> Out of curiosity, is it usually time to first byte where the delays show up? > I am wondering if there is a big bang-for-the-buck enhancement possible there > that doesn't prereq changes to some of the areas where hopping on and off the > thread is more complicated.
Ultimately, most of this stuff is getting bottlenecked on database accesses (or similar resources) somewhere in the backend. The problem is, I deal with hundreds of different applications (with both JBoss and Tomcat using the mod_proxy backend) and each one performs slightly different. It would take more than a trivial amount of effort to get specifics on whether these are blocking before the first byte of the header or before the first byte of the content itself ( as in https://docs.oracle.com/javaee/6/api/javax/servlet/ServletResponse.html#isCommitted%28%29 ). In at least the case of WebSphere Application Server (granted, a non-mod_proxy backend), I think there was even an option to control the data chunking to have the server either wait for a complete response or to start sending it out in pieces. How the JEE tiers typically work is that one or more non-presentation layers first collect all the data needed and perform the business logic -- this would typically get called from the Servlet itself (ex. doGet method -- or an equivalent spot in a framework). Then, that display object gets sent to the presentation layer (JSP or the like) in the form of an object, where the final form is rendered (XHTML, HTML, etc.) strictly from the contents of that object. As the presentation logic is a very small part of the overall execution timeline (and should not be making backend calls itself), users typically see nothing for a while, then the whole page just pops up. The headers are a similar state, and I suspect (but have not confirmed) they only leave the server as a complete set (hence the isCommitted method above). This is in direct contrast to typical LAMP stack setups without a dedicated presentation tier (like a simple PHP site), where end users often see a page partially render output, pausing at specific database queries. I would definitely expect to see a substantial improvement if the thread reservation could be delayed until the response headers are fully received. However, it would take some additional research to figure out how much if any of that savings could also be gained by allocating the thread when the response headers first start coming in. That additional research may also be highly dependent on the specific backend in question and any options in use. At least under this type of JEE workload, however, I would not expect to see a noticable benefit to being able to detach and re-attach the worker threads after we start processing the response body. Rick Houser Web Administration > -----Original Message----- > From: Eric Covener [mailto:[email protected]] > Sent: Thursday, December 03, 2015 12:40 PM > To: Apache HTTP Server Development List <[email protected]> > Subject: Re: reverse proxy wishlist > > On Thu, Dec 3, 2015 at 12:36 PM, Houser, Rick <[email protected]> > wrote: > > An async mod_proxy backend would be huge for my workloads. In the JEE > space I deal with, much more time is spent waiting on the application backends > then with the clients, especially now that we have the event mpm. Something > like this would allow me to drastically reduce thread counts and free up a > lot of > associated memory. > > Out of curiosity, is it usually time to first byte where the delays show up? > I am wondering if there is a big bang-for-the-buck enhancement possible there > that doesn't prereq changes to some of the areas where hopping on and off the > thread is more complicated.
