thank you for such detailed response. I feel, finally I've succeed to express my original question correctly. So if I go one step forward, and lets assume that indeed there is such limit of concurrent connections, THAN: should it be resolved by another architecture or another usage type of Twisted technology or something else? Quoting "Reza Lotun" <rlotun@gmail.com>:
Once there is a Site that serving many clients and reactor.listenSSL(), for example, that actually serving many TCP connections and all these going through TwistedGateway, my logic, please correct me if I wrong, says at some point there will be a limit on concurrent TCP connections, so how is it solved with Twisted?
That's a good question and I'm not sure if there's a definite answer to this (as far as I know). I think it depends on your application - for example, if your server is performing a big computation then on average client connections will last longer, meaning you'll have more concurrent connections.
The best way to determine this is to *measure* it - for example, you can do a load test with httperf and ramp up connections until this start to break or become unresponsive.
You can mitigate the situation by tuning your platform a bit (assuming you're using linux) - use the epoll reactor, which is high performance - make sure the number of open file descriptors is set to something high (and *not* 1024) - see `ulimit -a` - make sure you tune your tcp settings - see /etc/sysctl.conf, namely fs.file-max and various net.ipv4 settings (google is your friend on the best settings, coupled with testing)
Cheers, Reza
-- Reza Lotun mobile: +44 (0)7521 310 763 email: rlotun@gmail.com work: reza@tweetdeck.com twitter: @rlotun
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python