31–40 of 85 posts
Instead of loading apache for each php call, why not have a few PHP FastCGI instances running? They're lighter weight than apache+mod_php and you don't have to wait for them to load for each call?
The more generalized takeaway from this is that you shouldn't use a heavyweight listener to handle polling (or websockets in the near future) if you can avoid it. PHP was the culprit here, but I can't help but think you'd have had the same problem if you were trying to do the same thing with RoR, any Java app server, or any of the Python frameworks. Likewise, node.js or Twisted probably would have been an equally eff…
I'd probably go with node.js for this task - more manageable. Twisted has a huge learning curve.
could you give more info about how you did it? I need to implement something like this for a frequent Ajax refresh.
Sure thing, what part are you stuck on?
Earlier quoted context omitted.
Sure thing, what part are you stuck on?
thanks for the reply. I haven't started to code, but maybe in some weeks. It's more a chatroom with long polling that I will be building. All your app is in one dedicated server?
Right now the C app listens on a different port that lighttpd will redirect to if a pertinent request comes in.
There is a parent process that will fork upon connection and pass the socket to child which pulls the requested data and quickly returns it.
The one thing you will also need if you go this route is a SIGALRM handler. You just basically call signal() and set a flag before each socket read and write. So if the socket takes too long to return the signal gets called and kills the child process. Then you clear the flag on the other side of the socket read/write call so that the signal doesn't kill the process if the call returns on time.
Earlier quoted context omitted.
You could google how to do a simple fork server in c/c++ and after you have that working you just need to do something like this: stringstream response; response int n = write(s, response.str().c_str(), response.str().length()); if(n to write back a valid header that a browser will understand
You could store the static (non-changing) text in a couple of C strings and then call writev() to communicate everything. That would save you the step of continuously reconstructing the header.
For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible:
"We rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck. Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource."
http://www.ruby-forum.com/topic/62907
Later they tore out the C code and re-wrote it in Erlang.
Earlier quoted context omitted.
I'm not trying to be offensive either :) I was just warning that putting up a public facing server is eventually going to make you a target. Using a battle tested server will let you concentrate on getting more people to use your app instead of fighting bored 13 year olds trying to bring your server down. Good luck with your app!
Thanks! I understand your point, but a fork server is so simple I don't think there is much that can go wrong there, if it was serving more data I would be worried, but its meant to do a quick and short reply.