Two small httpd servers or one big one?

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?

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.

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

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.