You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerry Lampi <ja...@sdsusa.com> on 2013/07/12 20:16:38 UTC
Enabling protocol="org.apache.coyote.http11.Http11NioProtocol" causes
tomcat 6.0.36 to load web page elements
When we switched from tomcat 6.0.35 to 6.0.36, the initial load of our sign
on page became extremely slow. In 6.0.35, it would load in about 2
seconds; in 6.0.36, it loads in about 60 seconds.
Our environment is an IBM mainframe running z/OS. Tomcat runs under USS
(Unix System Services). The JVM version is java version "1.6.0" Java(TM)
SE Runtime Environment (build pmz3160sr13-20130207_01(SR13)).
When we remove the protocol="org.apache.coyote.http11.Http11NioProtocol"
from the server.xml, the page loads in about 2 seconds -- the same a tomcat
version 6.0.35.
So I have narrowed this down to one configuration change. We need to have
NIO enabled, as we use Netty to do some of our IO; therefore, leaving the
option disabled is not possible for us.
I ran Wireshark against 6.0.35 and 6.0.36 with NIO enabled hoping to see a
large discrepancy in the number of packets sent, but the packet counts were
very similar.
I ran Fiddler and did see that files over 50KB in size were the slow ones;
oddly, jar files (we have a swing applet on our sign on page) that were
much larger than the slower .gif and .js files, were served very quickly.
I am not sure how to proceed.
Jerry
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Jerry Lampi <ja...@sdsusa.com>.
On 7/17/2013 2:57 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jerry,
>
> On 7/17/13 3:30 PM, Jerry Lampi wrote:
>> On 7/17/2013 2:28 PM, Christopher Schultz wrote: Jerry,
>>
>> On 7/17/13 3:06 PM, Jerry Lampi wrote:
>>>>> Good news. I previously reported that sendFile was not
>>>>> enabled.
>>>>>
>>>>> As stated below by folks more knowledgeable than I, sendFile
>>>>> is enabled by default.
>>>>>
>>>>> I added this line to my server.xml file Connector:
>>>>> useSendfile="false" and now every page element loads very
>>>>> quickly. Problem solved.
>> That's kind of what I was hoping. Honestly, sendFile *should* be
>> enabled as it should be more efficient, but something is obviously
>> going wrong.
>>
>>>>> So it appears that sendFile became broken (at least in my
>>>>> USS implementation) in version 6.0.36 and beyond.
>>>>>
>>>>> Should I open an issue for this? In 6.0.35, sendFile seemed
>>>>> fine, in 6.0.36 and beyond (including 7.x), it is not fine.
>> Are you always using the same JVM version when testing these
>> against one another?
>>> Yes. Same JVM. I had another idea. I wonder if tomcat 6.0.35
>>> and below were never REALLY asking for sendFile? That would mean
>>> that the sendFile implementation on the IBM USS mainframe is
>>> faulty, but was not being exercised by tomcat until 6.0.36 and
>>> beyond. I find that possible, as we have had to debug other
>>> issues on that platform.
> The only related issue I see in the changelog for 6.0.36 is:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52858
Following 52858 led me to
https://issues.apache.org/bugzilla/show_bug.cgi?id=53138.
It appears that this exact change:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?r1=1372035&r2=1372034&pathrev=1372035
re-activated sendFile on 6.0.36. This seems to have caused slow
(inefficient) code to be run on the IBM USS Mainframe. Specifically, the
line that was commented out:
//unreg(sk,attachment);//only do this if we do process send file on a separate thread
Now is not:
unreg(sk, attachment, sk.readyOps());
So this issue's description may be summarized better as "The
implementation of sendFile on the IBM USS Mainframe JVM is slow and
inefficient".
I am pretty happy with that answer.
Jerry
>
> Since the file-fetches seem to take a really long time, would you be
> able to get a few thread dumps during those times? It might point to
> what operation is stalling.
>
> - -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/
>
> iQIcBAEBCAAGBQJR5vctAAoJEBzwKT+lPKRYs2AP/2XqZnRbzEHrle0cSOWQASP9
> KeCEh2fCbw/6lD8/OK2UYnAZtFIXY4vPXbZ0VQIUT5QSdaL23x573k3HV4t+MniV
> DF6yWyW0CHkrnn/9qkANwpF7EZ/mmShDs9nxE6ek3levCwsM/0NR/mlD8IsSEO8q
> p7ARxQZFl7so29ufMZD7OmhUoGqlmdlbHVPFj6FIQrlJRwlUCBSubdxXyxCLWq90
> 0jJerXlRsuRfzBWx3l2374Uon2euLRI7nVjxhD4u+AqZjEqth6MR3uj2Jm+Dh18N
> /Y5j7olTU3Tv360k56mhNTQej8yrC2PwOsXzAzYIRnx7jNrZIgpqPWxseX+cDksU
> Za1gWY18a6vXtfULY7NTGFZe4/4VDTE4W9fPTrOt6NIEBK8WdKlktNj2m7LRGvGg
> Eb27x9ZfXFw8xysbwARYONQaSWNK5MG7kVVAjkrkziWsePG7Vwn0h8QiXxazCi7m
> cDa1T0HxUruvcIED0lsZ6zBOWToo95uCNpDURhr/vtdX5LCYrt7PVbt7cnAwf4Kp
> RfSAYuw/XhxBu01v19tDXiWeqsxafImVEZ9/ZwFSRiO8eIwQWQHHK1q5DQbH6kG6
> 0M2dbh7dXu1Jv9T9P0PpAjNMNkqpnN71iFWZ87UZ6RZ2xtbIi9Y1fV2WCuekq8ZA
> xozOBdx4Ujl2mR9phfJq
> =nyis
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 7/17/13 3:30 PM, Jerry Lampi wrote:
> On 7/17/2013 2:28 PM, Christopher Schultz wrote: Jerry,
>
> On 7/17/13 3:06 PM, Jerry Lampi wrote:
>>>> Good news. I previously reported that sendFile was not
>>>> enabled.
>>>>
>>>> As stated below by folks more knowledgeable than I, sendFile
>>>> is enabled by default.
>>>>
>>>> I added this line to my server.xml file Connector:
>>>> useSendfile="false" and now every page element loads very
>>>> quickly. Problem solved.
> That's kind of what I was hoping. Honestly, sendFile *should* be
> enabled as it should be more efficient, but something is obviously
> going wrong.
>
>>>> So it appears that sendFile became broken (at least in my
>>>> USS implementation) in version 6.0.36 and beyond.
>>>>
>>>> Should I open an issue for this? In 6.0.35, sendFile seemed
>>>> fine, in 6.0.36 and beyond (including 7.x), it is not fine.
> Are you always using the same JVM version when testing these
> against one another?
>> Yes. Same JVM. I had another idea. I wonder if tomcat 6.0.35
>> and below were never REALLY asking for sendFile? That would mean
>> that the sendFile implementation on the IBM USS mainframe is
>> faulty, but was not being exercised by tomcat until 6.0.36 and
>> beyond. I find that possible, as we have had to debug other
>> issues on that platform.
The only related issue I see in the changelog for 6.0.36 is:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52858
Since the file-fetches seem to take a really long time, would you be
able to get a few thread dumps during those times? It might point to
what operation is stalling.
- -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/
iQIcBAEBCAAGBQJR5vctAAoJEBzwKT+lPKRYs2AP/2XqZnRbzEHrle0cSOWQASP9
KeCEh2fCbw/6lD8/OK2UYnAZtFIXY4vPXbZ0VQIUT5QSdaL23x573k3HV4t+MniV
DF6yWyW0CHkrnn/9qkANwpF7EZ/mmShDs9nxE6ek3levCwsM/0NR/mlD8IsSEO8q
p7ARxQZFl7so29ufMZD7OmhUoGqlmdlbHVPFj6FIQrlJRwlUCBSubdxXyxCLWq90
0jJerXlRsuRfzBWx3l2374Uon2euLRI7nVjxhD4u+AqZjEqth6MR3uj2Jm+Dh18N
/Y5j7olTU3Tv360k56mhNTQej8yrC2PwOsXzAzYIRnx7jNrZIgpqPWxseX+cDksU
Za1gWY18a6vXtfULY7NTGFZe4/4VDTE4W9fPTrOt6NIEBK8WdKlktNj2m7LRGvGg
Eb27x9ZfXFw8xysbwARYONQaSWNK5MG7kVVAjkrkziWsePG7Vwn0h8QiXxazCi7m
cDa1T0HxUruvcIED0lsZ6zBOWToo95uCNpDURhr/vtdX5LCYrt7PVbt7cnAwf4Kp
RfSAYuw/XhxBu01v19tDXiWeqsxafImVEZ9/ZwFSRiO8eIwQWQHHK1q5DQbH6kG6
0M2dbh7dXu1Jv9T9P0PpAjNMNkqpnN71iFWZ87UZ6RZ2xtbIi9Y1fV2WCuekq8ZA
xozOBdx4Ujl2mR9phfJq
=nyis
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Jerry Lampi <ja...@sdsusa.com>.
On 7/17/2013 2:28 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jerry,
>
> On 7/17/13 3:06 PM, Jerry Lampi wrote:
>> Good news. I previously reported that sendFile was not enabled.
>>
>> As stated below by folks more knowledgeable than I, sendFile is
>> enabled by default.
>>
>> I added this line to my server.xml file Connector:
>> useSendfile="false" and now every page element loads very quickly.
>> Problem solved.
> That's kind of what I was hoping. Honestly, sendFile *should* be
> enabled as it should be more efficient, but something is obviously
> going wrong.
>
>> So it appears that sendFile became broken (at least in my USS
>> implementation) in version 6.0.36 and beyond.
>>
>> Should I open an issue for this? In 6.0.35, sendFile seemed fine,
>> in 6.0.36 and beyond (including 7.x), it is not fine.
> Are you always using the same JVM version when testing these against
> one another?
Yes. Same JVM.
I had another idea. I wonder if tomcat 6.0.35 and below were never
REALLY asking for sendFile? That would mean that the sendFile
implementation on the IBM USS mainframe is faulty, but was not being
exercised by tomcat until 6.0.36 and beyond. I find that possible, as
we have had to debug other issues on that platform.
Jerry
>
> - -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/
>
> iQIcBAEBCAAGBQJR5vBLAAoJEBzwKT+lPKRY0cgP/jwK3qxAw9t0GjOstJ2duCNa
> Sd9EbJ484lQjSXW5qcUY6ZAtna8X4JEU60cfe0Rb0dorns9lZFeH0r5sjwwJO7VN
> mQXkf7GgfD7JkW2hO/0e9k1vGBGk1Kpj7xJA78ynJivQ1G4dC67FRyxYgbaArEwZ
> BCFVfyIyVKaUlIe4RXuAu0aFmh5SsQXuU6Xo1b/KfFSpA+i8wNNQOPmdzjdMBMv2
> RVaqDmTZOY4z6QkQVQoFXko60f9SBsUMj6OxX3p0mP/2HHlZYVEoof5mnm3K/Eyp
> rgOpkK1ia2UginBczbYABAcspaJuzQ+0m654djaB7aGVIYefEP9c2EM00rKNNnp+
> FAOXqdL2Rrt5ffpvPuarfDxYtJllU+YvLJhVgleVenvondhFKwkKwpn1nhEKKDrc
> 3dq4LQwIvAsYcqKF1FZeXzmGb2KJPXEVOW8yH++70ZAFwHnFkgIUdMn4OdjEKPvP
> t1rVHTe5A6TZdVuUwyX/uEgwN1kGBQfBTWJWMiT49a23B1JhimTPPH6zraiET9Q8
> DZcKCp0Ih2dMqriqBqoFsmmtbP16vnd+N9E0VO+GpYkXKpq/s7HbL/aTagbdh3vT
> hOsw2cmFnMU7TUKzFJBDEoPhTjNeUttMbwzFDU8JIuoM9HRuKdIPyzT2zj704dPz
> rv9moDdECjkzSDwyLilj
> =OT0P
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 7/17/13 3:06 PM, Jerry Lampi wrote:
> Good news. I previously reported that sendFile was not enabled.
>
> As stated below by folks more knowledgeable than I, sendFile is
> enabled by default.
>
> I added this line to my server.xml file Connector:
> useSendfile="false" and now every page element loads very quickly.
> Problem solved.
That's kind of what I was hoping. Honestly, sendFile *should* be
enabled as it should be more efficient, but something is obviously
going wrong.
> So it appears that sendFile became broken (at least in my USS
> implementation) in version 6.0.36 and beyond.
>
> Should I open an issue for this? In 6.0.35, sendFile seemed fine,
> in 6.0.36 and beyond (including 7.x), it is not fine.
Are you always using the same JVM version when testing these against
one another?
- -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/
iQIcBAEBCAAGBQJR5vBLAAoJEBzwKT+lPKRY0cgP/jwK3qxAw9t0GjOstJ2duCNa
Sd9EbJ484lQjSXW5qcUY6ZAtna8X4JEU60cfe0Rb0dorns9lZFeH0r5sjwwJO7VN
mQXkf7GgfD7JkW2hO/0e9k1vGBGk1Kpj7xJA78ynJivQ1G4dC67FRyxYgbaArEwZ
BCFVfyIyVKaUlIe4RXuAu0aFmh5SsQXuU6Xo1b/KfFSpA+i8wNNQOPmdzjdMBMv2
RVaqDmTZOY4z6QkQVQoFXko60f9SBsUMj6OxX3p0mP/2HHlZYVEoof5mnm3K/Eyp
rgOpkK1ia2UginBczbYABAcspaJuzQ+0m654djaB7aGVIYefEP9c2EM00rKNNnp+
FAOXqdL2Rrt5ffpvPuarfDxYtJllU+YvLJhVgleVenvondhFKwkKwpn1nhEKKDrc
3dq4LQwIvAsYcqKF1FZeXzmGb2KJPXEVOW8yH++70ZAFwHnFkgIUdMn4OdjEKPvP
t1rVHTe5A6TZdVuUwyX/uEgwN1kGBQfBTWJWMiT49a23B1JhimTPPH6zraiET9Q8
DZcKCp0Ih2dMqriqBqoFsmmtbP16vnd+N9E0VO+GpYkXKpq/s7HbL/aTagbdh3vT
hOsw2cmFnMU7TUKzFJBDEoPhTjNeUttMbwzFDU8JIuoM9HRuKdIPyzT2zj704dPz
rv9moDdECjkzSDwyLilj
=OT0P
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by André Warnier <aw...@ice-sa.com>.
André Warnier wrote:
> Jerry Lampi wrote:
>> Good news. I previously reported that sendFile was not enabled.
>>
>> As stated below by folks more knowledgeable than I, sendFile is
>> enabled by default.
>>
>> I added this line to my server.xml file Connector:
>> useSendfile="false"
>> and now every page element loads very quickly. Problem solved.
>>
>> So it appears that sendFile became broken (at least in my USS
>> implementation) in version 6.0.36 and beyond.
>>
>> Should I open an issue for this? In 6.0.35, sendFile seemed fine, in
>> 6.0.36 and beyond (including 7.x), it is not fine.
>
> If you do, make sure that you specify the precise version(s) of Windows
> under which this occurs. See my note (1) below, where I experienced the
> same problem under Apache httpd, not Tomcat.
> And show you precise <Connector> configuration in the report too.
>
Oops, take that back, you are not under Windows. Replace "Windows" by "OS" above.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by André Warnier <aw...@ice-sa.com>.
Jerry Lampi wrote:
> Good news. I previously reported that sendFile was not enabled.
>
> As stated below by folks more knowledgeable than I, sendFile is enabled
> by default.
>
> I added this line to my server.xml file Connector:
> useSendfile="false"
> and now every page element loads very quickly. Problem solved.
>
> So it appears that sendFile became broken (at least in my USS
> implementation) in version 6.0.36 and beyond.
>
> Should I open an issue for this? In 6.0.35, sendFile seemed fine, in
> 6.0.36 and beyond (including 7.x), it is not fine.
If you do, make sure that you specify the precise version(s) of Windows under which this
occurs. See my note (1) below, where I experienced the same problem under Apache httpd,
not Tomcat.
And show you precise <Connector> configuration in the report too.
>
> Thanks for all of your advice.
>
> Jerry
>
> On 7/12/2013 7:37 PM, André Warnier wrote:
>> Konstantin Kolinko wrote:
>>> 2013/7/13 Jerry Lampi <ja...@sdsusa.com>:
>>>> On Fri, Jul 12, 2013 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>>>>
>>>>> Jerry Lampi wrote:
>>>>>
>>>>>> On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
>>>>>> chris@christopherschultz.net> wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA256
>>>>>>>
>>>>>>> Jerry,
>>>>>>>
>>>>>>> On 7/12/13 2:16 PM, Jerry Lampi wrote:
>>>>>>>
>>>>>>>> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
>>>>>>>> our sign on page became extremely slow. In 6.0.35, it would load
>>>>>>>> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>>>>>>>>
>>>
>>> Why not to try with the current version (6.0.37 or 7.0.42)?
>>>
>>>>>> sendFile is not enabled.
>>>>>>
>>>
>>> Can you prove the above (with an explanation or with a configuration
>>> snippet)?
>>> On your <Connector> below you have it enabled. (Well, it is not the
>>> only place where you can disable it).
>>>
>>>>> Pity. That /would/ have been a clue..
>>>>>
>>>>>
>>>
>>> Yeah. By default sendfile is used when file size >=48Kb.
>>>
>>> Does it happen with static files only? If you have a JSP page that
>>> generates response with size >50Kb, would it experience similar
>>> delays?
>>>
>>>>> 10 200 /sdsvip/vip.css 1,611
>>>>> 00:00:00.0090005 1836
>>>>> 11 200 /sdsvip/vip.js 50,982
>>>>> 00:00:07.1194072 51216
>>>
>>> 7s might be enough to try to take a thread dump or two (to see what is
>>> actually happens at the server).
>>>
>>> If you configure an AccessLogValve on the server, does it show the
>>> same timings?
>>>
>>>> To answer your earlier question regarding connector:
>>>> <Connector port="${httpport}"
>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>> connectionLinger="-1" maxThreads="300"
>>>> maxKeepAliveRequests="-1"
>>>> socket.rxBufSize="125940" socket.txBufSize="219000"
>>>
>>> Why connectionLinger="-1" and why such excessive buffer sizes?
>>>
>>>> backlog="50"
>>>
>>> No such property is mentioned in documentation.
>>>
>>>> connectionTimeout="20000"
>>>> address="${weburl}"
>>>> redirectPort="${sslport}" />
>>>>
>>>
>>> How far are you from the server?
>>>
>>
>> 1) if sendfile() is being used, that may be a cause. In a different
>> context (Apache httpd under Windows 2003 server) I remember having had
>> to disable sendfile, because the OS implementation had a bug and it
>> triggered just this kind of behaviour : erratic very long response
>> times for some requests. Just disabling sendfile solved that issue.
>>
>> 2) about the buffer sizes : I wonder if that does not deserve further
>> attention. It may be that the fact that some files seem to get served
>> after a long delay is due just to the order in which they are being
>> served, and to some more or less full condition of the send buffer. It
>> is a buffer at the socket (connection) level, so presumably it could
>> accumulate the responses of several requests before getting flushed.
>> Would it be possible to change the order of the files being included
>> in the login page, and see if the delay still occurs for the same
>> files ? (and/or reduce the socket.txBufSize and check your times again).
>> Also, Constantin's suggestion for an AccessLog may show differences
>> between Tomcat's and the browser's perspective. Maybe for Tomcat,
>> these requests are served in a normal time, but they just take a long
>> time to reach the browser.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Jerry Lampi <ja...@sdsusa.com>.
Good news. I previously reported that sendFile was not enabled.
As stated below by folks more knowledgeable than I, sendFile is enabled
by default.
I added this line to my server.xml file Connector:
useSendfile="false"
and now every page element loads very quickly. Problem solved.
So it appears that sendFile became broken (at least in my USS
implementation) in version 6.0.36 and beyond.
Should I open an issue for this? In 6.0.35, sendFile seemed fine, in
6.0.36 and beyond (including 7.x), it is not fine.
Thanks for all of your advice.
Jerry
On 7/12/2013 7:37 PM, André Warnier wrote:
> Konstantin Kolinko wrote:
>> 2013/7/13 Jerry Lampi <ja...@sdsusa.com>:
>>> On Fri, Jul 12, 2013 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>>>
>>>> Jerry Lampi wrote:
>>>>
>>>>> On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
>>>>> chris@christopherschultz.net> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>>
>>>>>> Jerry,
>>>>>>
>>>>>> On 7/12/13 2:16 PM, Jerry Lampi wrote:
>>>>>>
>>>>>>> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
>>>>>>> our sign on page became extremely slow. In 6.0.35, it would load
>>>>>>> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>>>>>>>
>>
>> Why not to try with the current version (6.0.37 or 7.0.42)?
>>
>>>>> sendFile is not enabled.
>>>>>
>>
>> Can you prove the above (with an explanation or with a configuration
>> snippet)?
>> On your <Connector> below you have it enabled. (Well, it is not the
>> only place where you can disable it).
>>
>>>> Pity. That /would/ have been a clue..
>>>>
>>>>
>>
>> Yeah. By default sendfile is used when file size >=48Kb.
>>
>> Does it happen with static files only? If you have a JSP page that
>> generates response with size >50Kb, would it experience similar
>> delays?
>>
>>>> 10 200 /sdsvip/vip.css 1,611
>>>> 00:00:00.0090005 1836
>>>> 11 200 /sdsvip/vip.js 50,982
>>>> 00:00:07.1194072 51216
>>
>> 7s might be enough to try to take a thread dump or two (to see what is
>> actually happens at the server).
>>
>> If you configure an AccessLogValve on the server, does it show the
>> same timings?
>>
>>> To answer your earlier question regarding connector:
>>> <Connector port="${httpport}"
>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> connectionLinger="-1" maxThreads="300"
>>> maxKeepAliveRequests="-1"
>>> socket.rxBufSize="125940" socket.txBufSize="219000"
>>
>> Why connectionLinger="-1" and why such excessive buffer sizes?
>>
>>> backlog="50"
>>
>> No such property is mentioned in documentation.
>>
>>> connectionTimeout="20000"
>>> address="${weburl}"
>>> redirectPort="${sslport}" />
>>>
>>
>> How far are you from the server?
>>
>
> 1) if sendfile() is being used, that may be a cause. In a different
> context (Apache httpd under Windows 2003 server) I remember having had
> to disable sendfile, because the OS implementation had a bug and it
> triggered just this kind of behaviour : erratic very long response
> times for some requests. Just disabling sendfile solved that issue.
>
> 2) about the buffer sizes : I wonder if that does not deserve further
> attention. It may be that the fact that some files seem to get served
> after a long delay is due just to the order in which they are being
> served, and to some more or less full condition of the send buffer. It
> is a buffer at the socket (connection) level, so presumably it could
> accumulate the responses of several requests before getting flushed.
> Would it be possible to change the order of the files being included
> in the login page, and see if the delay still occurs for the same
> files ? (and/or reduce the socket.txBufSize and check your times again).
> Also, Constantin's suggestion for an AccessLog may show differences
> between Tomcat's and the browser's perspective. Maybe for Tomcat,
> these requests are served in a normal time, but they just take a long
> time to reach the browser.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
> 2013/7/13 Jerry Lampi <ja...@sdsusa.com>:
>> On Fri, Jul 12, 2013 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>>
>>> Jerry Lampi wrote:
>>>
>>>> On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
>>>> chris@christopherschultz.net> wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> Jerry,
>>>>>
>>>>> On 7/12/13 2:16 PM, Jerry Lampi wrote:
>>>>>
>>>>>> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
>>>>>> our sign on page became extremely slow. In 6.0.35, it would load
>>>>>> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>>>>>>
>
> Why not to try with the current version (6.0.37 or 7.0.42)?
>
>>>> sendFile is not enabled.
>>>>
>
> Can you prove the above (with an explanation or with a configuration snippet)?
> On your <Connector> below you have it enabled. (Well, it is not the
> only place where you can disable it).
>
>>> Pity. That /would/ have been a clue..
>>>
>>>
>
> Yeah. By default sendfile is used when file size >=48Kb.
>
> Does it happen with static files only? If you have a JSP page that
> generates response with size >50Kb, would it experience similar
> delays?
>
>>> 10 200 /sdsvip/vip.css 1,611
>>> 00:00:00.0090005 1836
>>> 11 200 /sdsvip/vip.js 50,982
>>> 00:00:07.1194072 51216
>
> 7s might be enough to try to take a thread dump or two (to see what is
> actually happens at the server).
>
> If you configure an AccessLogValve on the server, does it show the same timings?
>
>> To answer your earlier question regarding connector:
>> <Connector port="${httpport}"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> connectionLinger="-1" maxThreads="300"
>> maxKeepAliveRequests="-1"
>> socket.rxBufSize="125940" socket.txBufSize="219000"
>
> Why connectionLinger="-1" and why such excessive buffer sizes?
>
>> backlog="50"
>
> No such property is mentioned in documentation.
>
>> connectionTimeout="20000"
>> address="${weburl}"
>> redirectPort="${sslport}" />
>>
>
> How far are you from the server?
>
1) if sendfile() is being used, that may be a cause. In a different context (Apache httpd
under Windows 2003 server) I remember having had to disable sendfile, because the OS
implementation had a bug and it triggered just this kind of behaviour : erratic very long
response times for some requests. Just disabling sendfile solved that issue.
2) about the buffer sizes : I wonder if that does not deserve further attention. It may
be that the fact that some files seem to get served after a long delay is due just to the
order in which they are being served, and to some more or less full condition of the send
buffer. It is a buffer at the socket (connection) level, so presumably it could accumulate
the responses of several requests before getting flushed.
Would it be possible to change the order of the files being included in the login page,
and see if the delay still occurs for the same files ? (and/or reduce the socket.txBufSize
and check your times again).
Also, Constantin's suggestion for an AccessLog may show differences between Tomcat's and
the browser's perspective. Maybe for Tomcat, these requests are served in a normal time,
but they just take a long time to reach the browser.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/7/13 Jerry Lampi <ja...@sdsusa.com>:
> On Fri, Jul 12, 2013 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Jerry Lampi wrote:
>>
>>> On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
>>> chris@christopherschultz.net> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> Jerry,
>>>>
>>>> On 7/12/13 2:16 PM, Jerry Lampi wrote:
>>>>
>>>>> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
>>>>> our sign on page became extremely slow. In 6.0.35, it would load
>>>>> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>>>>>
Why not to try with the current version (6.0.37 or 7.0.42)?
>>>
>>> sendFile is not enabled.
>>>
Can you prove the above (with an explanation or with a configuration snippet)?
On your <Connector> below you have it enabled. (Well, it is not the
only place where you can disable it).
>>
>> Pity. That /would/ have been a clue..
>>
>>
Yeah. By default sendfile is used when file size >=48Kb.
Does it happen with static files only? If you have a JSP page that
generates response with size >50Kb, would it experience similar
delays?
>> 10 200 /sdsvip/vip.css 1,611
>> 00:00:00.0090005 1836
>> 11 200 /sdsvip/vip.js 50,982
>> 00:00:07.1194072 51216
7s might be enough to try to take a thread dump or two (to see what is
actually happens at the server).
If you configure an AccessLogValve on the server, does it show the same timings?
> To answer your earlier question regarding connector:
> <Connector port="${httpport}"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> connectionLinger="-1" maxThreads="300"
> maxKeepAliveRequests="-1"
> socket.rxBufSize="125940" socket.txBufSize="219000"
Why connectionLinger="-1" and why such excessive buffer sizes?
> backlog="50"
No such property is mentioned in documentation.
> connectionTimeout="20000"
> address="${weburl}"
> redirectPort="${sslport}" />
>
How far are you from the server?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Jerry Lampi <ja...@sdsusa.com>.
On Fri, Jul 12, 2013 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
> Jerry Lampi wrote:
>
>> On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
>> chris@christopherschultz.net> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Jerry,
>>>
>>> On 7/12/13 2:16 PM, Jerry Lampi wrote:
>>>
>>>> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
>>>> our sign on page became extremely slow. In 6.0.35, it would load
>>>> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>>>>
>>> Can you be more specific? Is it the "sign-in page" resource that takes
>>> 60-seconds to load, or do you mean the sign-in page plus all of its
>>> associated resources (graphics, css, applets, etc.)?
>>>
>>> The sign on page plus all of its associated resources. There are 27
>> page
>> resources. 3 of them (vipIndexPageAnim.gif, vip.js, and !xRefArgsIds.js)
>> are
>> slow. Here is the Fiddler trace:
>> # Result URL Body Overall_Elapsed
>> ResponseSize
>> 1 302 /sdsvip 5
>> 00:00:00.0150009 156
>> 2 200 /sdsvip/ 1,443
>> 00:00:00.0050003 1669
>> 3 200 /sdsvip/index0.html 3,964
>> 00:00:00.0070004 4190
>> 4 200 /sdsvip/ivorybkg.gif 18,659
>> 00:00:00.0100005 18887
>> 5 200 /sdsvip/vipIndexPageAnim.gif 63,007
>> 00:00:06.1323508 63235
>> 6 200 /sdsvip/sdsLogo.120.gif 2,239
>> 00:00:00.0090005 2465
>> 7 200 /sdsvip/ivorybkg.gif 18,659
>> 00:00:00.0100006 18887
>> 8 200 /favicon.ico 2,102
>> 00:00:00.0070004 2303
>> 9 200 /sdsvip/servlets/SDSM0100 6,414
>> 00:00:00.0160009 6691
>> 10 200 /sdsvip/vip.css 1,611
>> 00:00:00.0090005 1836
>> 11 200 /sdsvip/vip.js 50,982
>> 00:00:07.1194072 51216
>> 12 200 /sdsvip/helpVip/_js.js 6,409
>> 00:00:00.0080004 6641
>> 13 200 /sdsvip/spawnControl.js 8,513
>> 00:00:00.0100005 8745
>> 14 304 /sdsvip/ivorybkg.gif 0
>> 00:00:00.0090005 122
>> 15 304 /sdsvip/ivorybkg.gif 0
>> 00:00:00.0090005 122
>> 16 200 /sdsvip/helpVip/!tools.js 34,950
>> 00:00:00.0190011 35184
>> 17 200 /sdsvip/helpVip/_adminParms.js 658
>> 00:00:00.0080005 888
>> 18 200 /sdsvip/helpVip/_userParms.js 257
>> 00:00:00.0080005 487
>> 19 200 /sdsvip/helpVip/!xRefArgsIds.**js 54,828
>> 00:00:07.9134526 55062
>> 20 200 /sdsvip/VipSignOnApplet.jar 63,235
>> 00:00:00.0120006 63457
>> 21 200 .net /Root.crl 469
>> 00:00:00.1480085 837
>> 22 200 .net /primobject.crl 460
>> 00:00:00.1270072 828
>> 23 200 .net /ObjectSign.crl 16,253
>> 00:00:00.1470084 16623
>> 24 200 /sdsvip/resources.jar 232,214
>> 00:00:00.0500029 232405
>> 25 200 /sdsvip/commons-codec-1.4.jar 31,883
>> 00:00:00.0080005 32105
>> 26 200 /sdsvip/log4j.jar 154,491
>> 00:00:00.0550031 154714
>> All but three files are received at the browser well under sub-second. As
>> previously stated, the jar files, which are pretty big, also are received
>> sub-second. this is curious to me and may be a clue to amore
>> knowledgeable
>> person.
>>
>>
>>
>> Our environment is an IBM mainframe running z/OS. Tomcat runs
>>>> under USS (Unix System Services). The JVM version is java version
>>>> "1.6.0" Java(TM) SE Runtime Environment (build
>>>> pmz3160sr13-20130207_01(SR13))**.
>>>>
>>>> When we remove the
>>>> protocol="org.apache.coyote.**http11.Http11NioProtocol" from the
>>>> server.xml, the page loads in about 2 seconds -- the same a tomcat
>>>> version 6.0.35.
>>>>
>>> Is this over SSL or not?
>>>
>>> Not SSL.
>>
>> Does every page-load take 60-seconds or only the first time? What
>>> about other pages?
>>>
>>> Initial loads for each page are slow. Once a page element has been
>> cached
>> by the browser, the page loads instantly (i.e., when the web server
>> responds with a 304 result code: Not Modified).
>>
>> So I have narrowed this down to one configuration change. We need
>>>> to have NIO enabled, as we use Netty to do some of our IO;
>>>> therefore, leaving the option disabled is not possible for us.
>>>>
>>>> I ran Wireshark against 6.0.35 and 6.0.36 with NIO enabled hoping
>>>> to see a large discrepancy in the number of packets sent, but the
>>>> packet counts were very similar.
>>>>
>>>> I ran Fiddler and did see that files over 50KB in size were the
>>>> slow ones; oddly, jar files (we have a swing applet on our sign on
>>>> page) that were much larger than the slower .gif and .js files,
>>>> were served very quickly.
>>>>
>>> Are you using compression of any kind? Do you have sendFile enabled?
>>>
>>> No compression for basic resources (that is, no compression keywords
>> found
>> in server.xml). We do have a servlet named ContentType we use for
>> processing pack200 jar files. This is configured I the web.xml as
>> follows:
>> <servlet-mapping>
>> <servlet-name>ContentType</**servlet-name>
>> <url-pattern>*.jar</url-**pattern>
>> </servlet-mapping>
>>
>> sendFile is not enabled.
>>
>
> Pity. That /would/ have been a clue..
>
>
>
>> Here is a screencast showing the slow load to give you some context to the
>> Fiddler trace:
>> http://screencast.com/t/**zmJtsCvgpzTw<http://screencast.com/t/zmJtsCvgpzTw>
>>
>> Jerry
>>
>>
>> Are there an APR and a non-APR versions of the NIO Connector ? (I always
> get confused about that). If there are, what about switching to the other
> one ?
I just looked at page
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Connector%20Comparisonand
the APR will not be an option for us.
To answer your earlier question regarding connector:
<Connector port="${httpport}"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionLinger="-1" maxThreads="300"
maxKeepAliveRequests="-1"
socket.rxBufSize="125940" socket.txBufSize="219000"
backlog="50"
connectionTimeout="20000"
address="${weburl}"
redirectPort="${sslport}" />
I will have to run a test later where I remove the three items from the
page to see if it loads more quickly. I'm sure it would load faster, but
will do after weekend.
Jus to reiterate (as much for me as this group), the exact same web server
running under tomcat 6.0.35 works perfectly and loads quickly. When I
switch to 6.0.36, it loads slowly. Removing
protocol="org.apache.coyote.http11.Http11NioProtocol" in 6.0.36 results in
fast loads.
Jerry
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by André Warnier <aw...@ice-sa.com>.
Jerry Lampi wrote:
> On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Jerry,
>>
>> On 7/12/13 2:16 PM, Jerry Lampi wrote:
>>> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
>>> our sign on page became extremely slow. In 6.0.35, it would load
>>> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>> Can you be more specific? Is it the "sign-in page" resource that takes
>> 60-seconds to load, or do you mean the sign-in page plus all of its
>> associated resources (graphics, css, applets, etc.)?
>>
> The sign on page plus all of its associated resources. There are 27 page
> resources. 3 of them (vipIndexPageAnim.gif, vip.js, and !xRefArgsIds.js) are
> slow. Here is the Fiddler trace:
> # Result URL Body Overall_Elapsed
> ResponseSize
> 1 302 /sdsvip 5
> 00:00:00.0150009 156
> 2 200 /sdsvip/ 1,443
> 00:00:00.0050003 1669
> 3 200 /sdsvip/index0.html 3,964
> 00:00:00.0070004 4190
> 4 200 /sdsvip/ivorybkg.gif 18,659
> 00:00:00.0100005 18887
> 5 200 /sdsvip/vipIndexPageAnim.gif 63,007
> 00:00:06.1323508 63235
> 6 200 /sdsvip/sdsLogo.120.gif 2,239
> 00:00:00.0090005 2465
> 7 200 /sdsvip/ivorybkg.gif 18,659
> 00:00:00.0100006 18887
> 8 200 /favicon.ico 2,102
> 00:00:00.0070004 2303
> 9 200 /sdsvip/servlets/SDSM0100 6,414
> 00:00:00.0160009 6691
> 10 200 /sdsvip/vip.css 1,611
> 00:00:00.0090005 1836
> 11 200 /sdsvip/vip.js 50,982
> 00:00:07.1194072 51216
> 12 200 /sdsvip/helpVip/_js.js 6,409
> 00:00:00.0080004 6641
> 13 200 /sdsvip/spawnControl.js 8,513
> 00:00:00.0100005 8745
> 14 304 /sdsvip/ivorybkg.gif 0
> 00:00:00.0090005 122
> 15 304 /sdsvip/ivorybkg.gif 0
> 00:00:00.0090005 122
> 16 200 /sdsvip/helpVip/!tools.js 34,950
> 00:00:00.0190011 35184
> 17 200 /sdsvip/helpVip/_adminParms.js 658
> 00:00:00.0080005 888
> 18 200 /sdsvip/helpVip/_userParms.js 257
> 00:00:00.0080005 487
> 19 200 /sdsvip/helpVip/!xRefArgsIds.js 54,828
> 00:00:07.9134526 55062
> 20 200 /sdsvip/VipSignOnApplet.jar 63,235
> 00:00:00.0120006 63457
> 21 200 .net /Root.crl 469
> 00:00:00.1480085 837
> 22 200 .net /primobject.crl 460
> 00:00:00.1270072 828
> 23 200 .net /ObjectSign.crl 16,253
> 00:00:00.1470084 16623
> 24 200 /sdsvip/resources.jar 232,214
> 00:00:00.0500029 232405
> 25 200 /sdsvip/commons-codec-1.4.jar 31,883
> 00:00:00.0080005 32105
> 26 200 /sdsvip/log4j.jar 154,491
> 00:00:00.0550031 154714
> All but three files are received at the browser well under sub-second. As
> previously stated, the jar files, which are pretty big, also are received
> sub-second. this is curious to me and may be a clue to amore knowledgeable
> person.
>
>
>
>>> Our environment is an IBM mainframe running z/OS. Tomcat runs
>>> under USS (Unix System Services). The JVM version is java version
>>> "1.6.0" Java(TM) SE Runtime Environment (build
>>> pmz3160sr13-20130207_01(SR13)).
>>>
>>> When we remove the
>>> protocol="org.apache.coyote.http11.Http11NioProtocol" from the
>>> server.xml, the page loads in about 2 seconds -- the same a tomcat
>>> version 6.0.35.
>> Is this over SSL or not?
>>
> Not SSL.
>
>> Does every page-load take 60-seconds or only the first time? What
>> about other pages?
>>
> Initial loads for each page are slow. Once a page element has been cached
> by the browser, the page loads instantly (i.e., when the web server
> responds with a 304 result code: Not Modified).
>
>>> So I have narrowed this down to one configuration change. We need
>>> to have NIO enabled, as we use Netty to do some of our IO;
>>> therefore, leaving the option disabled is not possible for us.
>>>
>>> I ran Wireshark against 6.0.35 and 6.0.36 with NIO enabled hoping
>>> to see a large discrepancy in the number of packets sent, but the
>>> packet counts were very similar.
>>>
>>> I ran Fiddler and did see that files over 50KB in size were the
>>> slow ones; oddly, jar files (we have a swing applet on our sign on
>>> page) that were much larger than the slower .gif and .js files,
>>> were served very quickly.
>> Are you using compression of any kind? Do you have sendFile enabled?
>>
> No compression for basic resources (that is, no compression keywords found
> in server.xml). We do have a servlet named ContentType we use for
> processing pack200 jar files. This is configured I the web.xml as follows:
> <servlet-mapping>
> <servlet-name>ContentType</servlet-name>
> <url-pattern>*.jar</url-pattern>
> </servlet-mapping>
>
> sendFile is not enabled.
Pity. That /would/ have been a clue..
>
> Here is a screencast showing the slow load to give you some context to the
> Fiddler trace:
> http://screencast.com/t/zmJtsCvgpzTw
>
> Jerry
>
>
Are there an APR and a non-APR versions of the NIO Connector ? (I always get confused
about that). If there are, what about switching to the other one ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Jerry Lampi <ja...@sdsusa.com>.
On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jerry,
>
> On 7/12/13 2:16 PM, Jerry Lampi wrote:
> > When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
> > our sign on page became extremely slow. In 6.0.35, it would load
> > in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
>
> Can you be more specific? Is it the "sign-in page" resource that takes
> 60-seconds to load, or do you mean the sign-in page plus all of its
> associated resources (graphics, css, applets, etc.)?
>
The sign on page plus all of its associated resources. There are 27 page
resources. 3 of them (vipIndexPageAnim.gif, vip.js, and !xRefArgsIds.js) are
slow. Here is the Fiddler trace:
# Result URL Body Overall_Elapsed
ResponseSize
1 302 /sdsvip 5
00:00:00.0150009 156
2 200 /sdsvip/ 1,443
00:00:00.0050003 1669
3 200 /sdsvip/index0.html 3,964
00:00:00.0070004 4190
4 200 /sdsvip/ivorybkg.gif 18,659
00:00:00.0100005 18887
5 200 /sdsvip/vipIndexPageAnim.gif 63,007
00:00:06.1323508 63235
6 200 /sdsvip/sdsLogo.120.gif 2,239
00:00:00.0090005 2465
7 200 /sdsvip/ivorybkg.gif 18,659
00:00:00.0100006 18887
8 200 /favicon.ico 2,102
00:00:00.0070004 2303
9 200 /sdsvip/servlets/SDSM0100 6,414
00:00:00.0160009 6691
10 200 /sdsvip/vip.css 1,611
00:00:00.0090005 1836
11 200 /sdsvip/vip.js 50,982
00:00:07.1194072 51216
12 200 /sdsvip/helpVip/_js.js 6,409
00:00:00.0080004 6641
13 200 /sdsvip/spawnControl.js 8,513
00:00:00.0100005 8745
14 304 /sdsvip/ivorybkg.gif 0
00:00:00.0090005 122
15 304 /sdsvip/ivorybkg.gif 0
00:00:00.0090005 122
16 200 /sdsvip/helpVip/!tools.js 34,950
00:00:00.0190011 35184
17 200 /sdsvip/helpVip/_adminParms.js 658
00:00:00.0080005 888
18 200 /sdsvip/helpVip/_userParms.js 257
00:00:00.0080005 487
19 200 /sdsvip/helpVip/!xRefArgsIds.js 54,828
00:00:07.9134526 55062
20 200 /sdsvip/VipSignOnApplet.jar 63,235
00:00:00.0120006 63457
21 200 .net /Root.crl 469
00:00:00.1480085 837
22 200 .net /primobject.crl 460
00:00:00.1270072 828
23 200 .net /ObjectSign.crl 16,253
00:00:00.1470084 16623
24 200 /sdsvip/resources.jar 232,214
00:00:00.0500029 232405
25 200 /sdsvip/commons-codec-1.4.jar 31,883
00:00:00.0080005 32105
26 200 /sdsvip/log4j.jar 154,491
00:00:00.0550031 154714
All but three files are received at the browser well under sub-second. As
previously stated, the jar files, which are pretty big, also are received
sub-second. this is curious to me and may be a clue to amore knowledgeable
person.
>
> > Our environment is an IBM mainframe running z/OS. Tomcat runs
> > under USS (Unix System Services). The JVM version is java version
> > "1.6.0" Java(TM) SE Runtime Environment (build
> > pmz3160sr13-20130207_01(SR13)).
> >
> > When we remove the
> > protocol="org.apache.coyote.http11.Http11NioProtocol" from the
> > server.xml, the page loads in about 2 seconds -- the same a tomcat
> > version 6.0.35.
>
> Is this over SSL or not?
>
Not SSL.
>
> Does every page-load take 60-seconds or only the first time? What
> about other pages?
>
Initial loads for each page are slow. Once a page element has been cached
by the browser, the page loads instantly (i.e., when the web server
responds with a 304 result code: Not Modified).
>
> > So I have narrowed this down to one configuration change. We need
> > to have NIO enabled, as we use Netty to do some of our IO;
> > therefore, leaving the option disabled is not possible for us.
> >
> > I ran Wireshark against 6.0.35 and 6.0.36 with NIO enabled hoping
> > to see a large discrepancy in the number of packets sent, but the
> > packet counts were very similar.
> >
> > I ran Fiddler and did see that files over 50KB in size were the
> > slow ones; oddly, jar files (we have a swing applet on our sign on
> > page) that were much larger than the slower .gif and .js files,
> > were served very quickly.
>
> Are you using compression of any kind? Do you have sendFile enabled?
>
No compression for basic resources (that is, no compression keywords found
in server.xml). We do have a servlet named ContentType we use for
processing pack200 jar files. This is configured I the web.xml as follows:
<servlet-mapping>
<servlet-name>ContentType</servlet-name>
<url-pattern>*.jar</url-pattern>
</servlet-mapping>
sendFile is not enabled.
Here is a screencast showing the slow load to give you some context to the
Fiddler trace:
http://screencast.com/t/zmJtsCvgpzTw
Jerry
>
> - -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/
>
> iQIcBAEBCAAGBQJR4FiiAAoJEBzwKT+lPKRY/M4P/2Fxe5mLTFDAYcn+uMZKolfk
> xXx5aWO/aFwDiwd/nqsQ9SujtqcuX5XYMD3vb8o1ORUaUIxaQyYZUVQ5sKoxWZHi
> lzHgsagIu2wp2eSojvqCKu4CU0onOmKGt6EofMH5Gj4Lx0njtfozgi8Pdn/pT8j3
> YiyjBUUbF2iPDbWREixhp8L+HXqwoRJ3Fdxpe/XLBuxpgD+bCAq6THpZgWUhZi5c
> 16rGZDCM/THeWhYmKKq+uc+QkRYwf7v3KrS7uFxju3IiAFH4oMWX7Cn9T2rM624m
> y2Zkvxbdn3mBLnebRXXMbUg2iIOWuGx4Wr9ccuqixR3QTWZiJrsFstBzptiH2n6i
> z4rGAuvoReYyTYnusZ2BxVndldtFK18w5TfmoAkNzVCrPwgdvfKijqZB/V/B0mK5
> /C/xPQS4oYX5DoAuRjiqgiA8p6pDxkcEt7CvEaNoNONleRf4FcLOBqcKXTkc/dzP
> BiZ/C5CQGdCn2huiAcWn7oqfvUIr+1O+LCR05By7frLDhMDXMMe0IyPNTMKrHxUx
> l0rSqtq6w9+RjSTWHhiNnYL7t4zSpI/Zjm7ZWsfQhyVCgy6BUO0ksoseGPjQcDm2
> 0rNZPvxfWNLIXf1i9zaj+tW8FU/LROrzSgnMTS2fPlb47aXNkI6rQgHzELAYD28q
> q3row5rJg/vx4apOBICY
> =29Jo
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 7/12/13 2:16 PM, Jerry Lampi wrote:
> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of
> our sign on page became extremely slow. In 6.0.35, it would load
> in about 2 seconds; in 6.0.36, it loads in about 60 seconds.
Can you be more specific? Is it the "sign-in page" resource that takes
60-seconds to load, or do you mean the sign-in page plus all of its
associated resources (graphics, css, applets, etc.)?
> Our environment is an IBM mainframe running z/OS. Tomcat runs
> under USS (Unix System Services). The JVM version is java version
> "1.6.0" Java(TM) SE Runtime Environment (build
> pmz3160sr13-20130207_01(SR13)).
>
> When we remove the
> protocol="org.apache.coyote.http11.Http11NioProtocol" from the
> server.xml, the page loads in about 2 seconds -- the same a tomcat
> version 6.0.35.
Is this over SSL or not?
Does every page-load take 60-seconds or only the first time? What
about other pages?
> So I have narrowed this down to one configuration change. We need
> to have NIO enabled, as we use Netty to do some of our IO;
> therefore, leaving the option disabled is not possible for us.
>
> I ran Wireshark against 6.0.35 and 6.0.36 with NIO enabled hoping
> to see a large discrepancy in the number of packets sent, but the
> packet counts were very similar.
>
> I ran Fiddler and did see that files over 50KB in size were the
> slow ones; oddly, jar files (we have a swing applet on our sign on
> page) that were much larger than the slower .gif and .js files,
> were served very quickly.
Are you using compression of any kind? Do you have sendFile enabled?
- -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/
iQIcBAEBCAAGBQJR4FiiAAoJEBzwKT+lPKRY/M4P/2Fxe5mLTFDAYcn+uMZKolfk
xXx5aWO/aFwDiwd/nqsQ9SujtqcuX5XYMD3vb8o1ORUaUIxaQyYZUVQ5sKoxWZHi
lzHgsagIu2wp2eSojvqCKu4CU0onOmKGt6EofMH5Gj4Lx0njtfozgi8Pdn/pT8j3
YiyjBUUbF2iPDbWREixhp8L+HXqwoRJ3Fdxpe/XLBuxpgD+bCAq6THpZgWUhZi5c
16rGZDCM/THeWhYmKKq+uc+QkRYwf7v3KrS7uFxju3IiAFH4oMWX7Cn9T2rM624m
y2Zkvxbdn3mBLnebRXXMbUg2iIOWuGx4Wr9ccuqixR3QTWZiJrsFstBzptiH2n6i
z4rGAuvoReYyTYnusZ2BxVndldtFK18w5TfmoAkNzVCrPwgdvfKijqZB/V/B0mK5
/C/xPQS4oYX5DoAuRjiqgiA8p6pDxkcEt7CvEaNoNONleRf4FcLOBqcKXTkc/dzP
BiZ/C5CQGdCn2huiAcWn7oqfvUIr+1O+LCR05By7frLDhMDXMMe0IyPNTMKrHxUx
l0rSqtq6w9+RjSTWHhiNnYL7t4zSpI/Zjm7ZWsfQhyVCgy6BUO0ksoseGPjQcDm2
0rNZPvxfWNLIXf1i9zaj+tW8FU/LROrzSgnMTS2fPlb47aXNkI6rQgHzELAYD28q
q3row5rJg/vx4apOBICY
=29Jo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol"
causes tomcat 6.0.36 to load web page elements
Posted by André Warnier <aw...@ice-sa.com>.
Jerry Lampi wrote:
> When we switched from tomcat 6.0.35 to 6.0.36, the initial load of our sign
> on page became extremely slow. In 6.0.35, it would load in about 2
> seconds; in 6.0.36, it loads in about 60 seconds.
>
> Our environment is an IBM mainframe running z/OS. Tomcat runs under USS
> (Unix System Services). The JVM version is java version "1.6.0" Java(TM)
> SE Runtime Environment (build pmz3160sr13-20130207_01(SR13)).
>
> When we remove the protocol="org.apache.coyote.http11.Http11NioProtocol"
> from the server.xml, the page loads in about 2 seconds -- the same a tomcat
> version 6.0.35.
>
> So I have narrowed this down to one configuration change. We need to have
> NIO enabled, as we use Netty to do some of our IO; therefore, leaving the
> option disabled is not possible for us.
>
> I ran Wireshark against 6.0.35 and 6.0.36 with NIO enabled hoping to see a
> large discrepancy in the number of packets sent, but the packet counts were
> very similar.
>
> I ran Fiddler and did see that files over 50KB in size were the slow ones;
> oddly, jar files (we have a swing applet on our sign on page) that were
> much larger than the slower .gif and .js files, were served very quickly.
>
> I am not sure how to proceed.
> Jerry
>
I have no idea of the problem, but just to facilitate the work of someone who might have
an idea :
1) can you provide the configuration snippet of your NIO <Connector> ?
(paste it here in the text, don't send it as attachment.)
2) so if you remove (comment-out) from your login page the references to images and css
files, then it loads quickly, is that right ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org