"Rob Bloodgood" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Thursday, November 6, 2003, 9:39:58 AM, you wrote: > > PM> 2) If the server gets many simultanuous clients, refreshings bring extra > PM> hits to the server. For example, if the refresh rate is 3 seconds, then > PM> 1000 connections = 330/s hits, a big number. POE is based on non-blocking > PM> multiplex model so does not have such an overhead, true ? > > POE itself has never been the source of my concurrency problems > (currently serving only 88hits/s, it's kinda slow right now). > > Handling alot of sockets simultaneously is nice and clean, most of the > time... But be careful of: disk reads/writes, DBI of ANY kind, > long-running states (in the 100's of milliseconds) at that kind of > load, because EVERYBODY waits on the ONE process. >
I was told that by replacing select/poll with lower- I/O calls, a carefully designed multiplexing server in C can handle 20,000 concurrency connections. POE may be not that robust, but based on all those information, it looks that a thousand client poll should be just fine. Apache comes with a default MaxClients (fork) = 256. I ususally turn it to be 1024 and see that a "typical" unix server with 1G can handle 400-600 connections fairly well. What I want to say is that network servers usually has more potential than expected. :-) > *And*, I had to jump through special hoops to not have my > PoCo::Wheel::Run-based component monopolize POE's attention until the > entire (long-running) transaction was complete. > > Fortunately, you may be awhile reaching those kinds of loads. :-) > > My primary app is NOT primarily HTTP-based, but I threw in a web > server because it was easy to do and because HTML is dead trivial to > format internal state into, to peek at what the program in doing > inside. That being said, my HTML-generating states are *TERRIBLE* > performers... but that's because I have a LOT of data to report. Even > at local-network 100mbps speeds, it still takes a second or so to send > 300kb of report (which is after taking (...checking...) .633 seconds > to generate the output :-). > > Reasonably sized output should multiplex just fine, however. > I expect a huge load in number of connects, but messages sent back and forth are light and simply. In my priliminary design, there are basically only three objects involved: a POST request from client, a stream data flowing to client and a session hash managing users/messages. No disk file will be involved, and when the server stops, all historical data are gone. Well, maybe I'll put a registation and authentication in a DB later. I am reading POE pm's and Randal's articles carefully -- I learned a lot from his column for a long time :-). > L8r, > Rob > Pod
