Hacker News Reader

Comment by mrinterweb | Hacker News Reader

In my experience 9/10 web application performance problems are related to database interactions. Is the query using an index? Are you hammering your DB with 300 N+1 queries to render an API response. These are usually the biggest offenders when poor performance is observed. If you're interactions with you DB are bad, it doesn't matter what programming language you use, performance will be mostly equally awful regardless of language.

View on HN

As an ex-DBA, the lack of understanding - and even basic performance monitoring - of your average Sr Software dev is mind blowing.

As a side note, the willingness of those same devs to allow queries of arbitrary size and constraints hit their db is equally frustrating.

“As long as we prevent against SQL injection, who cares?”

Before NewRelic this was so much worse too.

Bad indexing, no indexing, and fragmented indexes seem to cause no end of issues, and there always seem to be shortages of people capable of fixing it properly.

not to mention ORMs that query a lot of data through non ideal joins.

In order to fix a problem, one must be able to first identify the problem. Many people are still unaware of how indexing works, even though the devices they utilize daily perform this action routinely.

They’re out there—but I just ran EXPLAIN ANALYZE on my company’s search for them, and the query planner’s not too happy. It has to scan the entire resume heap before doing an on-site join with candidates, all while dealing with resource contention from queries of other employers. I know recruiters and e.g. triplebyte, stackoverflow all offer indexes to speed up this search, but in our case those indexes wouldn’t fit in cash.

Why does the index need to fit in "cash" (cache RAM)? Generally an index on disk, especially SSD, is far faster than traversing the entire dataset, because it allows the query executor to quickly narrow it down. Even if this requires some disk IO, it's a lot faster than doing all the disk IO for the entire dataset.

I'm not sure if you missed the joke (he basically was saying "It's hard to hire people who can do this sort of thing; they're out there but in demand and recruiters are expensive" but using DB terminology) and are thinking he's actually describing a DB operation, or if you're building on it so obliquely -I- am missing the joke you're trying to make.

That was very very good, but I wonder what sort of latency you experienced on the query that produced that result.

We use Python for web apps and I heard one developer complain that Python is a slow language and asked whether we should consider a faster language ("like PHP").

I just told them that if they find a function in the web application where we are actually bottlenecking on our Python code, I'll personally rewrite that in C (although I might actually just use Rust instead).

No complaints or rewrites thus far. I don't actually think the other developers, including the one lodging the initial compaint, know where our performance bottlenecks are. They just know that "Python is slow" and repeat that.

Reply on news.ycombinator.com