I've read and heard that nods.js should be better and lighter at the server when doing long-polling then on a PHP-server. I'm doing a study on this and would like to measure the serverload at two simple long-polling applications to see the difference.
How could I measure this in a good way? I read something about apache bench but don't know if that works when doing long-polling. Also, I'm running on localhost.
Here are my two applications if someone want to take a look: https://github.com/furst/longpolling
NodeJS is a whole platform built with various packages and relies on various installed libraries to make "concurrency", sockets and event driven programming possible. This makes it able to do a lot of very interesting stuff, and it can do it quickly.
PHP is just a programming language, just like JavaScript is, and therefore PHP and NodeJS are not directly comparable. PHP has projects with scopes and intentions as NodeJS, they are just a little less known.
Ratchet: WebSockets for PHP
That is built on top of the socket component from ReactPHP, which together aims to be a much more fair comparison to NodeJS.
Related
I'm starting to consider websockets as a solution to replace long polling in a new build PHP app I am commissioning.
I have a few questions which I wonder if people could help me out with.
Can a Nodejs server call PHP and if it did wouldn't it suffer the same shortcomings as just going through Apache in terms of the connections? We all know nodejs is non blocking and Apache etc isn't but if Nodejs is just making a call to a PHP server in it's own procedure would that not bottle neck in a similar way?
Are PHP and websockets a good match?
Are there any good js libraries besides socketio which apparently only works with Nodejs?
Has anyone found a good tutorial which uses websockets and a PHP backend maybe using something like that Ratchet PHP library which might help me get on my way?
Thoughts would be muchly appreciated.
Please excuse my paraphrasing of your questions.
1: Can Node.js call PHP, and wouldn't that have the same shortcomings as Apache?
Calling a run-once PHP script will have the same general shortcomings as calling a web page, except that you are removing an extra layer of processing. Apache or any web server itself is such a thin layer that, while you'll save some time, the savings will be insignificant.
If PHP is more effective at gathering data for your clients than Node.js, for whatever reason, then it might be wise to include PHP in your application.
2: Are PHP and WebSockets a good match?
Traditional PHP scripts are normally intended to be run once per request. The vast majority of PHP developers are unfamiliar with event driven development, and PHP itself does not (yet) have support for asynchronous processing.
PHP is a fast, mature scripting language that is only getting faster, even with all of its many warts and shortcomings. (Some say that its weak typing is a shortcoming. Others say that it's a shortcoming that its typing isn't weak enough.)
That said, the minimum that any language needs in order to implement WebSockets is the ability to open up a basic TCP port and listen for requests. For PHP, it is implemented as a thin wrapper around the C sockets library, and there are additional extensions and frameworks available that can also change the feel of working in TCP sockets with PHP.
PHP's garbage collector has also matured. Memory leaks come either from gross disregard for the memory space (I'm looking at you, Zend Framework) or from intentional sabotage of the garbage collection system by developers who think they're clever or want to prove how easy it is to defeat the GC. (Spoiler: It's easy in every language, if you know the details!)
It is quite possible and very easy to set up a daemon (long running background process) in PHP. It's even possible to make it well behaved enough to gracefully restart and hand its connections off to a new version of the same script, or even the same script on the same server running different versions of PHP, though this is treading out of scope just a tiny little bit.
As for whether it's a good match, that is completely up to the developer. Are you willing, able, and happy to work with PHP to write a WebSockets server, or to use one of the existing servers? Yes? Then you're a good match for PHP and WebSockets.
3: JS Libraries for WebSockets
I honestly haven't researched them.
4: Tutorials for using PHP and Websockets
I'm personally fond of this tutorial: http://www.phpbuilder.com/articles/application-architecture/optimization/creating-real-time-applications-with-php-and-websockets.html
Although I have it on good authority that the specifics of that tutorial will soon be obsolete for that specific WebSockets server. (There will still be an actively maintained legacy branch for that server, though.)
In case of link rot:
Using the PHP-Websockets server (available on Github, will be homed soon), extend the base WebSocketServer abstract class and implement the abstract methods process(), connected(), and closed().
There's much better information at the link above, though, so follow it as long as the link exists.
It would hit the same bottleneck if you go through apache. This can be remedied by using a different web server, such as lighthttpd or nginx. You won't even need node at all.
PHP does not have decent shared memory making the biggest advantages of a WebSockets irrelevent. It should be decent enough if you don't want interaction between users, but even then I would have to frown upon the usage of PHP. PHP is great for a lot of things, but real-time communication is not one of them.
You might want to look at https://github.com/einaros/ws.
PHP is not a good back-end. Anything with an execution model that isn't run-and-forget in its own sandbox, such as Node, .NET, C/C++ and Java are good matches. PHP is suited for short running executions, such as actual web sites and even web services -- but not real time connections.
We are planning to build a vast web application that provides real-time data update and display(sth like stockmarket). There is a need for efficient server-client bidirectional communication. After research html5 web-sockets seem a must. However there are several issues regarding compatibility and fallback as well as server support. We need a simple and stable solution in php preferable and apache integration. We made some tests with phpwebsockets and pywebsockets but they seem not so stable. What would you propose as a more stable - tested solution, sth like kaazing maybe but in php? Thank you in advance.
What you want to use is Socket.IO, which takes care of all the cross-browser issues and provides seamless fallbacks for the older browsers. Socket.IO was made to be used with Node.js, but can now be used with a number of different server-side languages.
However, I would NOT recommend using Web Sockets with PHP. Because PHP is not designed for long running bidirectional communication and will cause an entire Apache process/thread to lock up with each new connection.
I would highly recommend using a language like Node.js on the server-side, which can easily handle thousands of long running connections without any problems.
Did you try COMET?
Theres a lot of sample of COMET+PHP apps on web.
http://www.zeitoun.net/articles/comet_and_php/start
http://ajaxian.com/archives/comet-with-php
http://www.phpclasses.org/blog/post/58-Responsive-AJAX-applications-with-COMET.html
Nodejs for two reasons:
1: You can use the same language on both client and server, thus more code re-use.
2: The built in event loop makes javascript ideal for those "do a tiny bit of work and then sleep for 20 seconds" situations.
You have to love javascript to take it on the server though.
I would probably go with Node.js. While I love javascript, I'm not drunk the Node.js cool-aid. (Fair warning…)
But Node.js allows you to use Socket.io - and that is what you want to be using to make your real-time communication work seamlessly on "all" systems. Communication between PHP and Node.js can be handled through sockets, a database or some other insane stuff.
WebSockets are not well supported, plus there is no stable php implementation.
Have you considered using long-polling/COMET? It will work across all browsers.
I have such a conception, to build a simple web application using some php/mysql hosting service. I'd also like to create a local version of that app. The local version should work similarly as the online one (i.d. using browser as the ui) and have the ability to communicate with the server. I want it to be as lightweight as possible.
Professionally, I'm a c#/.net programmer. I also have some experience with c/c++,javascript, python and java. I know very little about php, and honestly, I don't like the feeling coding in that language, hence, don't have much willingness to dig into it. .Net, python or java they're all too unwieldy, I can't force the users to install any of them. So I thought about haxe's multi-targeting. If I were to code the project in haxe (it seems pretty straight forward to learn, for some one with my background), I might use the same logic on both side of the server and the client, by targeting both php and neko.
As a novice, I have some doubts. I'm not sure if haxe for php alreadly mature enough for this kinda job. I know haxe is a cousin of ActionScript, it primarily targets AS, and because the author is also the inventor of nekoVM, therefore, these two targets should be fine. But uh, how about php? Is it really good for that as well? Any hints or suggestions? Is haxe's builtin libraries ok for a simple web app or should I use a framework? Does neko have a httpRequest functionality at all?
Much gratitude in advance.
The straight answer is that Haxe/PHP seems to really fit well for you. That because of you background. I used Haxe/PHP in several projects (it happens that I am also its author) and speed has never been an issue for me. If there are bottlenecks usually there are also ways to optimize those portions for better performances, and if in the end you application scales to billions of users you can always opt to switch to neko or a C++/cgi combo.
About the frameworks there are a few options too: Web "frameworks" for Haxe to deploy in a PHP environment?
I'm building a PHP web application and I've reached a point that I need to build a Comet server because I need to update my users' whenever a new data is available (pretty much like FB). I've spent so much time searching the web and I've come to a conclusion that the best way to build Comet server is to build it with erlang. Also I've found that apache-php is not a good combination for doing that because the process per request issue.So, I have to build a lightweight http server for comet application.
I'm totally newbie in erlang world but I'm thinking of implementing Comet server in erlang and make it to function as interface for updating the clients only. For the rest of my web application functions, I still want to continue implementing them with PHP. So directing the requests of updating the clients to the erlang server and directing the other requests to apache-php server.
It seems very complicating. I need to know what's the best way to learn erlang for the sake of building Comet server and how to combine the two languages (erlang and php) to work together like when I have new info. to be pushed to the clients, I need to make the new changes available to Comet and then it pushes the info to the users. So how can I benefit from php and erlang and make them work together.
Sorry for the long explanation but I really need your help guys and any guidance you may give me to learn and implement what I want. Thanks a lot in advance.
EDIT:
Should I consider learning Python and Twisted to accomplish what I want?
It's definitely possible to do this with Erlang. One possibility would be to use long polling, which you can do with mochiweb. http://code.google.com/p/mochiweb/
Another idea is to use sockets. Until web sockets are supported by a reasonable number of browsers, you'll have to use a flash "bridge" to create a TCP connection, and use javascript to communicate with the server. Take a look at web socket JS: http://github.com/gimite/web-socket-js
Once you have this set up, you can communicate between your Erlang processes and PHP with something like this: http://www.math-hat.com/~zukerman/projects/php-erlang/
Then again, if you're still a newbie to Erlang, maybe you'll save time in the long run with Python and Twisted or Tornado.
Apache+php is indeed a bad technology for comet style applications. You can use a lot of other technologies that are closer to php though: Ruby, Python and Perl should all be usable. If you really want, you could probably write some kind of socket server in php aswell, but I would probably not bet on getting it to work out. That's not to say that Erlang isn't a good choice, but there are more mainstream alternatives.
If you don't want to use a mainstream language, be sure also to check out node.js, which runs some very impressive benchmarks. Plus you may already know a bit of javascript.
You can learn Erlang pretty quickly, you should be able to use things like gen_server, gen_event and that sort of thing from OTP. The quickest way to learn Erlang should be to work your way through the documentation and examples at: http://www.erlang.org/doc/index.html.
For the communication between PHP and Erlang you can use sockets, fsockopen() and the rest on the PHP side and gen_tcp on the Erlang side. You can parse the Erlang terms sent trough the pipe from the PHP side (more info here).
I never used Erlang and PHP but I used Erlang and Python with some success, knowing PHP it should be pretty easy, just try to keep everything clean and keep the state on the Erlang side, using PHP only to generate the UI.
If you are considering Python and Twisted you can take a look at Orbited. They have very mature Comet implementation. You can make Orbited to communicate with your PHP application through STOMP protocol.
This article has a decent tutorial which will get you started with Orbited
http://thingsilearned.com/2009/06/09/starting-out-with-comet-orbited-part-1/
To integrate your application with PHP you will need to google for PHP STOMP clients
An addtional option is to use Nginx and it's push module (http://pushmodule.slact.net/)
This will allow you to use Comet from PHP without the need to learn a new language.
You should look into Yaws. It's an Erlang web server that's been around for over a decade, is extremely stable and still under active development and maintenance, and supports long-polling, PHP applications, WebSockets, and much much more — pretty much everything you could want.
The Yaws sources are on github and its mailing list is here.
Try Chicago Boss framework here ... using that you don't have to know the nuts and bolts of the thing called OTP (which actually very easy, powerful and battle proved), because the designer of Chicago Boss, managed to encapsulate it nicely... according to the tutorial.
I'm learning it right now, after learning OTP.
I was wondering if ASP.NET is more efficent than PHP with sockets. Ive frozen a server several times doing relatively few connections on PHP. I was wondering if any server side programming engines are capable of hosting a reliable and efficient socket server.
Having never implemented a socket server in PHP, nor ever touching ASP.NET I can't comment on those.
I've seen many great socket applications implemented in Python. I recommend looking into Twisted.
I've personally played around with EventMachine (Ruby), and it's definitely a great little library to use. Their goal is:
Extremely high scalability, performance and stability for the most demanding production environments
Creating a server with EventMachine is as simple as:
require 'rubygems'
require 'eventmachine'
module Echo
def receive_data data
send_data data
end
end
EM.run {
EM.start_server "0.0.0.0", 10000, Echo
}
You should be able to benchmark this pretty easily. It's a simple echo server.
A word of caution with php: AFAIK threading is not enabled by default and so getting this run efficiently will be one extra step for you. No idea about ASP.NET on this.
I'm currently in the middle of doing the exact same thing and had a couple thousand lines of php sockets code written before deciding to move over to c++.