On 19/11/2012, at 10:07 PM, Willy Tarreau <[email protected]> wrote: > Hi, > > On Mon, Nov 19, 2012 at 07:57:30PM +1300, Dylan Jay wrote: >> >> On 13/11/2012, at 9:51 PM, Dylan Jay <[email protected]> wrote: >> >>> Hi, >>> >>> I have backend servers (zope) which generally are single threaded and I >>> have a maxconn set to 1. However when they send binary data such as a large >>> video or image they will do this asynchronously and will accept another >>> connection to process while streaming the last request. In order to make >>> the most efficient use of the CPU of my servers I'd like my queues to >>> dequeue at the point at which they receive the first byte from the backend >>> sever rather than waiting for the connection to close. Is this possible? If >>> not, is there a work around to get more efficiency? >> >> no one's got any suggestion? > > That's quite a strange software architecture, isn't it ? Do you know what > makes the request parsing limited to one connection if the machine is > capable of processing the remaining data asynchronously ?
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. 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. > > I'm not opposed to finding a solution to make haproxy capable of improving > such a use case, but it would be nice to understand why such bottlenecks > exist in the first place, so that we know whether we should cover other > use cases at the same time. > > Regards, > Willy >
