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
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?
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
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.
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.
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 :)
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
