Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Speed Up Sites with htaccess Caching

Posted by Hemos on Mon Dec 04, 2006 09:24 AM
from the faster-faster-faster dept.
produke writes "Increase your page load times and save bandwidth with easy and really effective methods using apache htaccess directives. mod_headers to set expires, and max-age, and cache-control headers on certain filetypes. The second method employs mod_expires to do the same thing -- together with FileETag, makes for some very fast page loads!"
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • Increase page load times? (Score:5, Funny)

    by daranz (914716) <daranz@gmaiTOKYOl.com minus city> on Monday December 04 2006, @09:29AM (#17098646)
    Why would I want to do that?
  • I use it all the time, but be aware.. (Score:5, Interesting)

    by slashkitty (21637) on Monday December 04 2006, @09:31AM (#17098658)
    (http://slashdot.org/dev/null)
    It works great for images. I remember when I first started using it. It cut the number of http requests to the server in 1/2, and substantially reduced the bandwidth usage.

    However, if you are one to be changing images around, like using a Holiday logo or something, you have to change the image file name to force browsers to reload it.

    I'm sorta surprised that slashdot doesn't use this on their images:

    wget -S --spider http://images.slashdot.org/logo.png [slashdot.org]
    --08:31:01-- http://images.slashdot.org/logo.png [slashdot.org]
    => `logo.png'
    Resolving images.slashdot.org... 66.35.250.55
    Connecting to images.slashdot.org|66.35.250.55|:80... connected.
    HTTP request sent, awaiting response...
    HTTP/1.0 200 OK
    Date: Mon, 04 Dec 2006 14:30:12 GMT
    Server: Boa/0.94.14rc17
    Accept-Ranges: bytes
    Cache-Control: max-age=43200
    Connection: Keep-Alive
    Keep-Alive: timeout=10, max=1000
    Content-Length: 7256
    Last-Modified: Fri, 01 Dec 2006 03:02:14 GMT
    Content-Type: image/png
    Length: 7,256 (7.1K) [image/png]
    200 OK

  • caching htaccess? (Score:5, Informative)

    by oneiros27 (46144) on Monday December 04 2006, @09:37AM (#17098728)
    (http://www.annoying.org/)
    Here I was, thinking that someone had a solution for the slowdown caused by using htaccess files in the first place.

    They don't.

    If you're going to set caching in your server to decrease load time, make sure to set in the main configuation files, and disable htaccess, which can potentially increase the time of every page load. (the decreased hits and bandwidth may be an advantage to you -- you'll have to benchmark to see if this solution helps or hurts you for your given platform and usage patterns)
    • Re:caching htaccess? by mwvdlee (Score:3) Monday December 04 2006, @10:06AM
      • htaccess performance loss (Score:4, Informative)

        by oneiros27 (46144) on Monday December 04 2006, @10:33AM (#17099436)
        (http://www.annoying.org/)
        If you're on a shared hosting site, and htaccess is already turned on, you're already affected.

        Basically, if someone were to request a file from your site: /this/is/some/deep/file

        Then apache has to look for, and if there, parse, each of the following files: /.htaccess /this/.htaccess /this/is/.htaccess /this/is/some/.htaccess /this/is/some/deep/.htaccess

        And then, should the rules allow the file to be served, it'll be sent to the requestor.

        So the problem isn't the .htaccess file itself (unless you have a whole bunch of unnecessary rules, increasing the size of the file), but just turning on support for .htaccess files. I think the parsing of the .htaccess files is cached, but the system still has to check for the files each time, and see if they've changed.

        As for question about redirects -- you have to tell the system how to process the 404s ... I've seen lots of implementations, including setting a template system to resolve all 404s, and then using the path requested to drive a template system ... which of course meant that _every_ page on the site was served as a 404. (I was given the task of trying to figure out what the person had done, as they had tried upgrading the site, and wanted to archive the old site, and it took me much longer than expected to figure out what the horrible hack was that they used. (and of course, no services had cached the site, so I could see what it used to look like, because it always served 404s)) ... unless you have some way of specifying a handler for 404 errors without .htaccess (which you don't, as you've mentioned it's shared hosting), the question about .htaccess makes no sense.... it's still getting called, and you're still taking the performance hit, no matter what you pass off to.
        [ Parent ]
      • Re:caching htaccess? by Mad Merlin (Score:2) Monday December 04 2006, @10:40AM
  • httpd.conf (Score:5, Informative)

    Its in the comments on that site, but remember, you're always better off putting this kind of stuff in your httpd.conf as opposed to .htaccess files. htaccess files reduce performance on your webserver.
  • by xxxJonBoyxxx (565205) on Monday December 04 2006, @09:49AM (#17098862)
    So using cache control headers is "news", huh?

    Also, from the comment on this "innovative" article:

    1.DrBacchus said:
    Yes, these techniques *can* result in performance improvements, but should be put in your main server configuration file, rather than in .htaccess files. .htaccess files, by their very nature, cause performance degradation on your website, and so should be avoided whenever possible.
  • by tmh - The Mad Hacker (962953) on Monday December 04 2006, @10:11AM (#17099158)
    " Increase your page load times and save bandwidth"

    Probably not exactly what most people want to do, but yeah, if you can throttle your server so that page load time approaches infinity, bandwidth consumption will approach zero -- especially once people stop trying to use your site...

  • I recently upgraded RubyForge to Apache 2.2 and it's been such an improvement. mod_cache [blogs.com] is great, the worker MPM [blogs.com] is solid, and now I can run ViewVC under mod_python [blogs.com]. And there's mod_proxy and mox_proxy balancer for making Rails apps [getindi.com] work nicely with Mongrel. If you're still back on 1.3, I highly recommend 2.2.
  • Ooops.. I meant

    Decrease page load times

    As an example of how I implement this caching scheme..

    <FilesMatch "\.(flv|gif|jpg|jpeg|png|ico)$">
    Header set Cache-Control "max-age=2592000" # YEAR
    </FilesMatch>
    <FilesMatch "\.(js|css|pdf|swf)$">
    Header set Cache-Control "max-age=604800" # WEEK
    </FilesMatch>
    <FilesMatch "\.(html|htm|txt)$">
    Header set Cache-Control "max-age=600" # 10 minutes
    </FilesMatch>

    So the js and css get cached for a week, but if I make a change to one of them my site visitors won't get the updated content!

    But there is a fix for that that I use on all my sites now.
    Because the .html file is the file that specifies the URI for the js, css, and thereby every file on the site, I can just make a change to the html file and all site visitors update their cache!

    href="/z/c/askapache.css?v1008" type="text/css" />
    href="/z/c/askapache.js?v1008" type="text/javascript"></script>

    So when I make change I rename the css and js file to ?v1009

  • For everyone making the point about the performance hits of running these types of operations in htaccess as opposed to httpd.conf file yes I don't think anyone would argue with that, but it is true that this is for those billions of people on some type of shared hosting environment.. Besides, You can use the AllowOverride directive in httpd.conf to allow .htaccess in /z/image/ folder but not /z/df/even/cgi-b/live/ folder. Just turn it off, problem solved.

    Remember the article is called "Speed Up Sites with htaccess Caching" for a specific reason, this is about htaccess.. Power to the people! :)

    Just like how a lot of major servers with major processing power and bandwidth all of a sudden need to diagnose why their services aren't performing as expected. The reason in this example is because 99% of their customers were connecting to their bada$$ server every 3-7 minutes to check their email.. Only 1% of their customers were using IMAP..

    So likewise this may not seem like much of a performance gain to cut a small sites bandwidth IN HALF by implementing a well-thought-out caching scheme, but when you think what it would be like if the giant web hosting providers implemented a watered-down version of this in httpd.conf, man that would be huge and would help everyone. The bandwidth savings are dramatic

  • 2 replies beneath your current threshold.