tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Gamache <>
Subject Re: sendFiles vs. compression
Date Tue, 18 Apr 2017 14:58:30 GMT
Excellent information. Thank you!

Is there a way to create a split point where sendFile will handle files of
certain mime types (or all mime-types except for an exclusion list of mime
types) and/or of certain sizes while compression will handle files of other
mime-types and/or certain sizes?

Both settings have a minimum file size that engages their mechanism but to
set up a division of labor I would think we would need all of
include/exclude and max/min for both sendfile() and compression. Again, I
could be missing something obvious by staring at the problem too long.

@André and the rest of the listserv, In your opinions-- thinking about the
web site consumer's experience, and having to choose either send sendfile()
or compression-- is the juice worth the squeeze so-to-speak keeping
sendfile() and sending uncompressed files, or is the better choice to
enable compression at the expense of direct static file access and save

On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) <>

> On 18.04.2017 14:50, Chris Gamache wrote:
>> Using tomcat 8.0.43 ...
>> I'm grappling with GZip compression options. Historically, I've used a
>> custom GZip filter and that's been fine for the most part. If the file
>> being served is under 50K the filter would compress it in memory and send
>> it out. If the file is over 50K, it would connect the OutputStream to a
>> GZipOutputStream rather than compressing the whole thing in memory and
>> then
>> sending it out from there. When that happens it doesn't send a
>> Content-Length header. This is fine for most browsers. Safari has a
>> problem
>> with this and will decline to receive the file. In looking at the GZip
>> filter I've been using, it's kind-of naive-- there must be a more
>> intelligent compression option built into tomcat by now, right?
>> To enable compression, I set `compression="on"` in my <Connector/> element
>> in my server.xml file. There is on sticking point-- if sendFile is
>> available (asynchronous file-sending by the DefaultServlet using NIO) it
>> will trump compression by default. I can turn off sendFile, and browsers
>> report that they are receiving compressed files. So it seems like an
>> all-or-nothing situation where compression and sendFile are mutually
>> exclusive. There are minimum file size settings for both options, but no
>> max file size settings so I can't say "use sendFile for files under 50K
>> and
>> compression for files above 50K" because sendFile will always trump
>> compression.
>> I think the idea of sending out static files asynchronously is fantastic.
>> I
>> also want my pages to load faster by sending less data.
>> I figure the smart people who work on tomcat know a whole lot more about
>> this stuff than I do. They must have had a reason to prioritize sendFile
>> over compression, or the expert tomcat administrators have figured out a
>> way to balance the two.
>> Maybe I've been staring at the problem too long, but I can't figure it
>> out.
>> So, is it advisable turn of sendFile to engage compression? Or, is there a
>> combination of settings that will let me best use them both?
> For what it's worth :
> sendfile() is a way by which the (web) application can just point the OS
> to a static file on disk, and say "send this". And the sendfile logic in
> the OS takes care of the rest, in the most efficient way possible for that
> OS, and the call returns ok to your application right away, even possibly
> before the sendfile() action has completed.
> The sticky point here is "a static file on disk".
> So if you want to send back a gzipped file, then the only solution is to
> first create that gzipped version as a file on disk, and then use
> sendfile() on that gzipped version.
> And then, presumably, you'd want to "clean up" these gzipped versions at
> some point.
> Which cannot happen right after you have called sendfile(), because you do
> not really know when it will be done actually sending the file.
> So it is not really a "priority" issue, it is that these are different
> things, and that sendfile() really only works on a file, not on dynamic
> output from a webapp.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message