On 05.06.2009 23:34, Jason Joseph wrote: > Rainer Jung wrote: >> On 05.06.2009 22:04, Christopher Schultz wrote: >> >>> Chuck, >>> >>> On 6/5/2009 1:17 PM, Caldarale, Charles R wrote: >>> >>>>> From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: concurrent >>>>> connections with mod_jk/apache/tomcat >>>>> >>>>> The only time when a browser would fire off "simultaneous" >>>>> requests, is if there were several windows or frames open, each >>>>> making its own connection, and requests on it. >>>>> >>>> Not true; a browser will normally open extra connections for any >>>> objects associated with a page, including style sheets, embedded >>>> images, applets, etc. >>>> >>> Yes, and this appears to be the case that the OP gave: firebug in fact >>> shows that some resources are fetched /before/ the last byte of the >>> parent request is received. But, of course, only for Tomcat standalone. >>> >>> > I remember when Mozilla used to have a plugin that allowed you to "speed > up browsing" by increasing the amount of simultaneous open connections > you had but they suggested against numbers higher than 2 because it was > "against the HTTP1.1 spec" :) >> >> for 4KB I would expect, that the full response comes from Tomcat in one >> single AJP body packet (plus one header packet) and the buffering would >> then happen inside Tomcat. >> >> The OP could switch to JkLogLevel trace, so he would notice each AJP >> packet coming in from Tomcat with its hex dump and verify, that there is >> one header packet and then only one packet with the full body. >> >> > http://www.myownbriefcase.com/apache_mod_jk.log > Here is my mod_jk log with LogLevel trace on. This was cleared prior to > running this so it is for a single request. As far as I can tell there > is only one header packet... > > [debug] ajp_unmarshal_response::jk_ajp_common.c (615): Number of headers > is = 1
No this is the number of HTTP headers contained in the response. but nevertheless its only one header packet received from ajp13 pos=0 len=51 max=8192 but the following body packets are the more interesting: received from ajp13 pos=0 len=2281 max=8192 <!DOCTYPE html ... <a href="/WebApp_ID/public/logout.action".class="thf_line"> followed by received from ajp13 pos=0 len=14 max=8192 logout</a> and then many more packets: received from ajp13 pos=0 len=2746 max=8192 received from ajp13 pos=0 len=149 max=8192 received from ajp13 pos=0 len=979 max=8192 received from ajp13 pos=0 len=6532 max=8192 received from ajp13 pos=0 len=303 max=8192 received from ajp13 pos=0 len=362 max=8192 received from ajp13 pos=0 len=2302 max=8192 received from ajp13 pos=0 len=15 max=8192 received from ajp13 pos=0 len=177 max=8192 in sum about 16KB in a total of 11 body packets. So it might well be, that they were buffered by Apache and recombined in different chunks to be sent out. > I assume that means only one body packet was sent as well? I am having a > little trouble deciphering all of the log but I believe its all one body > packet after that? See above. >> If so, the only possibility would be to already try to flush inside >> Tomcat, possibly combined with ... >> >>> JkOptions +FlushHeader +FlushPackets >>> >> >> in order to make the flush also effective for httpd. >> >> > This definitely fixed the issue! +FlushHeader did not seem to have any > effect but +FlushPackets definitely changed the behavior so it was > acting like Tomcat direct. Here are the results... > > http://207.7.102.90/~thecorp/apache-ajp-withflush.jpg > http://www.myownbriefcase.com/apache_mod_jk-withflush.log Yes, in this log we can see, that shortly after the first body packet comes back from Tomcat, the browser already starts to retrieve embedded page objects, so Apache must have send out the first body packet immediately. > Just reading through the documentation for FlushPackets it states, "This > option can have a strong performance penalty for Apache and Tomcat as > writes are performed more often than would normally be required (ie: at > the end of each response)." Is this something I should be concerned > about? I am most likely not going to be going with the AJP solution > considering your comments regarding Tomcat's performance until I see > some more compelling reason to start using Apache. It depends :) But what will be the resources used additionally by the overhead of sending more packets: - a bit more cpu - packets per second thoughput on TCP - bandwidth due to more TCP packet headers I would expect all those to be very minor relative to the amount of resources available on modern systems. So in general you don't want to always flush just because of general rules of careful resource usage. In your case, if you want to drive latency down as much as possible, it could be a viable decision to add the flush option. >>> Setting +FlushPackets will make mod_jk send the bytes it receives from >>> Tomcat /immediately/ with no further buffering (other than the size of >>> an AJP packet, which is allegedly limited to 8KiB). >>> >>> Another option would be to use mox_proxy_http instead of mod_jk, which >>> may have other buffering options to play with. >>> >> >> Regards, >> >> Rainer >> > As a side note to Chris, no matter what I did, the size of the > employerBriefcase.action through Tomcat was 16kB and 4kB through AJP. > Although as you can see in the last picture with flush enabled the > action is now 5kB. I think I have figured it out though, I just realized > I have mod_deflate enabled for Apache. Would that apply to data coming > back from the AJP connector as well? Thats my best guess as to the > discrepancy you noticed. Yes, it would. And I wouldn't be surprised, if that was already causing most of your problems. I expect mod_deflate to buffer bigger chunks in order to be able to compress efficiently. You could retest without mod_deflate and without the additional flush configuration just for the complete understanding. > Thanks again for helping me figure this out, definitely an interesting > issue, I think I am beginning to understand the whole connection/HTTP > process a little better now :) Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
