Notes on: Xen and the Art of Deploying Rails by EngineYard 1. History of rails deployment 1. CGI 2. Apache 1.3.x/mod_fastcgi 3.

Lighttpd/fcgi 4. Apache2.x/mod_fcgid 5. Lighttpd/SCGI 6. Lightspeed 7. ... forget all these 2. Mongrel - no reason to use anything else 1. Mongrel is a HTTP server library 2. HTTP is well known and well tooled 3. Mongrel is easier to set up and use 3. but rails isn't thread safe 1. only one request per mongrel to the app server 2. set up a cluster of mongrels to scale 3. don't want to have Mongrel serving static files 4. Nginx – russian light web server 1. seriously bent on performance 2. super small resource footprint 3. way faster than Apache for static files 4. built-in memcached 5. Nginx + Mongrel is THE stack 1. very fast 2. don't need apache 3. mod_rewrite is going away, to be replaced with http_script_module 6. Perfect simple stack 1. Linux, Nginx, Mongrel(mongrel_cluster), Monit 7. Swiftiply: Event driven Mongrel 1. much faster 2. no code changes! 3. a little different paradigm than the current mongrel 8. Swiftiply Proxy 1. only works with Mongrel 2. boot as many mongrels as you want – autoconfigures 3. auto configuration 4. will eventually be able to get stats out of the proxy 5. could fire up new mongrels on the fly 9. the Zen of Xen 1. visualization is big these days 2. modularize your servers, instead of a dedicated box with everything on there 3. old school: everything running on one machine 4. new school: separate everything out on its own virtual machine 5. makes you much more flexible, just move VM's around 10. what happens when you need to get another box? 1. old school: get another box and move services on to there 2. new school: add another box with Xen installed, move a VM to a node on the new box 3. can do live migrations! 4. easy to target performance problems 5. scales much better 6. each VM does one thing and does it well 11. Advanced Clustering 1. SAN storage for all VM's

2. visualized compute nodes that boot off of USB thumb drives 3. hardware load balancers or dedicated boxes running Ultra Monkey or LVS 4. hardware load balancers are really expensive 12. Creating a fabric of compute and storage 1. shared file system between nodes 2. only deploy your code to one node 3. fragment caching all on the same storage 13. RAM 1. rails uses a lot of memory 2. almost always constrained by RAM instead of CPU 3. Rmagick and :include are the worst culprits 4. hard to track down memory usage in rails apps 5. almost all apps will end up with a leak somewhere 14. Rails eats DB resources for breakfast 1. indexes on your database 2. learn where and when to apply indexes 3. watch SQL logs 15. other tips 1. don't ever use filesystem sessions ... use AR or SQLsession or Memcached sessions 2. script/runner is massively inefficient – don't load all of rails for background processes 3. do not use script/runner to process incoming mails, run a daemon in a loop and poll a mail server ... run one processes with net/imap or something .. dont fork a whole process 4. learn how to write custom mongrel handlers (for example, for API calls) 5. cache, cache, cache 16. don't take as gospel 1. test it and benchmark it youself 2. trust but verify

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.