Re: sendFiles vs. compression

[Chris Gamache]

On Wed, Apr 19, 2017 at 9:26 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> On 4/18/17 10:58 AM, Chris Gamache wrote:
> > 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?
>
> You could configure a second DefaultServlet that matches specific
> patterns. You could also configure a "named" DefaultServlet and then
> use a Filter to decide if you want your CompressionDefaultServlet to
> handle your output versus your (likely "default") SendfileDefaultServlet
> .
>
Excellent suggestion. It's similar to the rewrite filter suggestion, but it
keeps web.xml simple which is one of my goals.


>
> > 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.
>
> You could also pre-compress your static files.
>

I like that idea. It is a good way to take care of it in a targeted and
sane way.


>
> > @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 bandwidth?
>
> It really depends upon your use-case. If you have a lot of free CPU
> cycles, then using them instead of sendFile="true" will improve your
> overall throughput to the client.


> If you have a very CPU-intensive application (which most are NOT...
> most apps are just waiting around for a disk, database, etc. to
> respond) then maybe you want to be as CPU-efficient as possible and
> use sendFile="true".
>
> If you have a very data-heavy application (tons of bytes need to be
> sent back and forth to the client) or you have clients with very thin
> pipes (e.g. mobile), then compression might outweigh "efficiency" on
> the application server.
>

That pretty much sums it up, yea? ;)

I think the group consensus is to monitor the server CPU and use that as
the main factor in deciding whether to use compression or not.

I really appreciate your thoughts and the thoughts of the other responders.
I have a clear plan of attack now.


> - -chris
>
> > On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat)
> >  wrote:
> >
> >> 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
> >>>  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 

Re: sendFiles vs. compression

[Chris Gamache]

On Wed, Apr 19, 2017 at 9:05 AM, Mark H. Wood  wrote:

> On Tue, Apr 18, 2017 at 02:03:19PM -0400, Chris Gamache wrote:
> > I had any frame of reference to base a decision on, I wouldn't have asked
> > the question. Ask any front-end engineer what the single best thing to do
> > to make a user's experience better when accessing a single-page web
> > application, they will say "enable compression" so why it isn't turned on
> > by default was a mystery, and that it plays second fiddle to serving
> static
> > file from the file system in an efficient manner was a double mystery.
> >
> > Perhaps if my fellow tomcat users would share their thought processes in
> > their particular situations for selecting one method over the other, that
> > might help me look at my own situation and make a good decision.
>
> Well, why does one want to use sendfile()?  Why does one want to use
> compression?
>
> sendfile() can be more efficient on the server end, by reducing the
> number of context switches when sending large files:  one switch into
> kernel mode is all that is needed to get the file sent.  So if you
> have a lot of concurrent users and fairly large files, this economy
> might dominate the user experience.
>
> Gotcha. More files can be sent at once (and more efficiently).
We have only a few large files to transfer per client, and the rest is
client/server data chatter.


> OTOH compression can make more efficient use of lower-bandwidth links,
> because it sends fewer bits in fewer packets to accomplish the same
> task.  So if you have a lot of users on slow links then this economy
> might dominate the user experience.  Note that compression uses more
> CPU at both ends, so a server already running flat-out or a large
> community of low-powered clients may eat up any savings, and then
> some.
>
>
Got it. CPU on both client and server to consider.

We're not CPU bound ATM on our servers using our current naive GZipFilter,
so this is a consideration I will put into the hat.
We're going for shorter app load time, and bandwidth is our chief
consideration. Radio time is more power/dollar intensive than
(de)compression for mobile clients, and non-mobile clients won't probably
blink at decompressing 500kb of javascript and a few images and fonts.


> How to know which is most important?  Measure!  The simplest approach
> would be to try it each way and ask users how they experienced the
> result.  If you have a lot of information about the distribution of
> bandwidth and CPU power across your user community, the amount of
> data to be sent per request, and the shape of traffic over time, you
> can make some shrewd guesses, but in the end the best solution is the
> one that does the job best, and the only way to know that is to test
> and see.
>

Yes. Excellent advice. Thank you for your thoughtful response!



>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Re: sendFiles vs. compression

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 4/18/17 10:58 AM, Chris Gamache wrote:
> 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?

You could configure a second DefaultServlet that matches specific
patterns. You could also configure a "named" DefaultServlet and then
use a Filter to decide if you want your CompressionDefaultServlet to
handle your output versus your (likely "default") SendfileDefaultServlet
.

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

You could also pre-compress your static files.

> @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 bandwidth?

It really depends upon your use-case. If you have a lot of free CPU
cycles, then using them instead of sendFile="true" will improve your
overall throughput to the client.

If you have a very CPU-intensive application (which most are NOT...
most apps are just waiting around for a disk, database, etc. to
respond) then maybe you want to be as CPU-efficient as possible and
use sendFile="true".

If you have a very data-heavy application (tons of bytes need to be
sent back and forth to the client) or you have clients with very thin
pipes (e.g. mobile), then compression might outweigh "efficiency" on
the application server.

- -chris

> On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat)
>  wrote:
> 
>> 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
>>>  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. 

Re: sendFiles vs. compression

[Mark H. Wood]

On Tue, Apr 18, 2017 at 02:03:19PM -0400, Chris Gamache wrote:
> I had any frame of reference to base a decision on, I wouldn't have asked
> the question. Ask any front-end engineer what the single best thing to do
> to make a user's experience better when accessing a single-page web
> application, they will say "enable compression" so why it isn't turned on
> by default was a mystery, and that it plays second fiddle to serving static
> file from the file system in an efficient manner was a double mystery.
> 
> Perhaps if my fellow tomcat users would share their thought processes in
> their particular situations for selecting one method over the other, that
> might help me look at my own situation and make a good decision.

Well, why does one want to use sendfile()?  Why does one want to use
compression?

sendfile() can be more efficient on the server end, by reducing the
number of context switches when sending large files:  one switch into
kernel mode is all that is needed to get the file sent.  So if you
have a lot of concurrent users and fairly large files, this economy
might dominate the user experience.

OTOH compression can make more efficient use of lower-bandwidth links,
because it sends fewer bits in fewer packets to accomplish the same
task.  So if you have a lot of users on slow links then this economy
might dominate the user experience.  Note that compression uses more
CPU at both ends, so a server already running flat-out or a large
community of low-powered clients may eat up any savings, and then
some.

How to know which is most important?  Measure!  The simplest approach
would be to try it each way and ask users how they experienced the
result.  If you have a lot of information about the distribution of
bandwidth and CPU power across your user community, the amount of
data to be sent per request, and the shape of traffic over time, you
can make some shrewd guesses, but in the end the best solution is the
one that does the job best, and the only way to know that is to test
and see.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: sendFiles vs. compression

[tomcat]

On 18.04.2017 20:03, Chris Gamache wrote:

On Tue, Apr 18, 2017 at 11:24 AM, André Warnier (tomcat) 
wrote:


Hi again.
On this list, it is customary (and requested) to respond in-line and not
"top post".
See : http://tomcat.apache.org/lists.html#tomcat-users, item #6.
It makes it easier to follow the conversation, as opposed to having to
scroll back and forth to find out what you are commenting on.

Noted. Apologies.




On 18.04.2017 16:58, Chris Gamache wrote:


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.



As you have probably already found out from the extensive and exquisitely
written on-line tomcat documentation, there do not seem to exist such
fine-tuned parameters available in the standard tomcat Connectors.



Props. We could do better explaining the "why's" along with all the
"what's". When I figure it out, I'll send a patch. ;) For now, I have to
rely on my fine colleagues here in the list for some of the more intricate
interpretations.



If you want this type of control, /and/ you can more or less determine the
kind of response you want to send by examining the request URL, I would
have a look at a servlet filter such as URLRewrite (
http://tuckey.org/urlrewrite/), which could examine the request and
determine to which specific response-generating servlet it should dispatch
the call. In that servlet you can then decide yourself to compress or not
the output, and/or to use sendfile.

So by rewriting the URL, the request gets re-evaluated such that a

different  would be engaged? I still have the dilemma of
determining which ladle I use to serve the data with.





@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
bandwidth?



I think that this is a question to which you are the only one who can
provide the right answer, because "it depends" on a lot of factors that are
specific to your application, your mix of documents, your bandwidth
availability and cost, the requirements of your clients etc..

With all respect, and I do thank you for your willingness to respond-- if

I had any frame of reference to base a decision on, I wouldn't have asked
the question. Ask any front-end engineer what the single best thing to do
to make a user's experience better when accessing a single-page web
application, they will say "enable compression" so why it isn't turned on
by default was a mystery, and that it plays second fiddle to serving static
file from the file system in an efficient manner was a double mystery.



Your any front-end engineer either is a crook, or he wants to get rid of you 
quickly.
There is no such "one size fits all" answer, for such a vague question.


Perhaps if my fellow tomcat users would share their thought processes in
their particular situations for selecting one method over the other, that
might help me look at my own situation and make a good decision.



You already got a glimpse of our thought processes in the matter :
We would start by trying out one configuration, in our own complex circumstances, and look 
at the results. And if we identify one particular problem area and can then ask a more 
precise and focused question based on some collected facts, and we cannot answer it 
ourselves, we might post it to the tomcat user's list.


Alternatively, one of us might propose a dedicated paid consultancy, to inspect your 
application and your server and its connectivity and your user's usage pattern, and 
recommend a "best" solution based on collected facts, on his own experience in the matter, 
and on your budget.










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

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 

Re: sendFiles vs. compression

[Chris Gamache]

On Tue, Apr 18, 2017 at 11:24 AM, André Warnier (tomcat) 
wrote:

> Hi again.
> On this list, it is customary (and requested) to respond in-line and not
> "top post".
> See : http://tomcat.apache.org/lists.html#tomcat-users, item #6.
> It makes it easier to follow the conversation, as opposed to having to
> scroll back and forth to find out what you are commenting on.
>
> Noted. Apologies.


> On 18.04.2017 16:58, Chris Gamache wrote:
>
>> 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.
>>
>
> As you have probably already found out from the extensive and exquisitely
> written on-line tomcat documentation, there do not seem to exist such
> fine-tuned parameters available in the standard tomcat Connectors.
>

Props. We could do better explaining the "why's" along with all the
"what's". When I figure it out, I'll send a patch. ;) For now, I have to
rely on my fine colleagues here in the list for some of the more intricate
interpretations.

>
> If you want this type of control, /and/ you can more or less determine the
> kind of response you want to send by examining the request URL, I would
> have a look at a servlet filter such as URLRewrite (
> http://tuckey.org/urlrewrite/), which could examine the request and
> determine to which specific response-generating servlet it should dispatch
> the call. In that servlet you can then decide yourself to compress or not
> the output, and/or to use sendfile.
>
> So by rewriting the URL, the request gets re-evaluated such that a
different  would be engaged? I still have the dilemma of
determining which ladle I use to serve the data with.


>
>> @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
>> bandwidth?
>>
>
> I think that this is a question to which you are the only one who can
> provide the right answer, because "it depends" on a lot of factors that are
> specific to your application, your mix of documents, your bandwidth
> availability and cost, the requirements of your clients etc..
>
> With all respect, and I do thank you for your willingness to respond-- if
I had any frame of reference to base a decision on, I wouldn't have asked
the question. Ask any front-end engineer what the single best thing to do
to make a user's experience better when accessing a single-page web
application, they will say "enable compression" so why it isn't turned on
by default was a mystery, and that it plays second fiddle to serving static
file from the file system in an efficient manner was a double mystery.

Perhaps if my fellow tomcat users would share their thought processes in
their particular situations for selecting one method over the other, that
might help me look at my own situation and make a good decision.

>
>
>>
>>
>>
>> On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) 
>> wrote:
>>
>> 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 
 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 

Re: sendFiles vs. compression

[Chris Gamache]

On Tue, Apr 18, 2017 at 11:29 AM, Mark Thomas  wrote:

> On 18/04/17 15:58, Chris Gamache wrote:
> > 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?
>
> No.
>
> > 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
> > bandwidth?
>
> It will depend on your site and the typical traffic mix. You'd have to
> test it.
>
> Or...
>
> You can have the best of both worlds if you pre-compress your static
> resources. You need to be using 8.5.x or later. Look for precompressed
> on http://tomcat.apache.org/tomcat-8.5-doc/default-servlet.html
>
>
That's wicked. Something to look forward to when we are at the point of
jumping to 8.5 or beyond.


> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: sendFiles vs. compression

[Mark Thomas]

On 18/04/17 15:58, Chris Gamache wrote:
> 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?

No.

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

It will depend on your site and the typical traffic mix. You'd have to
test it.

Or...

You can have the best of both worlds if you pre-compress your static
resources. You need to be using 8.5.x or later. Look for precompressed
on http://tomcat.apache.org/tomcat-8.5-doc/default-servlet.html

Mark


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

Re: sendFiles vs. compression

[tomcat]

Hi again.
On this list, it is customary (and requested) to respond in-line and not "top 
post".
See : http://tomcat.apache.org/lists.html#tomcat-users, item #6.
It makes it easier to follow the conversation, as opposed to having to scroll back and 
forth to find out what you are commenting on.


On 18.04.2017 16:58, Chris Gamache wrote:

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.


As you have probably already found out from the extensive and exquisitely written on-line 
tomcat documentation, there do not seem to exist such fine-tuned parameters available in 
the standard tomcat Connectors.


If you want this type of control, /and/ you can more or less determine the kind of 
response you want to send by examining the request URL, I would have a look at a servlet 
filter such as URLRewrite (http://tuckey.org/urlrewrite/), which could examine the request 
and determine to which specific response-generating servlet it should dispatch the call. 
In that servlet you can then decide yourself to compress or not the output, and/or to use 
sendfile.




@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
bandwidth?


I think that this is a question to which you are the only one who can provide the right 
answer, because "it depends" on a lot of factors that are specific to your application, 
your mix of documents, your bandwidth availability and cost, the requirements of your 
clients etc..








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


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

AW: sendFiles vs. compression

[Kreuser, Peter]

Hi Cris,

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

There may be a different aspect!

Are you servicing the file on an SSL and login protected website?

Then you should be aware of the BREACH attack http://breachattack.com/ and 
restrict the compressed resources wisely.
Basically the authors say: do not use compression.

Best regards

Peter

> 
> 
> 
> On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) 
> wrote:
> 
> > 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  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: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: sendFiles vs. compression

[Chris Gamache]

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




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

> 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  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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: sendFiles vs. compression

[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  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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

sendFiles vs. compression

[Chris Gamache]

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