Home / server / Questions / 222442
In Process
luison
Asked: 2011-01-15 05:03:57 +0800 CST

Serving images from another hostname vs Apache overload for the rewrites

  • 772

We are trying to improve further the speed of some sites with older HTML in order as well to obtain better SEO results. We have now applied some minify measures, combined html, css etc. We use a small virtualized infrastructure and we've always wanted to use a light + standar http server configuration so the first one can serve images and static contents vs the other one php, rewrites, etc. We can easily do that now with a VM using the same files and conf of vhosts (bind mounts) on apache but with hardly any modules loaded. This means the light httpd will have smaller fingerprint that would allow us to serve more and quicker, have more minSpareServer running, etc.

So, as browsers benefit from loading static content from different hostnames as well, we've thought about building a rewrite rule on our main server (main.com) to "redirect" all images and css *.jpg, *.gif, *.css etc to the same at say cdn.main.com thus the browser being able to have more connections.

The question is, assuming we have a very complex rewrite ruleset already (we manually manipulate many old URLs for SEO) will it be worth?

I mean will the additional load of main's apache to have to redirect main.com/image.jpg (I understand we'll have to do a 301) to cdn.main.com/image.jpg + then cdn.main.com having to serve it, be larger than the gain we would be archiving on the browser?

Could the excess of 301s of all images on a page be penalized by google?

How do large companies work this out, does the original code already include images linked from the cdn with absolute paths?

EDIT Just to clarify, our concern is not to do so much with server performance or bandwith. We could obviously employ an external CDN server but we have plenty CPU and bandwith.

Our concern is with how to have "old" sites with plenty semi-static HTML content benefiting from splitting connections for images and static content via apache without having to change the html to absolute paths (ie. image.jpg to cdn.main.com/image.jpg happening on the server not the code)

apache-2.2 optimization rewrite cdn seo

3 Answers

  1. to redirect main.com/image.jpg (I understand we'll have to do a 301) to cdn.main.com/image.jpg

    This is a bad idea, don't do it.

    Your long question is kind of hard to follow. As I understand it, you're worried about the server load, not how fast the site loads for your end users.

    If you're worried about server capacity, either:

    • Get a bigger server or
    • Use a in-RAM proxy server in front of your HTTP server (Squid, Varnish, Apache Traffic Server) or
    • Use a inexpensive Content Delivery Network to cache your static content closer to the end users, reducing both page load time and load on your servers.

    thus the browser being able to have more connections.

    The browser parallel download limit is a little bit of a red herring -- modern browsers download 6-8 files in parallel from the same hostname. It's only old browsers (IE6, IE7) which really suffer from this limitation.

    If you're worried about the end user's page load speed, then use a CDN, that's good advice in all situations were your users are spread out over a large geographical area (ie you have a global audience).

    301s of all images on a page be penalized by google?

    Possibly. But more likely, it will be hated by your users. For each image request you're first serving a 301, and then the correct image from another URL. That means 2 round trips to the servers for every single image, and hence significantly longer page load time for your users.

    • 1

  2. I've been playing with a similar question at my company for the past weeks. A couple things to keep in mind:

    1. Multiple domains for browsers: This is a fine line to tune. On the one hand, you have browser-imposed limits of how many resources can be loaded concurrently from the same domain (in this respect, more domains to load from is better). On the other hand, each domain you call out to requires a DNS lookup, which can hinder load speeds. I've been using a rule-of-thumb of 5 different domains, myself.
    2. Next, if I'm reading your description right (and I'm still drinking coffee, so I might not be), you're still going to be making the initial request to 'main.com' and having the 'heavy' apache redirect to the 'light' apache. This isn't going to help you at all. If you went this route, it would be better to set up 'main.com' as the light apache and have it Reverse Proxy any non-static content to the 'heavy' apache.
    3. Number 2 doesn't take full advantage of the 'multiple domain' improvement though, since all requests are pushed through the domain main.com. So what we did was set up a domain (following your example names) cdn.main.com as the 'light' apache and have it internally redirect to the appropriate resources. You might check out mod_cache also.
    • 0

  3. Usually, geting another server with say 20TB of available bandwidth per month costs much less than the CDN will charge you for the same amount of traffic (okay, it is probably faster due to the spread of the CDN but it is not cheaper in any case)

    Anyway, I am experimenting with the following setup (please comment on this if you think I may have something wrong here)

    Have www.server.com run all the php/mysql stuff and serve all the static files (images, css etc) from static.server.com. (i have set all base url addresses on variables so I can change them on will) On the static.server.com there will be a rewrite rule to check if the image exists localy and, if not, bring it over from www.server.com through a shell script/scp/rsync command. Then, next time it will be required, it will be already there. So, no second rewrite rule will be needed for that specific image/file. You will always have the option to just change that one variable that holds the path to your static content and serve everything from your main server again. The images will be there too.

    This way, image calls go directly to my static server and all the other stuff goes to the php/mysql one. If you don't run any php on the static server, then the processes won't become very big so you can have much more servers running in parallel to serve your images and it won't eat up your main computer's bandwidth.

    If you see that much CPU goes to waste on your static server,you can always move your mysql there too so you can balance the loads between the two.

    For an example on the above you can check this out (it is almost the same: )

    http://mrphp.com.au/code/image-cache-using-phpthumb-and-modrewrite

    Edit: I am talking about using two separate servers here (and physically located close enough in the case the mysql goes on the other server)

    Another thing I should add on the above is that you can have a DNS entry on static.server.com point at whichever server you want. (even the same as the rest of the application). So you can hard code the static content's address to e.g. static.server.com/image1.jpg. Applying the above solution just requires to set the DNS entry to point the static.server.com domain to your cache machine.,

    • 0