Tell me more ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.
up vote 5 down vote favorite

I have a site where I anticipate to have a large amount of users. I've heard that it is a good idea to separate user content (uploaded images) and place them on a separate static server where lighttpd would serve the content. This is supposed to speed up the requests significantly.

My question is:

  • Roughly how much imporovement can I expect form doing this?
  • How is it done? Users on my site upload files but then how do I automate the transfer process? What's the best practice? Rsync?
  • Any other tips? ideas? I'd really appreciate your input.
share|improve this question

migrated from stackoverflow.com May 15 '11 at 7:18

2 Answers

up vote 2 down vote accepted

Worry about Rsync later - for now you can do it all on the one box.

Your main domain is http://www.example.com/ on this domain you serve cookies (yum!).

The non-www redirects to the above.

Your static domain is http://static.example.com/ and on this domain you don't serve cookies or any other header items that are not really needed. Put js+css on there compressed and images served uncompressed. Set anything served on static to be public cache-able and with an expiry date some time into the future.

Now setup your domains to point to the same place on the file system, i.e. if you really want to load test.jpg you can get exactly the same file from either place. Do this with httpd.conf settings and two virtual server entries.

When your traffic gets to big levels you can migrate your static content server to a different box and rsync the whole document root to the new box. A cron job can be setup to do this every 5 minutes or so and the 404 of the static can redirect to the www to pick up on any resources not yet rsynced.

share|improve this answer
Aewsome advice! having 404 to rewrite to the origin server is a genius idea! Thank you very much for advice! – user7562 May 25 '11 at 4:52
I have a few questions, what exactly do you mean by putting js/css compressed? is that a webserver setting or do I compress it myself? Why not compress images? – user7562 May 25 '11 at 4:58
Images are already compressed - jpeg etc. You cannot compress them any more than they are already when serving them on the fly. For this reason there is no need to double compress them. Your js javascript and css style sheets are essentially text files with lots of whitespace in them. These resources compress very well with 'gzip' (the compression algorithm typically used by Apache). – ʍǝɥʇɐɯ May 25 '11 at 5:55
up vote 0 down vote

The difference in speed is dependent on a lot of variables. Think about it this way, every time a user requests a page/image the processor of the server must handle that request throw the requested item into ram and then serve it.

By separating static content you remove large images videos and other stuff from the queue of page requests to your processor so it can hand out pages as fast as possible without stressing about the images/videos/large stuff.

What it depends on is your processor speed, ram, bandwidth.

How you do it is you assign your static server to a subdomain this allows for non-cross domain scripting. If it's just images you can link with just the web addr, or you can read more about cross server scripting, apache is designed to do it so it is pretty darn easy.

There is a SO question that is pretty similar here Pros and Cons of a separate image server (e.g. images.mydomain.com)?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.