On 19/11/2012, at 11:02 PM, Willy Tarreau <[email protected]> wrote: > On Mon, Nov 19, 2012 at 10:39:17PM +1300, Dylan Jay wrote: >> zope is optimised to handle cpu bound and io bound requests differently. >> During request processing it will handle a single request per thread, however >> since threading in python isn't that good and due to request processing in >> zope being mainly CPU bound most people will run zope with single thread per >> CPU. However once a request is processed and if the result can be streamed >> from a blob file on disk, then this will be done asynchronously while the >> next request is being processed. > > OK, that's interesting to know. So that applies to all responses, no just > delivery of static files ?
No not all responses. Zope has an object database with blob support. It only applies to images, document, videos etc stored in the database, which is sort of like static files. Once it's decide to send the file, the transaction can end and the actual sending of the file is handled off to an async thread. It doesn't apply when a html template page is being generated since the transaction doesn't end till the last bit of the page has been generated. The problem I'm trying to solve is delivery very large blobs like long videos which could take a long time to stream and aren't amenable to cache in something like varnish. Currently while thats happening the cpu is being underutilised. > >> I'm not sure but I suspect other back end servers might act similarly in that >> by the stage they are starting to deliver the response back to haproxy, most >> of the CPU bound operations are over and it would be a good time start >> processing the next request. > > OK. In fact it would not be the first byte of data but the end of headers, > but that's similar. true. > > At the moment I see no easy solution to do this, since haproxy counts the > established connections to apply the maxconn. But I think we can add another > concept of active request, which would be a request for which we did not > receive a response yet. I'm trying out setting maxconn to 2 even when dynamic requests will be handled synchronously. At least some of the time the request will get processed earlier increasing the cpu utilisation. The risk is a request could get stuck behind a slow request and since haproxy has already handed off to the backend it can't redistribute it (or it could but then it would get done twice). but if there was a setting like max-active-requests=1 then that would result in better balancing. or perhaps if there was a way to use acls with response headers to up the maxconn while serving a video? > > Possibly this could even be combined with the current maxconn mechanism. > This still needs some thoughts and some work. > > Willy >
