On 20/11/2012, at 12:29 AM, Willy Tarreau <[email protected]> wrote: > On Tue, Nov 20, 2012 at 12:08:12AM +1300, Dylan Jay wrote: >> 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. > > OK, that's becoming a bit tricky then.
I think I'm making it sound more complicated than it is. Basically in most web apps once the status header has been sent then most processing has already happened since otherwise you can't indicate to the browser an error in processing occurred. So status header means generally the server will be ready to receive another request very soon. > >> 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. > > Do you know if there is something in the request that can tell you whether the > request is for a large blob or a generated page ? If so, I have a solution :-) :) Only the extension in the URL or perhaps a range header with some video players. But both are hacks and won't apply in all cases which why I'm looking to avoid it. > >> 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. > > I agree and this is generally what people do when running with such low > limits. > >> 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). > > In general the risk is low because if a request gets too slow and times out, > there are big changes that the second request will experience the same fate. Not really. Some requests are just slow transactions like complex saves or long generated HTML pages. If a request is waiting behind a 2 second request when it could have been sent to a server that was just serving video then that's inefficient. > >> 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? > > The maxconn cannot be adjusted that way, it would be a bit dangerous. But > maybe > we could have a per-server active-request count and use this to offset the > maxconn vs curr_conn computations when deciding whether to dequeue or not. > > However I still think that playing with maxconn is a bit dangerous because I'm > fairly sure that your server has a hard limit you don't want to cross. And > that's the goal of the maxconn setting. > But if there was a maxconn and a max processing or max action request limit I'd set maxconn to say 4 and maxprocessing to 1. There would be a limit to the number of blobs it can serve efficiently at once on a single thread. > Willy >
