On scalability and memory footprint
tdavis: "Memory usage" is pretty vague. If you're just talking about writing poor code that naturally requires more memory to store objects and such, it's not a big issue if you can scale linearly. What you really need to watch out for is memory leaking. This can cause processes to slow down dramatically and there's nothing you can do to scale it when that happens; your app server will take requests and probably even have RAM to spare, but the actual processing of the request will take forever and your site will be sloooow. This is especially relevant for long-running processes. I have accidently written memory leaks into programs before that, despite having more than enough RAM to grow, eventually slowed down to an absolute crawl. I'm talking 1 loop per second to begin with and by morning it's doing 1 loop every 4 hours.Premature optimization? Avoid it. Writing good code? Don't avoid it because bad code is easier and memory is cheap. There are some times when it makes no logical sense to allow something to use tons of memory, despite how much you have available. For instance, if you request the same page from your site over and over again and the memory usage continues to increase, that's probably a bad thing. What is that process storing in local memory and not garbage-collecting after a request? It's HTTP so there should be no persistence at the web framework level (i.e. in Rails). It should manufacture a request, send it, and move on to the next one, shedding all the local variables made in the process. If your memory footprint is increasing while your real load is remaining the same, that's bad. If you're storing the same object in memory in 5 different places, that's bad -- but not that big a deal so long as they're all gone when the request has been served.(Flamebait P.S. -- save memory, kill Rails.)