Heh, you're too modest. Well, anyway, since it's a little clearer now to me, leaving multiplexing on is still hurting performance. I ran my benchmarks using "ab -c 5 -n 1000", so this was *the* scenario where it was supposed to increase performance (multiple clients hitting at the same time), and I still got much better performance with multiplexing off than on.
For the record: Multiplexing on Concurrency Level: 5 Time taken for tests: 34.250515 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 9739000 bytes HTML transferred: 9465000 bytes Requests per second: 29.20 [#/sec] (mean) Time per request: 171.253 [ms] (mean) Time per request: 34.251 [ms] (mean, across all concurrent requests) Transfer rate: 277.66 [Kbytes/sec] received Multiplexing off Concurrency Level: 5 Time taken for tests: 14.126215 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 9739000 bytes HTML transferred: 9465000 bytes Requests per second: 70.79 [#/sec] (mean) Time per request: 70.631 [ms] (mean) Time per request: 14.126 [ms] (mean, across all concurrent requests) Transfer rate: 673.22 [Kbytes/sec] received More than twice as many requests per second with it off. On Dec 9, 11:57 pm, Graham Dumpleton <[email protected]> wrote: > On Dec 10, 1:35 pm, Justin Davis <[email protected]> wrote: > > > > It is talking about the fastcgi socket connection between web server > > > and fastcgi process, nothing to do with user HTTP client. > > > Ahh, ok, that makes sense. Good to have a real expert on this stuff > > around -- thanks Graham! > > I just bullshit and people are stupid enough to believe me. ;-) > > > -Justin > > > On Dec 9, 6:47 pm, Graham Dumpleton <[email protected]> > > wrote: > > > > On Dec 10, 6:05 am, Justin Davis <[email protected]> wrote: > > > > > This is a good point -- why is that the default setting? From flup > > > > code: > > > > > 946 Set multiplexed to True if you want to handle multiple requests > > > > 947 per connection. Some FastCGI backends (namely mod_fastcgi) don't > > > > 948 multiplex requests at all, so by default this is off (which saves > > > > 949 on thread creation/locking overhead). If threads aren't available, > > > > 950 this keyword is ignored; it's not possible to multiplex requests > > > > 951 at all. > > > > > A quick test with a lighttpd server shows a significant (40%) increase > > > > with this turned off. > > > > > Someone correct me if I'm wrong, but the way I'm reading this is that > > > > it would handle multiple requests per client connection. This is > > > > probably not a common occurrence for most web apps since static > > > > content is usually served outside of fastcgi code path. > > > > It is talking about the fastcgi socket connection between web server > > > and fastcgi process, nothing to do with user HTTP client. > > > > Technically, two distinct users could make requests at the same time > > > and requests for those two users could be multiplexed across same > > > socket connection between web server and fastcgi process. > > > > In practice, few if any main stream web server modules for fastcgi > > > support this, so there is no good reason to have it enabled. > > > > FWIW, Apache/mod_wsgi does not multiplex across the socket connection > > > between the web server processes and its daemon mode processes either. > > > The extra complexity in the code is just not worth it and is likely > > > not to be as efficient. > > > > Overall, the only gain from multiplexing, if things even did support > > > it, would be keeping down the number of system file descriptors in > > > use. This is probably only going to be relevant to large scale shared > > > web hosting operations and not your average self managed site. > > > > Although it will help in the area of use of file descriptors, it does > > > risk causing latency problems and reduced performance due to > > > additional complexity of code to handle it plus the fact you are > > > stuffing more data down a single socket pipe. Depending on how the > > > fastcgi protocol is implemented, one user HTTP client blocking on > > > reading response could possibly even technically block all clients for > > > which data is being multiplexed over the same socket from fastcgi > > > process. This is because it isn't going to be realistic for web server > > > process to buffer up data for one of the sessions just so it can keep > > > passing back data from another. Whether this hypothesis is true I > > > don't know though as have never looked at code for a web server that > > > tries to implement multiplexing. > > > > Graham > > > > > Counter arguments? > > > > > On Dec 7, 3:31 am, s7v7nislands <[email protected]> wrote: > > > > > > hi,all! > > > > > any server support fastcgi 'mulitplexing', that allows a single > > > > > client-server connection to be simultaneously shared by multiple > > > > > requests? after google, I find apache,nginx,lighttpd all not support > > > > > it.and test with nginx, seem when mulitiplexed = False is faster than > > > > > True. > > > > > def runfcgi(func, addr=('localhost', 8000)): > > > > > """Runs a WSGI function as a FastCGI server.""" > > > > > import flup.server.fcgi as flups > > > > > return flups.WSGIServer(func, multiplexed=True, > > > > > bindAddress=addr).run() > > > > > > so why set this value 'True'? thanks! > > -- You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
