This fetishism with scaling... to me it's just procrastination. It feels like work because you're doing something technical but, in the end, you're adding very little to your product.
Yesterday I had a meeting with a potential customer and I hated it. I hate to try to explain my SaaS software to non-technical people who treat me like some 17-year-old webmaster. I'd much rather be refactoring Clojure code. But I got out of my comfort zone and this client will probably add hundreds of thousands to my bottom line. And I'm glad I was at that meeting while my competitors were fetishizing about non-existent scaling issues.
It's 2012 for god's sake, you can rent a 32GB server for less than $100.
Performance isn't a problem until it is, and then when it is a problem, it's bigger than any other problem in the world because you have nothing to sell if it does not operate.
I always thought I was being wise by not doing any premature optimization, but after a few lessons learned the hard way I certainly factor in performance to the design of software before I build now.
Scalability is not a "feature" tacked on at the end development.
Scaling will only become a problem when/if you achieve product/market fit.
What percentage of startups on HN have achieved product/market fit, are past a 128GB commodity box AND have no dedicated engineering team for scaling issues?
As an engineer, not knowing how to scale when working on something that may need to scale could spell the downfall of whatever product you're working on. Yes, all is well and fine until you hit a natural growth cycle and can't commission new boxes fast enough because each request is taking 300ms. Your database isn't accepting enough requests (plus, some of your bad queries that aren't indexing are blocking too long). Then your web servers run out of memory because you are using an ORM for large lists of items that you're just returning as an array...
Once you get to the point of no return you have to know what to do or you'll suffer. Learning that when fire is falling from the skies is the worst way in retrospect.
Part of being a good developer is knowing where the scalability bottlenecks are likely to be as you are developing software, and making intelligent decisions about the algorithms, data structures, and architectures you use. I would never advise a developer to not "factor in" performance or future scalability needs at all. The problem is when you spend significant extra effort building highly scalable architectures that you don't need now and may (likely) never need.
To a point. However, it's also rather painful to add after the fact in many architectures, and you've ever been up against that wall once, you'll never want to be in that situation again.
Plus, almost all of these techniques will also speed up page generation on a lightly-loaded server, so that's a win in any circumstance.
scale is one of those problems that sneaks up on you (well unless you're an instant hit site I suppose)
In all of my cases dealing with scale issues it's been due to the DB growing very large in size to the point where you can't use the same techniques that you're used to using. That usually happens in combination with more concurrent users. Depending on how large and how organized your code is, things can get very ugly when the site starts throwing errors, being unresponsive, etc.
I usually know where I want to go as a next step with scaling and monitor our resource usage until it gets pretty high. Then we take the next step. But we don't spend a huge amount of time scaling until we know we need it.
One of the issues I've run into in the past was a MySQL problem where their system was creating tons of temporary tables, and because of the massive amount of traffic they were getting, it was killing their database server because it was choking out the disk's I/O, and the server was at 80% iowait most of the time because the disk cache was paging things in and out like crazy.
I went back and forth with them about optimizing the app, but it was apparently some huge labyrinthine monstrosity. They insisted that they didn't have the resources to do any of the significant rewrites that it would require to fix the app to do proper queries (or at least, not enough to be worthwhile).
Eventually I gave up. /tmp was mounted onto a separate partition, so I disabled ext3 journalling and set commit=30 so that it only sync'ed to the disk every 30 seconds. Since no temporary tables lasted that long, the VFS layer never wrote to the disk if it didn't have to. /tmp became an in-memory cache, and CPU use dropped to 5%.
Optimizing isn't about a checklist, it's about looking at the system that you have, understanding what it's doing and why, and understanding how the other systems around it behave so that you can resolve the issue. Moving onto another database server wouldn't have helped them. Moving onto a RAID would have reduced the impact, but their load didn't scale linearly so they'd hit their limit in a few months anyway.
tmpfs for mysqld's tmpdir is a similar option, perhaps even better if, as I'd hope, tmpfs's internals are simpler and faster because it has an easier job to do that ext3-sans-journal. Obviously needs the RAM though.
No, you didn't, but we all knew you were talking about Hetzner. One company, selling consumer-grade desktop parts unfit for use in a production server, in one country, does not lend credibility to statements like you made. Neither does the NYC site with no info, no SLA, and again, desktop parts. It's something like saying salary isn't important to startups because labor costs in China are pennies per hour.
It's 2012 for god's sake, and 32GB RAM servers are still hundreds of dollars a month to rent from any first class data center.
This is a bit of a tangent, but do you have any sources for consumer-grade desktop parts being lower quality than enterprise-grade? I'd like to read an in-depth hardware analysis that describes circuit board design, capacitor sourcing, etc.
I'm really curious to see how different equivalently priced ASUS and supermicro boards differ.
You can split hairs all you like, Dan, but you're still missing the point: scalability is only an issue for a fraction of the entrepreneurs/engineers who worry about it.
Yesterday I had a meeting with a potential customer and I hated it. I hate to try to explain my SaaS software to non-technical people who treat me like some 17-year-old webmaster. I'd much rather be refactoring Clojure code. But I got out of my comfort zone and this client will probably add hundreds of thousands to my bottom line. And I'm glad I was at that meeting while my competitors were fetishizing about non-existent scaling issues.
It's 2012 for god's sake, you can rent a 32GB server for less than $100.