<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 19, 2011, at 8:39 AM, Michael Thompson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Menlo; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">I agree that threads and processes is going to be the first step to<br>scaling but I don't think there's much advantage putting that in<br>twisted given that there are other solutions for this.<br></span></span></blockquote><div><br></div><div>Other solutions for what? If Twisted is going to be a WSGI container, it should (eventually) be a multiprocess container, since that approach scales better to the number of CPUs. Other options in the arena of single-machine load-balancing require lots of tedious setup and usually subtly affect the semantics of your application (you have to do work to make sure the application gets the correct idea of what URL it's being visited at and who the client is).</div><div><br></div><div>It would be even better if Twisted could automatically scale your WSGI application up to multiple hosts, even. This is exactly the sort of thing that Twisted is good at.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Menlo; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">I was hoping that changing the reactor would give an easy way to make<br>Twisted look better, from a PR point of view. To check I ran a<br>benchmark on two EC2 m1.small machines using<br></span></span></blockquote></div><br><div>Changing the reactor typically affects applications with a high degree of concurrency (more than 1000 concurrent connections) where the bottleneck is the multiplexing mechanism. It can affect other things sometimes, but that's the usual problem it's meant to address.</div><div><br></div><div>The benchmark we're discussing is handling only a few requests at a time. Itamar's approach to widening the threadpool is a better way to increase concurrency than changing the reactor, since the number of concurrent requests will be bottlenecked on the maximum number of threads anyway.</div><div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="font-family: monospace; ">So looks like the reactor has nothing to do with it. Here some profile results for the select reactor.<br></span></blockquote><br></div><div>If you want to turn this profiling project into some optimizations, add a simple WSGI requests-per-second benchmark to a branch of <<a href="https://code.launchpad.net/~exarkun/+junk/twisted-benchmarks">https://code.launchpad.net/~exarkun/+junk/twisted-benchmarks</a>>, tell exarkun about it, and then submit a patch which makes that benchmark's number go up.</div><div><br></div><div>Thanks for following up on it!</div><div><br></div></body></html>