On Wed, Apr 19, 2017 at 9:05 AM, Mark H. Wood <mw...@iupui.edu> 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 >
