Hacker News new | comments | show | ask | jobs | submit login

Yes, 100%.

One thing I've enjoyed so far about being a contractor (but not a consultant) is that even as a relatively junior developer, I get to see the dirty internals of many different companies, and spot patterns between them. This is one of them.

I've been at companies that decided to switch to hot new NoSQL distributed fault-tolerant join-free key-value vector clock databases, when really they only needed to add a couple of indexes to a few heavily-queried fields. I've seen language switches and full re-architectures based on perceived performance problems, but the complexities of the new architecture made request latencies worse (c.f. https://en.wikipedia.org/wiki/Second-system_effect).

The best approach I've seen so far is described as 'list, rank, iterate'. Profile your problems aggressively, rank the issues in descending order of importance, and greedily work your way down the list, fixing them.

If there's one thing that drives me potty it's people who claim that mysql is too slow for their requirements (usually low-medium traffic website), then I look at their implementation and see no indexes on non primary-key fields.

Before NoSQL was a thing, I saw people break their data out into 1000s of .txt files to get around this.

There are so many good reasons to avoid MySQL that one shouldn't even need to bring up speed.

Agreed but in this case "mySQL" meant "SQL" (vs. NoSQL).

The single most useful thing to address perceived performance problems: Measure your performance. A often neglected part of the "list, rank, iterate" cycle is generating performance indicators that can be quantitatively assessed.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact