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.
Related
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.
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'm currently creating a website using PHP and the Kohana framework. I want to site to be able to use real time (or near real time) data (e.g. for chat and real time feeds). I need it to be able to scale to thousands of concurrent users. I've done a lot of reading and still have no idea what the best method is for this.
Does anyone have any experience with StreamHub? Is it possible to use this with PHP?
Am I digging myself into a hole here and need to switch languages? I've looked at node js and nowjs, but I'm weary about coding a while site in Express (I wonder about security holes, code maintainability, lack of a good ORM). I've read about Twisted Python, but have no idea what web framework would work well on top of that, and I'd prefer not to use Nevow - maybe Django can be used well with Twisted Python? I'm just looking to be pointed in the right direction, so I don't go too far in PHP and realize I can't get the near real-time results that I need.
Thanks for the help.
I've looked at node js and nowjs, but
I'm weary about coding a while site in
Express (I wonder about security
holes, code maintainability, lack of a
good ORM).
I can personally vouch for code maintainability if you can do JavaScript. I personally find JavaScript more maintainable then PHP but that's probably due to lack of PHP experience.
ORM is not an issue as node.js favours document based databases. Document based databases and JSON go hand in hand, I find couch db and it's map/reduce system easy to use and it feels natural with json.
In terms of security holes, yes a node.js server is young and there may be holes. These are un avoidable. There are currently no known exploits and I would say it's not much more vulnerable
then IIS/apache/nginx until someone points a big flaw.
I want to site to be able to use real
time (or near real time) data (e.g.
for chat and real time feeds). I need
it to be able to scale to thousands of
concurrent users.
Scalability like that requires non-blocking IO. This requires a non-blocking IO server likes nginx or node.js (Yes blocking IO could work but you need so much more hardware).
Personally I would advice using node.js over PHP as it's easier to write non blocking IO in node. You can do it in PHP but you have to make all the right design and architecture decisions. I doubt there are any truly async non-blocking PHP frameworks.
Python's twisted / Ruby's EventMachine together with nginx, can work but I have no expertise with those. At least with node you can't accidentally call a blocking library or make use of the native blocking libraries since JavaScript has no native IO.
PHP is not the language you should be using for real-time updates of a website. PHP scripts load first before HTML (and HTML calls javascript files), so PHP cannot update your page for you. However, when used with AJAX (eg. using a jQuery function to call a PHP file to update your page in real-time), you can use PHP in this fashion.
Using jQuery and AJAX (all javascript), you can do quite a bit in terms of updating a page without reloading it. I've seen sites such as this one that demonstrate how to make a chat using jQuery.
I want to make the most lightweight possible HTTP server in C that supports PHP and possibly FastCGI if it will make a huge difference.
I'm not sure how to implement PHP support. Does it just call PHP.exe with the path to a .php file and read the output? What about things like header () in PHP? How are those handled by the server?
And another question, is it ideal to use separate threads for each request? I don't expect a very heavy load, but I'm not 100% sure on the design aspect of this...
I'm still pretty new to C and C++ and this is a learning experience.
Firstly let me say that if the goal is a lightweight HTTP server that serves PHP pages, this has already been done. Have a look at nginx.
As for a learning experience, you've chosen something that's actually fairly tough.
Multithreaded is hard at the best of times. On C/C++ (anything with manual memory allocation really) it's an order of magnitude harder.
Added to this is network communication. There are quirks to deal with, different versions of HTTP (mostly a non-issue now), all sorts of HTTP headers to deal with and so on.
The most intuitive solution to this problem is to have a process that listens to a port. When it receives a request, it spawns a process, which may exec to a PHP process if required.
This however does not scale. The first (obvious) optimization is to use threads instead of processes and some form of interthread communication. While this helps, it will still only scale so far.
Go beyond that and you're looking at async socket handling, which is fairly low level.
All of these however are fairly big projects.
Is there any particular reason you're doing this in C/C++? Or any particular reason you're learning one or both of those languages? These languages certainly have their place but they're increasingly becoming niche languages. Managed (garbage collected) languages/platforms have almost completely taken over. Joel argues that garbage collection is about the only huge productivity increase in programming in about the last 20 years and I tend to agree.
For a learning experience regarding HTTP code written in C you may also take a look at:
http://hping.org/wbox/
To make your own HTTP server, I reccomend to get inspiration from other peoples code. The programmer ry famous for the node.js framework has written simple elegant code regarding this matter.
Check out his libebb library, it has a parser generated with Raegel using the easy yet powerful PEG (it's based on Zed Shaw's mongrel parser). Also check the example usage. It is really clean and usable code.
libebb is a lightweight HTTP server library for C.
It lays the foundation for writing a web server
by providing the socket juggling and request parsing.
By implementing the HTTP/1.1 grammar provided
in RFC2612, libebb understands most most valid HTTP/1.1
connections (persistent, pipelined, and
chunked requests included) and rejects invalid or
malicious requests. libebb supports SSL over HTTP.
Regarding PHP-Server coupling, the easiest way is CGI but if you feel adventurous dig into php source code under SAPI (Server API) modules to see how to do it.
Similar to libebb, see http://www.gnu.org/software/libmicrohttpd/. It too uses GnuTLS for optional SSL.
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.