tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.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:36:44 GMT
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 <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
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message