RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > Subject: RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP > requests from same browser > > You would need a fairly large, and well-disciplined team of pigeons to > > do that though. I don't think that this was a good metaphor, You should > > have chosen a bigger bird and/or a smaller load. Eagles and tennis > > balls maybe ? > Or swallows and coconuts. Someone had to bring that up. African or European? I think we can remove the "not" from the subject line now... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
On Fri, Mar 22, 2013 at 10:04 AM, Jeffrey Janner < jeffrey.jan...@polydyne.com> wrote: > > -Original Message- > > From: André Warnier [mailto:a...@ice-sa.com] > > Sent: Thursday, March 21, 2013 8:51 AM > > To: Tomcat Users List > > Subject: Re: [a bit, but not totally OT] Tomcat Behavior on Multiple > > HTTP requests from same browser > > > > Christopher Schultz wrote: > > > HTTP connections for long periods of time, but that's really abuse of > > > the protocol IMO. You can send bowling balls via carrier pigeon, but > > > there are better ways to send bowling balls. > > > > You would need a fairly large, and well-disciplined team of pigeons to > > do that though. I don't think that this was a good metaphor, You should > > have chosen a bigger bird and/or a smaller load. Eagles and tennis > > balls maybe ? > > > > Or swallows and coconuts. > > Jeff > (sorry, couldn't resist.) > > Wow, you all are funny! LOL
RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
> -Original Message- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Thursday, March 21, 2013 8:51 AM > To: Tomcat Users List > Subject: Re: [a bit, but not totally OT] Tomcat Behavior on Multiple > HTTP requests from same browser > > Christopher Schultz wrote: > > HTTP connections for long periods of time, but that's really abuse of > > the protocol IMO. You can send bowling balls via carrier pigeon, but > > there are better ways to send bowling balls. > > You would need a fairly large, and well-disciplined team of pigeons to > do that though. I don't think that this was a good metaphor, You should > have chosen a bigger bird and/or a smaller load. Eagles and tennis > balls maybe ? > Or swallows and coconuts. Jeff (sorry, couldn't resist.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 3/21/13 7:15 AM, André Warnier wrote: Christopher Schultz wrote: I think there might be a problem with the instrumentation, or just coincidences at a fairly implausible level. The trust of the matter is that Tomcat does not allocate a thread permanently to a remote client until ... whenever the client "disconnects" (whatever that means, as HTTP is a connection-less protocol). (See the nitpick (*) below) Possible, but see above again with the httpd/tomcat connections managed by the mod_jk module. It does have and manage its own pool of connections, with each connection potentially "staying alive" for a time much longer than any individual client request. I do not deny that. Right, but the AJP connections are managed in a connection pool. I haven't really checked-into this, but I suspect that two requests coming from the same keepalive connection have no guarantee of being sent across the same AJP connection to Tomcat, and thus no guarantee that they will be served by the same JVM thread. mod_jk is aware that the client/httpd connection is keepalive, and it does not have any way to know that this client is not going to send another request to Tomcat. So what does mod_jk really do ? Does it relinquish the one connection that he had to Tomcat back to the pool immediately after the first response has been served ? or does it keep its handle on that pool connection until the client/httpd timeout has expired ? It would be a mistake for mod_jk to retain control of the AJP connection for that keepalive request -- there's no guarantee that the /next/ request across that connection would even be routed through mod_jk: it might be for some other resource that another module handles. On the other hand, if there were 10 successive requests for Tomcat from the same client on the same connection, then it might be argued that it would be counterproductive to return the connection to the pool each time, just to go obtain another one right after, and this 10 times in a row. May be there should be an "adaptative" or "predictive" algorithm here : if this client in the recent past has always sent several requests in short succession, then maybe I'll keep this connection for now, just in case he does it again. I can already hear Rainer saying "patches are always welcome". ;-) But the real point is : does mod_jk keep the connection, or does it return it to the pool at the end of each response ? Barring Rainer reading this, I guess that only looking at the code would tell. Note that Apache httpd already maintains the client/httpd connection, and keeps a count of how many requests have been received over this connection. It has to, for MaxKeepAliveRequests. So it would not be too much of a complication for mod_jk to keep its own count, of how many requests forwarded to Tomcat have been received over this same connection. That would already be a good predictor of whether the same is likely in the future. a = time for which this client connection has been alive b = number of requests forwarded to tomcat over this connection c = a / b = average time between 2 requests forwarded to tomcat if c is lower than the overhead for obtaining and returning a connection from the pool, then keep the connection. It would be self-adaptative, because if the client slows down its request rate, then c would become larger, and the connection would be returned to the pool; and vice-versa. There is also kind of a weird question here : what is really the purpose of the keepAliveTimeout attribute on the Tomcat AJP Connector ? +1 (*) nitpick about HTTP being connection-less : that may be true in the sense that each request+response is supposedly independent from any other request+response. But HTTP 1.1 explicitly introduces "persistent" TCP connections. Yes, and HTTP sessions are standard fare these days, too. But the fact is that HTTP itself is connection-less. We as engineers can make it feel like it's not and do stupid things like put JDBC connections into HttpSession objects and try to tie everything together to make the user feel like they have a permanent connection. We can even hold-open HTTP connections for long periods of time, but that's really abuse of the protocol IMO. You can send bowling balls via carrier pigeon, but there are better ways to send bowling balls. You would need a fairly large, and well-disciplined team of pigeons to do that though. I don't think that this was a good metaphor, You should have chosen a bigger bird and/or a smaller load. Eagles and tennis balls maybe ? I should also probably remind you of RFC 1149 : http://en.wikipedia.org/wiki/IP_over_Avian_Carriers - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 3/21/13 7:15 AM, André Warnier wrote: > Christopher Schultz wrote: >> >> I think there might be a problem with the instrumentation, or >> just coincidences at a fairly implausible level. The trust of the >> matter is that Tomcat does not allocate a thread permanently to a >> remote client until ... whenever the client "disconnects" >> (whatever that means, as HTTP is a connection-less protocol). > > (See the nitpick (*) below) > > Possible, but see above again with the httpd/tomcat connections > managed by the mod_jk module. It does have and manage its own pool > of connections, with each connection potentially "staying alive" > for a time much longer than any individual client request. I do not > deny that. Right, but the AJP connections are managed in a connection pool. I haven't really checked-into this, but I suspect that two requests coming from the same keepalive connection have no guarantee of being sent across the same AJP connection to Tomcat, and thus no guarantee that they will be served by the same JVM thread. > mod_jk is aware that the client/httpd connection is keepalive, and > it does not have any way to know that this client is not going to > send another request to Tomcat. So what does mod_jk really do ? > Does it relinquish the one connection that he had to Tomcat back to > the pool immediately after the first response has been served ? or > does it keep its handle on that pool connection until the > client/httpd timeout has expired ? It would be a mistake for mod_jk to retain control of the AJP connection for that keepalive request -- there's no guarantee that the /next/ request across that connection would even be routed through mod_jk: it might be for some other resource that another module handles. > There is also kind of a weird question here : what is really the > purpose of the keepAliveTimeout attribute on the Tomcat AJP > Connector ? +1 > (*) nitpick about HTTP being connection-less : that may be true in > the sense that each request+response is supposedly independent from > any other request+response. But HTTP 1.1 explicitly introduces > "persistent" TCP connections. Yes, and HTTP sessions are standard fare these days, too. But the fact is that HTTP itself is connection-less. We as engineers can make it feel like it's not and do stupid things like put JDBC connections into HttpSession objects and try to tie everything together to make the user feel like they have a permanent connection. We can even hold-open HTTP connections for long periods of time, but that's really abuse of the protocol IMO. You can send bowling balls via carrier pigeon, but there are better ways to send bowling balls. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRSwfNAAoJEBzwKT+lPKRYAMgQAKyONnliLXad6HDwO9raxN+d evcEl8zAeYr6vbevZJ/KJK/FALoFVOmHdMDj+twGEWM+zrIOkHel2y9LHKzxR+St 6Fz1466yDeHM45D/PBcyMow2WaOSR9a6Ewj8uDprJLuVjT20qRlaiw0pQjvfB5M2 rPfX0rEP6NPMQNaTTdaTiq56LP4j/kNMiIhNZyZrq3Gu+9hP/LGEZgKW4j9PDPRF wvNUnWrHwhl4cUJwtRF1CuyynmJmnsrglQWpLgj1cYvBnzHp/19I3CKUevut5JUj NtcCmZ+u/is9zsJbWn6g1yRpyVFNForyV2XF2UFMDm/4UO+Ofyq1lVsGtvkMu3b2 2PQ7vMPqMM34JBySI3ZWVMFxD3GZUMm+Bqc4H5iKIzcGxRg0MgQn5z6DHniuIOmw lUxsjiwHiJ8xF/W3cdN1cxzPPzG92MOp4FWpsnMF+XcAN8ctGr5MuRJzDJKfct1o VcQojNqhmDyBHlJd3188aAz94KUXIGyXkmsLNdvnYhSZLZWxjFwBNxYm/4RzmHeA Dm/Heoe+qpxsk868YGKvJcIAk/1Rdxje8ZEJv44YRNXyCqfDkq0t9HUCduzyNBJF 4H/RVCSSS6OEXvdXUMywS2JJElcss560fSZ1ZF45YSW6NiLMIyl5PjFR1mb0Kfsf YYwN2L9egDE8ZDibeON2 =Bxsy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
Christopher, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 3/20/13 2:25 PM, André Warnier wrote: Saurabh Agrawal wrote: All our assets are served from L3 CDN. So the asset requests never come to the application server. That, I do not understand. I do not understand what you mean by "assets" here, and I do not understand "L3 CDN". So I cannot tell of this is relevant or not to the problem. CDN = Content Delivery Network. I'm not sure what "L3" (probably "Level 3", a data center operations company) is, but a CDN is basically a whole bunch of copies of your files geographically distributed such that requesting a file always gets the bits that are closest to you. Kind of a cool thing. ;) Thank your for the above Rosetta Stone. This computer business os so full of acronyms of all kinds - some of them with multiple interpretations - that it is sometimes difficult to grasp the meaning. And I really don't feel like having to use Wikipedia every 3 words of a post on the list. Not when "static content is delivered by the Apache front-end" would have done it. The bottom line is that Saurabh expects only dynamic requests to come to Tomcat, so keepalives should be much less useful than if Tomcat were to be serving everything. Imagine httpd out front serving all static content and forwarding dynamic stuff to Tomcat via AJP -- that's almost exactly what's going on here, except that the static stuff is being served very efficiently from a network-topology perspective. Since AJP is in use, keepalive is almost entirely a red herring as typical AJP connections are permanently-connected to the web server. Well, I would say so indeed forthe case of a html page wit embedded images e.g. Butit may not be so in the "benchmark" case that Saurabh explained, with each of the 1 clients making multiple requests to non-static content, presumably served by Tomcat. A human user may have delays, that his testcase might not have. So, by default, the keepAliveTimeout [for AJP] is set to "infinite". [snip] And if the client keeps the connection open, but does not send any additional request on that connection, the Thread will wait theoretically forever (because that is what the documentation says about the default value of these parameters). No, the defaults are different for non-AJP connections. Tomcat's default default is 60 seconds but the stock server.xml configures it to 20 seconds. Right. But my explanation was meant as an example only, to point out the interlinked effects of the various attributes and timeouts. And 20 seconds is still an incredibly long time, in the context of 1 "simultaneous" clients sending multiple requests each. Now your case is a bit different, because - you are not using the HTTP BIO connector (you use AJP) I think you've gotten yourself confused, here, unfortunately. You can use AJP with BIO, NIO, or APR (maybe you mixed-up AJP and APR between your eyes and your brain... the two are honestly too close to each other and it is very easy to do that). Yes, I was confused and thank you for making me see the light. I though that the AJP Connector was a beast all of it's own, and did not "use" these different underlying layers. It is clear fom the documentation that it does though, I don't know how I could have overlooked that for so long. He is in fact using the BIO connector because he has specified protocol="org.apache.coyote.ajp.AjpProtocol". - in front of your Tomcat, is an Apache httpd server. This server has its own keep-alive settings which apply to the connection of the client with Apache httpd. And these keep-alive settings are a bit different from the Tomcat ones (for example, there is a keep-alive timeout, but also a MaxKeepAliveRequests) +1 - between Apache httpd and Tomcat, there is the mod_jk module in Apache, and that module uses its own timeouts (as set in workers.properties), and in addition it uses itself a pool of connections to Tomcat, and this pool of connections has its own rules for keeping alive a connection between Apache and Tomcat. But the basic principles above apply, and may explain why you are seeing what appears to be one Thread dedicated to one client, forever. I think there might be a problem with the instrumentation, or just coincidences at a fairly implausible level. The trust of the matter is that Tomcat does not allocate a thread permanently to a remote client until ... whenever the client "disconnects" (whatever that means, as HTTP is a connection-less protocol). (See the nitpick (*) below) Possible, but see above again with the httpd/tomcat connections managed by the mod_jk module. It does have and manage its own pool of connections, with each connection potentially "staying alive" for a time much longer than any individual client request. I do not deny that. But what I am not so sure of (and maybe Rainer could comment here) is this scenario : - a client,
