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. *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. L8r, Rob
