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