A mod_perl based multi-player strategy game in which the client sends and receives information about his location and status every 2 seconds. The sent information is light (around 20-100 characters, not including HTTP headers) and the received information varies based on the conditions, but usually ranges from 40-400 characters.
If you're counting bytes you'll need to account for TCP/IP overhead in addition to HTTP overhead. My memory (which is probably wrong) is that TCP/IP overhead is in the neighborhood for 46 bytes per packet. Since you're dealing with small data, you're probably not splitting packets.
Since the overhead of setting up (and tearing down) a TCP connection is 7 packages (3 to open, 4 to close), it's to your advantage to keep the connection alive. (See Connection: Keep-Alive and Perl for details.)
In a somewhat similar situation a while back, on a machine 1/2 as powerful, but doing a lot of work on the back end per request, we were able to handle 150 simultaneous connections, though they were polling every 5 seconds.
| [reply] |
You really need to instrument your handlers and get a good
idea of what's happening during a request. Get the
mod_perl Developer's Cookbook (ISBN 0672322404), which has several recipies on using Devel::Dprof and
Time::HiRes for gathering statistics. There's also
sugguestions on tuning the number of httpd processes and what
not.
| [reply] |
Your limit will be dictated by the number of apache processes you can fit in RAM at once. It's impossible to predict exactly how many that will be without measuring your application while it runs. One thing that may help is the use of a proxy server. See the mod_perl guide for details. | [reply] |