[Twisted-Python] Advise for heavy concurrency
matusis at yahoo.com
Wed Nov 28 19:55:51 EST 2007
Here is one tip:
If you have a dual Xeon 5140 (4 cores) machine and run 4 twisted epoll servers in a similar (but not exactly similar situation), it chokes at 30000 clients.
The machine is CPU-bound, and the for loop that loops over clients to send your packets is a performance hog.
We are now considering using pyrex for that for loop, or rewriting it with C and libevent.
> -----Original Message-----
> From: twisted-python-bounces at twistedmatrix.com [mailto:twisted-python-
> bounces at twistedmatrix.com] On Behalf Of Atilla
> Sent: Wednesday, November 28, 2007 3:34 PM
> To: Twisted general discussion
> Subject: [Twisted-Python] Advise for heavy concurrency
> I'm interested in how well Twisted would perform in situations where
> there is a very high number of concurrent connections.
> The problem: I'm working on a feature that would require me to
> distribute small amounts, both in occurrence and size, of packets to a
> very large number of connected clients. Think in the terms of a Jabber
> or IRC server, but with a lot less traffic. What we're trying to do is
> to maximize the number of simultaneous connections a server can run,
> to an absolute maximum. It'll be a dedicated system so crippling any
> system-wide setting is not going to interfere with other applications.
> So far experimenting with the epoll reactor has shown really nice
> scalability as numbers grow. Thousands of connections per machine are
> no problem at all, but we need to scale out heavily.
> At a certain point the memory requirements for keeping open all those
> connections in the system grow higher, but those can be minimized by
> adjusting system buffer sizes, tcp window sizes and certain other
> Furthermore - more than one instance of the service could be ran per
> server, dedicating two or three processes on a 4-core CPU system,
> until exhausting the rest of the limits, in case CPU oevrhead becomes
> I'm also considering advantages that might come through different I/O
> and/or process schedulers. Is there anything that would be beneficial
> to my situation, considering the server will be a dedicated machine
> with little to nothing else to run on it that might suffer performance
> Does anyone have any experience with scaling twisted to a very large
> number of parallel connections? Are there any limitations that I might
> be missing?
> We'll start experimenting with a sample service soon to try to
> identify any specific limitations that will need to be worked on.
> Any tips are wellcome. Cheers,
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python