Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How not to structure database-backed web apps: performance bugs in the wild

blog.acolyer.org

Post reply on HN
Print view View original

241–250 of 319 posts

Re: How not to structure database-backed web apps: performance bugs in the wild

#241

Post by testplzignore »

mnutt wrote: post #212
nicktrocado92 wrote: post #209

Earlier quoted context omitted.

Why it's an antipattern ?

It’s susceptible to Thundering Herd whereby more requests come in for the same cache key before the initial computation is finished, and so you end up with lots of cache misses. The fix is usually to lock the cache key and have subsequent requests wait on the original computation but it’s a bit more complex to code.

Just be careful to lock the cache key, and not the cache. I've seen the latter done often, which of course kills performance if there are cache misses for multiple keys at the same time.

Re: How not to structure database-backed web apps: performance bugs in the wild

#242

Post by kyberias »

czechdeveloper wrote: post #16
mozumder wrote: post #3

Its always amazing to see web pages take 2-4 seconds of back-end processing. On a modern CPU, that's about 10 billion instructions. 10 billion instructions to send a few kilobytes of data. There's such a waste in back-end server design. If you're measuring response times are in seconds, and not in microseconds, you're doing something seriously wrong.

From my experience, most of my waiting time is IO, not CPU load. Even simple stuff, such as SELECT COUNT(*) to display total count in grid on big table can take seconds. It does not have to be complicated.

You may be confused about how databases work. COUNT(*) is not "simple stuff". It almost always involves an index _scan_. For tables with millions of rows, it takes a while.

Re: How not to structure database-backed web apps: performance bugs in the wild

#243

Post by kyberias »

olavk wrote: post #68
ianamartin wrote: post #41

Earlier quoted context omitted.

You have a problem. And it’s probably related to your db architecture, which was probably designed by devs with ORMs.

What kind of database architecture could cause SELECT * to be slow?

Any. "Architecture" has nothing to do with that. SELECT COUNT(*) is usually "slow".

Re: How not to structure database-backed web apps: performance bugs in the wild

#244

Post by olavk »

mnm1 wrote: post #231
olavk wrote: post #65

Earlier quoted context omitted.

> Inefficiency exists even at small scales with ORMs ORMs are not inherently inefficient. And in my time I have seen plenty of n+1 style queries written with raw SQL.

Lazy loading often fetches too little and eager loading too much. Most orms select all columns in all tables regardless of need. The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems, it's just a matter of how big, over a system without the orm. Since orms are superfluous, every line of code in them adds unnecessary overhead. They ar…

> The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems

No they are not. Have you measured this in a real-world application? This overhead is negligible compared to the cost of the query itself. And without an ORM you still have to load the data into some kind of objects or data structures before you pass it to presentation, you will just have to write the code yourself.

But yeah, lazy loading in a loop will kill performance. So don't do that.

Re: How not to structure database-backed web apps: performance bugs in the wild

#245

Post by blihp »

raarts wrote: post #239
knesek wrote: post #82

When I was inexperienced I feared ORMs because of the negative performance impacts I've read they could have. I constantly worried about what would happen if the amount of data increased and I hit ORM induced problem that I could not resolve without major rewrite of data access layer. However, whenever I've actually hit those problems in production, I found the similar thing the authors of the article did - ORM induc…

‘Unsolvable performance problems’ that could have been fixed by adding an index?? How did these team members pass their job interviews? By practicing algorithm puzzles?

Sadly, this occurs far more often than you might think. Large companies especially do it to themselves given how they structure their teams with developers and DBAs being on different teams and reporting to different managers. (i.e. you can trace their respective management chain separately until just below the C level) These reporting structures are problematic since large companies tend to hire people with very narrow skillsets which makes it vital that these groups work together. The end result is that you have teams throwing things over the wall to each other not knowing or caring what is happening on the other side of the wall... dysfunction by design.

Re: How not to structure database-backed web apps: performance bugs in the wild

#246

Post by olavk »

mnm1 wrote: post #230
blattimwind wrote: post #199

Earlier quoted context omitted.

> Inefficiency exists even at small scales with ORMs. In other words, you have no idea what you're talking about.

So the ORM taking many seconds for query overhead isn't a problem? This makes the web page served by this api many seconds slower. A second of slowness increases bounce rate by quite a bit and by two to three seconds, most visitors abandon the website. I guess that doesn't matter to you as you post a comment without substance and only an insult.

What ORM setup gives you "many seconds" overhead on a small website? Are you sure the ORM is to blame? I suspect you are doing something like lazy loading in a loop or joining/filtering on the client side.

Re: How not to structure database-backed web apps: performance bugs in the wild

#248

Post by mklepaczewski »

latch wrote: post #23

I've worked on moderately busy backend platforms (~10K-20k rps handled on a ~4 e5-2650 and aiming for 5ms 95p response times). It greatly depends on what you're doing, but for the majority of systems which are read heavy (and that most certainly includes "dynamic" sites like Amazon or Wikipedia), I hold to two major beliefs: 1 - Have very long TTLs on your internal cache servers with a way to proactively purge (messa…

1 - TTL should be infinite. If one needs finite TTL it means that cache invalidation logic is bogus.

Re: How not to structure database-backed web apps: performance bugs in the wild

#249

Post by coldtea »

manigandham wrote: post #213
coldtea wrote: post #193

Earlier quoted context omitted.

> Encouragement and attitude doesn't force you to do anything. You still have to choose to use it, either well or poorly. I don't believe in choices, people are flimsy. I believe in creating an environment that encourages good behavior.

> I don't believe in choices ...ok, people still make choices though, you're not controlling their minds. Perhaps educate your workforce so they make the right decisions by themselves, it's more effective and takes less effort than trying to coerce them through generalizations.

>...ok, people still make choices though, you're not controlling their minds.

No, but as a PM you can dictate they don't use an ORM.

Re: How not to structure database-backed web apps: performance bugs in the wild

#250

Post by godelmachine »

latch wrote: post #23

I've worked on moderately busy backend platforms (~10K-20k rps handled on a ~4 e5-2650 and aiming for 5ms 95p response times). It greatly depends on what you're doing, but for the majority of systems which are read heavy (and that most certainly includes "dynamic" sites like Amazon or Wikipedia), I hold to two major beliefs: 1 - Have very long TTLs on your internal cache servers with a way to proactively purge (messa…

By TTL, are you referring to Transistor Transistor Logic?
Post reply on HN