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 <j...@sdsusa.com>:
On Fri, Jul 12, 2013 at 4:21 PM, André Warnier <a...@ice-sa.com> wrote:
Jerry Lampi wrote:
On Fri, Jul 12, 2013 at 2:27 PM, Christopher Schultz <
ch...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
