I have developped an application using PHP/MySQL which used comet technology, presicely long-polling. The proof of concept works great, but I am expecting traffic to quickly reach thousands of simultanous connections = thousands of open connections on the webserver.
I do not have the ability to setup my own server (e.g. using lighttpd), and usually rely on simple 5$/month PHP hostings for other web projects. However, I realize those won't do the trick as they are not meant to support such a high number of simultanous open connections.
What are my other options? I could not find any host specialized in comet applications.
Thanks
you would be better of with dedicated server, which will be more expensive, but it will do the job, i personally like 1and1.co.uk, and if your in america 1and1.com
hope that helps!!
I've been in the same situation as you, and just decided to go with a dedicated server, where I would then install Nginx and the Push Module. This was a real-time chat for a newspaper's website, and it has worked great so far. Apache will go under real quick as Jon mentions, while nginx performs great, and the push module is as simple as it gets. Good luck!
Yeah Apache isn't designed to be used with many open connections. You may want to look into running cometd on top of Jetty. You will have to do some programming in Java, but you would still be able to do all your web requests in php. You might be able to find a Java/Jetty and PHP web host.
I'd like to see what other solutions people have.
I have read that Apache does not handle well many open connections to server.
Many people recommend nginx or StreamHub Comet Server (Python):
Python Comet Server
http://ajaxpatterns.org/HTTP_Streaming
Or you can use complete Comet Framework (works with PHP): http://www.ape-project.org/
Related
I've been "recruited" so to speak to help work on a web project that is currently written in PHP with an Apache server. We would like to integrate a real-time (or at least something very close to it) chat feature. Scalability is a definite concern, and this type of work is definitely not my typical.
Everything I've read about creating such a chat feature requires the use of "long-polling" so the servers don't get rapidly overloaded and, well, crash. PHP and Apache are not conducive to implementing such a feature, so I've explored some alternatives, like Twisted Python for example.
The website has roughly ~7,000 lines of PHP (i.e., it'd pretty difficult to just straight switch languages for the entire thing), so my question is how can I manage this situation as far as trying to integrate python and setting up a separate server? Or, is this a very bad way to do this? Are there other alternatives that would be better suited? (Sadly many of the PHP Comet, or even AJAX, solutions I've found don't scale in the slightest. Note, the Apache server is not necessarily required; however, any server used must work with PHP and Python etc, short of having separate servers.)
Thanks for the help!
I would use Tornado on the server to write the chat application. Client server communication can then be over websockets. If you use SockJS on the client side you can also support older browsers via long polling. There are plenty of example chat clients written using Tornado. It's very simple to get started and it is wonderfully scalable. A chat server like this can be serving thousands of clients without showing any appreciable CPU activity.
This is an example, possibly a bit over engineered https://github.com/diggidanne/websocket-chat/blob/master/server.py
With all the buzz around WebSockets, it's pretty hard to find a good walkthrough on how to use them with an Apache server on Google.
We're developing a plugin, in PHP (symfony2), which will run from time to time kind of a chat instance. And we find WebSockets more interesting, standard and quick than AJAX for this matter. The thing is, we don't have much sysadmin ressources in our group and we find hard to gather good informations on the following matters:
Can we run a WebSocket instance on a traditional Apache, dedicated server, and if yes, do you have useful links for us?
If we need to mod the server, what kind of tools would you recommend knowing that we are not too skilled in sysadmin so we can't afford to have a high maintenance b*** on this.
Thank you very much,
ps: we'll link back to your blog/site as we'll make a technical/informational post on our devblog about this part of our app.
Thank you again!
As #zaf states you are more likely to find a standalone PHP solution - not something that runs within Apache. That said there is a apache WebSocket module.
However, the fundamental problem is that Apache wasn't built with maintaining many persistent connections in mind. It, along with PHP, is built on the idea that requests are made and responses are quickly sent back. This means that resources can very quickly be used up if you are holding requests open and you're going to need to look into horizontal scaling pretty quickly.
Personally I think you have two options:
Use an alternative realtime web technology solution and communicate between your web application and realtime web infrastructure using queues or short-lived requests (web services).
Off load the handling of persistent connections and scaling of the realtime web infrastructure to a realtime web hosted service. I work for Pusher and we fall into this category.
For both self-hosted and hosted options you can check out my realtime web tech guide.
One path is to use an independent installed web sockets server.
For PHP you can try:
http://code.google.com/p/phpwebsocket/ or http://github.com/Devristo/phpws/
There are some other projects which you can try as well.
Basically, you need to upload, unpack and start running the process.
On the frontend, you'll have javascript connecting to the server on the specific port.
Most websocket servers have a demo which echoes back whatever it hears, so this is a good place to write some test code. You may even find a rudimentary chat implementation.
The tricky part is to monitor the web socket server and to make sure it runs smoothly and continuously.
Try to test on as many browsers/devices as possible as this will decide on which websocket server implementation you choose. There are old and new protocols you have to watch out for.
I introduced another websocket server: PHP Ratchet (Github).
This is better and complete list of client & server side codes and browser support.
Please check this link.
Another Path is to use a dedicated websocket server.
Try Achex Websocket Server at www.achex.ca and checkout the tutorials.
OR
If you really want Apache, check out Apache Camel. (but you have to set it up and its a bit more complicated than achex server)
http://camel.apache.org/websocket.html
I have been reading about websockets and also about socket.io.
I understand websockets are not support but enough browsers yet to be realistically used.
socket.io has browser support but appears to need node.js. With my hosting solution I have some space on a shared server, very limited control over the server and have access to php but there is no node.js.
I have read that people can get socket.io to work with PHP.
Question: seeing I have very limited server access, not control over ports, command line etc is it realistic that I could get socket.io working with PHP or should I just stick with the AJAX calls (I'm currently using)?
Note: I've developed a chat solution and it appears it would be much more light weight if it was running with a socket solution.
Also - is there good security with Sockets.io?
thx
Trying to make PHP talk to socket.io I suspect will be a big task.
Certainly it's not a great idea to run websockets via a pre-fork or threaded apache. Any event based server should be OK if you can handle the number of PHP processes. A better approach would be to write an event based server in php. Like this one
i researched a few websocket server implementations. i read, that there is a way to use node.js in production. using apache many years, i also searched for a module to handle websockets within apache, but found only half-hearted stuff. nothing which seemed solid.
i stumbled upon yaws, which is a websocket capable server written in erlang, which has the advantages of beeing the right language for a highly parallel application such as the chat thing, and also because websockets should be well integrated within the main server.
now, i'm developing a php chat server, which uses a framework called ratchet. -> google for 'ratchet php'. they got a good tutorial.
i start it via the commandline, and although for you it should be possible to also start the ratchet server via a browser call, i would not recommend that.
so in your constrained hosting environment, i would stick to ajax.
Only yesterday, I was asking a friend of mine how he would go about emulating direct communication channels between two clients through a web server, for the purpose of creating a chat application, but by using solely PHP/MySQL/JavaScript.
He told me that the best way to do this was by the use of SOCKETS, a term I had only heard of until then. This morning I started looking into it for the purpose of creating my chat application, but I'm quickly starting to believe that it's not as easy as I'd hoped.
So my question is this: if I don't have access to my own server (I have a domain hosted on a shared server that I also use for testing purposes), can I still use sockets to achieve my goal? If so, how exactly? (Please understand that I am completely new to the idea)
If not, what other way is there to accomplish the communication channels?
My only idea so far is to simply send periodic requests (AJAX) to the web server the application would be stored on and request any new messages, if any. But this does not seem very feasible.
Thanks in advance for your help!
I think what your friend is trying to get to is implementing Comet for your chat site.
Assuming he's getting you to use PHP sockets to act as a daemon, I highly doubt a shared hosting provider will let you do it.
You could try hanging the PHP script until there's data available. However, this will quickly consume resources on a CGI-based server since the PHP server can't tell if the client is still connected. I know this from experience.
For these kind of things, I highly recommend you get a dedicated server or VPS and write your backend in something like socket.io which automagically handles all your communication problems on both the client and server side. PHP, MYSQL and servers that fork to serve requests are usually the worst case scenarios for implementing Comet since they incur quite a bit of overhead and aren't scalable.
If you can't afford to run your own Comet server, then polling may be your only option. This will be the most resource intensive and least responsive.
I wanted to know if somebody could explain in somewhat simple terms how I could get
started with comet. I am on a shared host environment.
What exactly are my possibillity's?
From what I have read here sofar, is that php is not the best option., because it is
run as a one process per request instead off thread.
On another, they talk about sockets.
I have also read about facebook and that they run there own comet server written in erlang, but they still have a php website. So how exactly does that work then?
I have read alot off stuff now, but it is still a bit vague on what is actually possible
in my situation. Running a php script that is a client off a comet server?? That is not saying how it keeps a longlasting open connection! (just throwing in some comments from other posts)
thanks, Richard
You can use PHP to reproduce the Comet behavior. Like you said PHP isn't the best choice because of a lot of memory management issues that are still widely there.
However for small scale purposes (low-traffic) PHP will work just fine.
There's a lot of information on the web about Comet and how to use it with languages such as Python or Erlang (especially good because of its optimal concurrency behavior, but frankly I don't know much about it).
If you want to try out Python there's a good question/answer on SO:
Python Comet Server
A simple solution is to find a SaaS comet provider, such as the one we host at Frozen Mountain, WebSync On-Demand. Basically, it'll let you use our servers (running WebSync + IIS) to handle the long lived connections, but allow you to publish your messages via PHP, and pre-process your messages in PHP. If you're going to have < 10 simultaneous users, it's free, so for a small site it should do exactly what you need.