Hacker News new | ask | show | jobs
by victorma 4990 days ago
>I would argue that data fetching from DBs or caches will be the majority of execution time.

People keep saying that, and I would like to see some numbers for that also.

The DB dataset could be already cached in memory, for example.
2 comments
encoderer 4990 days ago
Large web apps do often spend a lot of time manipulating strings and arrays in memory. It's absolutely true and I've seen it myself several times -- a performance penalty that is measurable and noticeable to users.

But that pales in comparison to the overhead of a Database call, or even a call to Redis or Memcached.

I've read (from sources I trust) that a database call on a modern stack like .Net or JVM is 4 orders of magnitude slower than a local method call. Think about that. So if the time you spend brushing your teeth is a local method call, the entire next day is a database query.

I can't remember the source here but the information is available with a few minutes of coding or googling.

And to the caching point -- having data cached locally in memory is great, but you can't trust that.

link
Firehed 4990 days ago
> And to the caching point -- having data cached locally in memory is great, but you can't trust that.

You can if you design around handling a possibly-stale cache.

link
encoderer 4989 days ago
Not really. There is no system that ever has had an always-fresh cache.

Are you disputing the premise or just disagreeing for the sake of it?

link
Firehed 4989 days ago
I'm saying that having a stale cache won't be a problem for an application that is designed around the fact that you will occasionally have stale data.
link
ihsw 4990 days ago
Database access latency will always trump any language design issues, except in extreme cases. This article does make some of those cases obvious, especially since they are easily-overlooked programming mistakes.
link
ludovicurbain 4990 days ago
Database access latency will always be an important factor of _latency_ .

That doesn't prevent anyone from coding stuff that requires 20 times less application servers while using the same amount of database (+caching) servers.

The very idea that because the DB call takes a while to complete, we can waste even more CPU cycles is a complete misunderstanding of real world use cases.

But then, the very use of PHP means that you don't give a shit about execution time or server costs at all.

link