What works? When using nio connector with this parameter useSendFile=false, the 
load of large static files works fine. Before I set it to false it failed.

As for the other questions:
I don't know why it is slow, maybe the client's web server has some kind of a 
caching and the first time transfer is slow but then it is faster

-----Original Message-----
From: Pid [mailto:p...@pidster.com] 
Sent: ה 28 יולי 2011 11:16
To: Tomcat Users List
Subject: Re: fail to download large static files in tomcat

On 28/07/2011 07:31, Michal Singer wrote:
> Regarding the question I asked on downloading large static files a while ago, 
> I got a reply now:
> 
> 
> hi,
> i got the same issue today, environment: windows xp, tomcat 7 with nio 
> connector;
> it works after i try to add useSendfile="false" in server.xml Connector 
> section;
> you could have a try

What works?

> I answered this person:
> 
> Thanks, it looks like it works :)
> Do you also use compression=true?
> 
> I am not sure what is faster, nio or http? 

This doesn't make sense.  The NIO & BIO connectors both service HTTP.

> The first time nio is used, it is very slow, but then it is faster than 
> regular http.

Why?

> But if the client calls the nio once, it will be very slow.

Why?

> I also saw that useSendfiles is better in performance since it will reduce 
> cpu cycles:
> sendFile" mode, Tomcat tells the O/S to transfer the contents of the file  
> directly to the socket (bypassing reading it in to Tomcat memory).
> 
> So, isn't it a decrease in performance to set it to false?
> 
> Thanks for the answer.

sendfile can lead to performance increases, it depends on the application.


p

---------------------------------------------------------------------
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

Reply via email to