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.
