On Thu, Dec 15, 2016 at 02:43:24PM +0700, Dylan Jay wrote: > I think the distcc example does sound similar. That is basically whats > happening here. The time to read from disk + send back is not insignificant, > but the CPU part is done and is able to handle another request. Not sure if I > mentioned this before, but this archtecture is not mine specifically but an > open source python based application server (http://zope.org).
OK. This is indeed quite a common one. > I also perhaps should mention that we have solved this partially by using > x-sendfile headers (also called accelerated-redirects) which for some > requests will return just the header and then reenter haproxy via a different > queue with a high maxconn and get sent to nginx instead. However this makes > for a more complex setup and doesn???t cover all the use cases where the > backend server is streaming rather than processing. I understand. > You might be right that there could be different definitions of ???active??? > but at least for your POST example it is the same definition as for us. > Nothing gets sent from zope until processing is over. Actually thats only > partially true. There is a way to stream the result as you a processing it. > In which case the signal of ???any byte received??? is not enough to > differentiate a response that is still being processed from one that is not. > I guess there could be an optional response header to indicate processing or > not processing? (assuming haproxy parses response headers). This is an edge > case however, and in such cases it might be possible to know their urls in > advance and handle them via a different queue. We could imagine having a few options to define when a request is active, and later even have an http-response action to indicate that a request is not active anymore (eg: based on your response header). This still remains tricky though. At least the most complex parts have been dealt with when maxconn was implemented and here active requests would be a subset of the existing requests which themselves are a subset of the connections. > In terms of implementing, unfortunately myself and my colleagues are all > python developers. I haven???t touched C for 20 years :( Hey, that's what each and every first-time contributor says. After you'll spend some time reading some code you'll feel more at ease. Don't be ashamed :-) Cheers, Willy
