tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Lampi <...@sdsusa.com>
Subject Re: Enabling protocol="org.apache.coyote.http11.Http11NioProtocol" causes tomcat 6.0.36 to load web page elements
Date Wed, 17 Jul 2013 19:06:07 GMT
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 <jal@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


Mime
View raw message