Ask HN: Where/How can I learn more about general webapp maintenance?

<p><pre><code> 1. Database, database, database 2. Database 3. It's probably your database unless you're doing something CPU or disk intensive, for example resizing and prettifying pictures, rendering a 3d image, etc. Realize that these days looping a few thousand times is trivial. 4. It's your database </code></pre> Starting with <i>fault tolerance, speed, unit testing, code abstraction, etc.</i> is starting at the wrong point. 90% of performance problems are at the database level.<p>What's most likely wrong with performance in a webapp:<p><pre><code> 1. No/bad indexes/missing foreign keys on your db 2. Stupid joins 3. You're doing stupidly complicated things in an ORM 4. You're doing complicated things in the DB instead of loading a large chunk into memory and doing calculations or aggregations in code. Simple DB queries are a lot faster than you think they are. Complicated ones are a lot longer than you think they'll be. There are weird gotchas in DBs like using a function in a where or select clause will cause a massive performance hit. 5. You're not caching into memory or something like memcached things that changes infrequently but are queried regularly. Memcached is actually overkill most of the time. Actually think about how much memory storing X would take compared to how much memory your machine has. Be surprised at how insignificant it is these days. 6. 1-5 are especially true if you're using Mysql - It's great and all, but all the other big DBs piss all over it for out of the box performance. You have to give it some love. I expect some dissent here. They're wrong. MS SQL is a shit ton better at handling a poorly designed db/db queries out of the box than mysql. I can't stress this enough. </code></pre> tl;dr Start looking at your database performance before anything else.

I'm not an expert, but this is what I've cobbled together as a fellow Ruby/Rails startup person.<p><i>Fault</i> <i>Tolerance</i>: Just use Heroku. We've seen maybe an hour of downtime in a few months?<p><i>Speed</i> (and fault tolerance): Cache everything you can, assets on S3/CF.<p><i>Testing</i>: Rails Test Prescriptions by Noel Rappin [<a href="http://pragprog.com/book/nrtest/rails-test-prescriptions" rel="nofollow">http://pragprog.com/book/nrtest/rails-test-prescriptions</a>]. Then you can choose what you like, but I like Test::Unit, Mocha, FactoryGirl.<p><i>Code</i> <i>Abstraction</i>: Rails is already pretty sensibly organized, and if MVC + tests + static assets is not a good fit for your webapp, you really should not be using it in the first place. One minor point: Noel and others will tell you to use skinny controllers.<p>Curious what other people consider best practice for Ruby/Rails startups.

I've heard good things about New Relic for performance testing.<p>MiniTest, which is built into ruby 1.9 has a full suite including performance tests. It's really cool because you can measure e.g. whether an algorithm scales linearly or not.

A quick tip would be to run everything process intensive in the backend, don't waste frontend resources with API calls, data processing etc, got something that takes more than 200ms to run, place it in a job que and do the processing later.<p>Some tools for the job: <a href="https://github.com/defunkt/resque" rel="nofollow">https://github.com/defunkt/resque</a> <a href="https://github.com/tobi/delayed_job" rel="nofollow">https://github.com/tobi/delayed_job</a><p>Also don't forget to cache. You shouldn't worry too much if you do these two properly.

From a performance point of view: test and measure! Find the worst bottleneck, and reduce it. Rinse and repeat.<p>NewRelic is a great tool to help you do this.<p>Common performance problems to look out for in Rails are:<p>* Missing database indexes<p>* Long running code (eg PDF generation, file uploads to a third party) that should be put in a job queue<p>* Innocent looking ActiveRecord calls that use N+1 queries or fetch way too much from the DB and the result set is further reduced in Ruby

You can read on various massively scalable webapps architecture. <a href="http://highscalability.com/" rel="nofollow">http://highscalability.com/</a> seems to aggregate those, and you can find articles and slides published by the developers of more services if you do some googling.<p>The key to speed and load tolerance is massive multilevel caching; every service does caching differently but they all do.

Pick up Release IT (<a href="http://amzn.com/0978739213" rel="nofollow">http://amzn.com/0978739213</a>) from the Pragmatic guys. While many of the examples and stories are based on Java webapps there is something in there regardless of which platform you are building atop.<p>Oh, and don't ever establish a blocking connection without a timeout or some other mechanism to abort it.