Re: useSendFile=true skips compression
Thanks for the explaination. So either I take the performance hit if I have high volumes, or the clients take a performance hit if I dont use compression. Is there some way I could get the best of both worlds? Maybe compress the files on the filesystem, then use a filter to programatically change the content type of those specific files to gzip? I suppose that would save some CPU as well, since the files wouldnt need to be recompressed with every request. Of course that also means that browsers without gzip abilities are SOL, but then again, this is a GWT app, so I am assuming a new browser (sorry lynx, no support). On Sat, Oct 4, 2008 at 11:43 AM, Bill Barker [EMAIL PROTECTED] wrote: Shaun Senecal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Could someone explain to me why the NIO Connector will ignore the compression settings for large files if useSendFile is enabled (it is by default)? It seems to me that if compression is enabled you would specifically want to use it when sendFile is enabled, but that might just be because I don't really understand what sendFile means/does :) In normal mode, Tomcat reads the file into its own memory buffer, optionally compresses it, and then writes it out again to the socket. In 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). On a modern O/S, this allows the O/S to transfer data using kernel memory only, instead of copying the kernel memory to program memory first (which has a significant cost on high-volume servers). It looks like my solution is to simply disable this option, but I was curious about why this is the case. I am trying to deploy a large GWT app, and I want to ensure that my massive JavaScript files get compressed before being sent to the client. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: useSendFile=true skips compression
if you're implementing with xml you *may* want to consider result-set data format which utilises less bandwidth such as json..start here http://gwt-rest.googlecode.com/svn/trunk/README Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Mon, 6 Oct 2008 09:20:21 +0900 From: [EMAIL PROTECTED] To: users@tomcat.apache.org Subject: Re: useSendFile=true skips compression Thanks for the explaination. So either I take the performance hit if I have high volumes, or the clients take a performance hit if I dont use compression. Is there some way I could get the best of both worlds? Maybe compress the files on the filesystem, then use a filter to programatically change the content type of those specific files to gzip? I suppose that would save some CPU as well, since the files wouldnt need to be recompressed with every request. Of course that also means that browsers without gzip abilities are SOL, but then again, this is a GWT app, so I am assuming a new browser (sorry lynx, no support). On Sat, Oct 4, 2008 at 11:43 AM, Bill Barker [EMAIL PROTECTED] wrote: Shaun Senecal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Could someone explain to me why the NIO Connector will ignore the compression settings for large files if useSendFile is enabled (it is by default)? It seems to me that if compression is enabled you would specifically want to use it when sendFile is enabled, but that might just be because I don't really understand what sendFile means/does :) In normal mode, Tomcat reads the file into its own memory buffer, optionally compresses it, and then writes it out again to the socket. In 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). On a modern O/S, this allows the O/S to transfer data using kernel memory only, instead of copying the kernel memory to program memory first (which has a significant cost on high-volume servers). It looks like my solution is to simply disable this option, but I was curious about why this is the case. I am trying to deploy a large GWT app, and I want to ensure that my massive JavaScript files get compressed before being sent to the client. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Stay up to date on your PC, the Web, and your mobile phone with Windows Live. http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/
Re: useSendFile=true skips compression
Shaun Senecal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Could someone explain to me why the NIO Connector will ignore the compression settings for large files if useSendFile is enabled (it is by default)? It seems to me that if compression is enabled you would specifically want to use it when sendFile is enabled, but that might just be because I don't really understand what sendFile means/does :) In normal mode, Tomcat reads the file into its own memory buffer, optionally compresses it, and then writes it out again to the socket. In 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). On a modern O/S, this allows the O/S to transfer data using kernel memory only, instead of copying the kernel memory to program memory first (which has a significant cost on high-volume servers). It looks like my solution is to simply disable this option, but I was curious about why this is the case. I am trying to deploy a large GWT app, and I want to ensure that my massive JavaScript files get compressed before being sent to the client. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
useSendFile=true skips compression
Could someone explain to me why the NIO Connector will ignore the compression settings for large files if useSendFile is enabled (it is by default)? It seems to me that if compression is enabled you would specifically want to use it when sendFile is enabled, but that might just be because I don't really understand what sendFile means/does :) It looks like my solution is to simply disable this option, but I was curious about why this is the case. I am trying to deploy a large GWT app, and I want to ensure that my massive JavaScript files get compressed before being sent to the client.
