Interesting approach. This is also nicely recursive, with each run being more expensive. I would prefer that statement to have a cost cap. Say "... in three days of work".
Thanks for reading.
To the downvoter: Maybe in your fantasy world, throwing more computing power at problems solves Eeeverything, including P ?= NP. I do wonder - why people even bother offering such services as the OP, if it's so pointless?
I once spent weeks optimizing code on a "best in the world" (for my branch of work) open source project because it made the assumption that it'd run on SSDs, hence it made zillions of small reads from the disk. There were two approaches to solve that: buy an SSD, or refactor the code. But it was through profiling that I found the answer (and in my economic situation at the time, buying an SSD was definitely not viable, much less a step 0!).
At work we were debugging why a process that is usually quite fast (< 5min) was taking close to 2 hours once we got to the load we predict for this coming fall.
We noticed the box it was running on was running out of memory, so we assumed resizing it to have ~4x the RAM would help, but surprisingly it didn't. The actual answer turned out to be algorithmic, and we were able to rewrite it to use an O(n) algorithm rather than an O(n^2) algorithm.
For what it's worth, a quite staggering number of sites I've fixed up have had databases with varchar ID columns, and no indexes anywhere.
Thankfully the DB sizes have been small enough that fixing this has taken a few seconds to a few minutes max of DB downtime, with instant, seriously-impressive-looking results afterwards.
It's not just talent/skills - there's more communication overhead when dealing with a team, and when the team has a range of skill levels on it, the comm overhead can make things worse (if not managed well)
I have a longstanding suspicion that developer cost climbs slower than developer skill and productivity, meaning companies should always hire the best they can get, because they'll maximize productivity that way.
also, i simply don't buy the assertion that any ops or dev can be automated in any meaningful way. the only thing it's doing is making it easier for morons to shoot themselves in the foot by ignoring the experts and then run to the same experts like a little child when everything catches on fire. see: recent story of a guy who deleted 1500 systems at once. oops.
are we all doing more, or less work than 5 years ago? has all this cloud and deployment tech made any less work for anyone, or destroyed any jobs? lol no. i repeat emphatically LOL NO. such a claim is just absurd in my view. anyone who claims such a nonsensical statement has never done actual ops work where you get called if shit goes south.
the smartest thing amazon ever did was simply give people a button to push to give them more money when they're faced with their own overwhelming stupidity. ain't nobody to blame but yo'self then.
I'm genuinely curious as to why you feel this way?
On a more technical side as an example, the number of open files can only be so high. You really start to hit the limit when you do things like that, which is when the most interesting kinds application crashes happen. "Just increase the file count." results in "Our report shows that an OldServer did not include a necessary open file limit config change. Engineer #582 has been fired."
I suppose we are lucky to have a very consistent workload per logical database.
This allowed us to calculate our costs ahead of time. We found that we could keep DB costs at ~$1/customer/month. For a B2B SaaS product we were satisfied with that cost.
Most decent RDBMS have a good way to ensure isolated locks across tenant ids e.g. MySQL partitions.
Currently, I manage several hundred logical databases for a B2B SaaS product. This has the potential to grow to several thousand over the course of years.
My customers enjoy that (arbitrary) piece of mind that their data is logically separated from all else. I enjoy not having to remember to include a tenant_id clause.
Our traffic pattern is quite steady per hour of day and per customer. That, plus using RDS for horizontal scaling (fixed # of logical DBs per host) allowed us to take this route.
I suppose the decision is a matter of circumstance and preference, but I don't think this is necessarily "wrong" to do.
Firstly, this doesn't help if you're CPU-bound or write-bandwidth-bound, both of which are quite common.
Secondly, you may not be able to simply get a bigger box. Most motherboards have effective RAM limits. Bigger iron gets exponentially more expensive. Jeff Atwood on this: http://blog.codinghorror.com/scaling-up-vs-scaling-out-hidde...
(I remember about a decade ago when our chip design startup bought a 128GB RAM box because that was the largest available at sane pricing ...)
* Database with homegrown software load-balancer in front of it, and the database replicated to a half-dozen subscribers. Load balancing required database calls, and the subscribers had their LUNs on the same array as the main database. So 7 different servers, but all beating the same storage. In the end, we ended up with no load balancing (just the single instance).
* Application server with lots of agents (one on every workstation). Agents were checking in every 200ms, even if they had nothing to report. Result was lots of tiny database transactions (for logging no activity). Throttled that down to 10 seconds (product managers agreeing that was the more realistic threshold) and batching the updates, made the logging asynchronous, and saw the database transaction log no longer waiting on log writes constantly.
* Bad clustering keys for tables. Some tables that were being searched constantly as heaps. Sharded tables with divergent schemas. This was fun, as had to conform everything while it was live (got agreement on what was reasonable delay for synch jobs). Chose correct clustering keys, compressed the tables, and then got rid of other indexes that were no longer necessary. Cut IO by 99%, and writes were now just appends.
* Badly written queries using inadequate indexes on badly structured tables. TL;DR: An analysis process took 24 hours, and was tuned to take 4.5 hours. I spent a day on it to cut it down to an hour while I worked on other things. We then spent 2 weeks refactoring it to cut it down to about 8 minutes, despite the underlying data model being bleh. We also added ad-hoc functionality to do stuff out-of-band of the regular scheduled job, with an average response time of 6ms.
* ORM lazy loading by default, including for things that constantly retrieved collections. Rewrote them to be programmatically eager loaded and reduced database calls from millions a day to thousands a day.
* And a little bit of hardware. SAN HBA links were moved form dual 1Gbps to dual 10Gbps. Some SSDs added. Ended up reducing IO latency by 96-98%, depending on the server. Needed to happen, as IO latency was in hundreds of ms, and we were able to get it down to where it should be (< 10ms for reads, 1-3ms for writes).
Non-scaling SAAS stack went from falling on its face with an entire rack of hardware, to being cut down to 1/3rd of a rack of hardware and the hardware basically twiddling its thumbs. The organization was in the process of building of entirely new SAAS platform in a completely different tech stack -- they immediately started questioning that decision when the old stack handled everything trivially, and they knew there was a lot more tuning that still could be done.
> "In the 1880s, James MacNeill Whistler, as plaintiff in a libel action, was challenged, "For two days' labour, you ask two hundred guineas?" "No, I ask it for the experience of a lifetime." That seems an apt summary of the message of this legend."