We are building a maps based site in which we serve out map tiles created by us. The entire application is working well enough and we have followed through on most of the best Rails practices to speed up things. We have also now gone through the list of YSlow and typical HTTP practices to further reduce the time spent in the application.
I guess it's now time to go beyond the design and look at what can be done with the servers. We are using a traditional Apache + Mongrel Cluster for deployment at this time.
I have been reading and Thin looks attractive, as do Nginx and Lighttpd. I am wondering what we should look at next.
Serving map data requires us to server a number of tiles (256 x 256 pixels each) to create the map the user sees. Naturally, we will add "expires" headers, etc. so that the client caches it (if it can). We are just wondering if there is a recommended way to reduce the time it takes to serve files.
The tiles are served from a complex directory structure on four assets domains. Is there a "very fast static file server" that you would recommend us to use? Any experience or guidance would be great..
I would say don’t over optimize prematurely. Seems you have done the basics, if the site does not seem slow why spend time or trying to solve a problem that does not exist yet.
As a side note you should keep an eye on http://railslab.newrelic.com/. They have made some good resources to scale rails apps.
Also nginx infront of apache is quite useful for serving up static files. nginx is lot better at serving static files. nginx will also eventually help you out in load balancing across web servers and help you avoid more complex solutions for sometime.
There's nothing wrong with Rails for the task of building a maps based application.. instead of Google Maps or Bing Maps, we use our own based on data that we have. We use OpenLayers for the client side (Javascript) and store data in a database...
Specifically, which aspect of this would you think does not map to Rails?
Thanks, Adi. We are just in that phase where we have a bit of time to look at the final set of optimizations before we do the final sizing of the hardware for the projected load. Thanks for the links - we will start to look at these now...
