On Sun, May 30, 2010 at 9:22 AM, Eric Covener <cove...@gmail.com> wrote:
> On Sun, May 30, 2010 at 1:40 AM, Sergey Chernyshev > <sergey.chernys...@gmail.com> wrote: > > Wouldn't you agree that deflate has all reasons to be on a default > > configuration? > > Again, I don't agree. I think it should be configured. > There are two parts to the problem - enabling gzip module by default in "configure" so when people compile Apache, they have it available - enabling the module in Apache config and configuring gzip for specific content I think having gzip available is a must, otherwise people will have to go through compiling it in which is almost impossible for most of the people. > I checked and it seems that http://httpd.apache.org/ is using gzip > > compression - why you think other people (with less control over their > > servers) shouldn't get it by default?! > > Our infrastructure has configured it, just like everyone else can. > First of all they had to compile it in and in case of Apache Foundation, I have no doubts they new what they were doing and has no hesitation in that regard. In case of a regular internet provider or enterprise IT or Linux distribution packager, I think this is very different and they have hard time understanding this and I believe it's important for a team maintaining most popular web server in the world to make such decisions for them as you did with other modules that are compiled in by default. If you're forbidden from enabling mod_deflate, it's probably for a good > reason (CPU, support) > Let me address these two separately - first, CPU. I think CPU whatever it is more important then extra time spent for apache child uploading the data over the network should be really tested. I'll be happy to ask people in the industry to provide their data whatever CPU limit was more important then slowed download times. I know that many people who can afford it, use SSL and GZIP-enabling (and even caching) reverse proxies in front of their Apache farms and some of them even use lightweight servers like nginx or lighttpd. But we're not talking about teams that can configure sophisticated server setups, but about regular infrastructure teams. Now, the second part - Support: I think browser support is very hight for gzip and in any case, we're not enabling gzipping blindly - mod_deflate honors Accept-encoding headers and sends data only in those cases. I'm well aware of bugs in some older browsers and it should be taken into account when default rules are created for ignoring some known bad behavior. The biggest point here is that leaving people to figure those details out is dangerous and there is no better place to provide support to people is in default configuration - documentation already lists some edge cases and I think people would benefit from such configuration: http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#recommended I have a feeling that default configuration can be quite simple - all is needed is to identify most common content types that are compressible and white-list them for compression (instead of not very reliable "everything but images" rule). Second step is to identify those old browsers that have broken support for gzip (while advertising it through Accept-encoding) and disable them. > Same is true for Expires as well: > > - Yahoo: http://developer.yahoo.com/performance/rules.html#expires > > Smartly considering your content expiration is wise, having the > default conf guess is unwise. > Agree completely - it was wrong for me to start the conversation with directives that I have in "drop-in htaccess" because those require other things to be done on application layer as I mentioned. I think, again, we should separate two issues - configuration and availability of the module. People who don't have access to recompiling Apache or enabling the modules don't have ability to configure expiration right now. And all I'm asking is to give them ability to configure their sites. Exact configuration is probably a question of their apps, although some best practices are available there as well. > Here's my article explaining why expiration is solving "caching problem" > > people are having and helps load static content once without > re-requesting > > it from the server waisting connections for pointless 304s: > >> Setting infinite Expires headers is a great solution to the problem > > I know what the headers do, I disagree that httpd should send them > with arbitrary values by default. > > > There are numerous books written about performance and all of them talk > > about these two aspects in one way or another. > > That should help people make smart decisions, but these are not > exactly obscure topics. Not sure I got your point about the obscurity of the topics - my point was that it's not just my whim to have gzip and expiration, but an industry practice instead and it's strange that multitude of books are being written to help people understand, but software doesn't do the job. I don't think there is any reason why Apache shouldn't be associated with fast web. Let's help people write about "Fast by default with Apache" instead of "Install nginx or lighttpd" or "the only way is to use CDN vendors like Akamai, the'll take care of it". > BTW, I always build Apaches from the source and before writing to the > list, > I downloaded the latest versions and checked - none of the three modules > I > > mentioned are enabled by default in the default build configuration > file. If > > I'm wrong, just let me know and I'll go and celebrate ;) > > No clue here about starting with a "default build configuration file" > -- maybe you're starting with "httpd.spec". When you ask for deflate > or expires and build from source, they end up loaded in the generated > config. > I'm not worried about my own ability to configure web servers at this point and if that was the case, I would just go to some forum and ask the questions. What I'm trying to do is to help more people get the benefits of those modules - I think they are critical to web site performance and it's in our hands to help. -- > Eric Covener > cove...@gmail.com >
