1

I'm in the process of optimizing my website to serve static assets via a different domain so that they download/upload bandwidth is reduced and caching is easier.

Right now, I'm using Rails 3.1 with NGINX and Passenger.

So far, I've setup the system so that ALL of the assets are served through a similar domain to what I have now (its not a subdomain, but a different domain ... this way any cookies from the real domain won't be transfered within the requests). The NGINX server has the following configurations:

server {
listen 80;
server_name similarwebsite.com;
root /path/to/static/files;
}

server {
listen 80;
server_name website.com;
root /path/to/rails/files/public;
}

I find it to be much better to have a separate environment for the assets than that of Rails (I really don't like all the Rack abstractions that are going on just to deliver a few simple assets).

My question now remains, should I split the static files onto a different HTTP server like thttpd? For now they're both running on the same machine, but all of the assets would be delievered via thttpd and all the rails stuff via nginx. The thttpd instance can run on a different IP or port. Just wondering if this would make it any faster.

Any ideas? Am I going too far?

Paul Sonier
  • 38,903
  • 3
  • 77
  • 117
matsko
  • 21,895
  • 21
  • 102
  • 144
  • The second name is usually static.websiste.com rather than similarwebsite.com. Cheaper, too. – Joshua Aug 01 '11 at 23:35

3 Answers3

1

I believe that thttpd is extraordinary fast while being light on CPU so using it for static files could reduce CPU load. However, it will cost a bit more in restarting HTTP connections.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • This sounds excellent. One thing to keep in mind is that for thttpd you can set the keep alive to a higher amount and for nginx the keep alive can be disabled or set to a low amount. – matsko Aug 01 '11 at 23:54
  • I looked into thttpd and I decided not to use it since it is outdated and not well documented. I just used NGINX with another domain to serve the assets. – matsko Aug 15 '12 at 02:45
1

Good idea to separate the static content. Perhaps you should go one step further and use a CDN (content delivery network). I've used Akamai and Amazon's Cloud Front, each of which has costs related to their performance. There are inexpensive (free!?) alternatives as well. See the wiki page for CDNs for more info: http://en.wikipedia.org/wiki/Content_delivery_network

Daniel Woods
  • 11
  • 1
0

Turns out that I just stuck to using one NGINX http server to serve both the dynamic and static files. The static files were under a different domain and this solution was the best one with the least amount of configuration work.

matsko
  • 21,895
  • 21
  • 102
  • 144