How not to structure database-backed web apps: performance bugs in the wild
1–10 of 319 posts
Re: How not to structure database-backed web apps: performance bugs in the wild
#2This is cool. Are there more papers as practically useful for a (web) developer as this one?
Re: How not to structure database-backed web apps: performance bugs in the wild
#3Its 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.
Re: How not to structure database-backed web apps: performance bugs in the wild
#4... Which begs the question: what good is an ORM if it does not prevent by design such issues? Here, we are essentially saying users of ORM must also have in their mind the SQL version. Or call an expert after the mess is done :/...
Re: How not to structure database-backed web apps: performance bugs in the wild
#5Its 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.
Modern frontends take even longer to completely load.
Re: How not to structure database-backed web apps: performance bugs in the wild
#6Its 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.
Too much CPU and too much available memory will get you there. When in time of abundance, we humans are not good at optimizing.
Re: How not to structure database-backed web apps: performance bugs in the wild
#7[deleted]
Re: How not to structure database-backed web apps: performance bugs in the wild
#8Its 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.
And that's exactly how client-side rendering became popular again.
"It's taking too long on the server, let's offload everything to every single client out there."
Now we have two problems.
Re: How not to structure database-backed web apps: performance bugs in the wild
#9... Which begs the question: what good is an ORM if it does not prevent by design such issues? Here, we are essentially saying users of ORM must also have in their mind the SQL version. Or call an expert after the mess is done :/...
[deleted]
Re: How not to structure database-backed web apps: performance bugs in the wild
#10I never understood why I don't enjoy working with ORM but reading this article make it clearer for me.
They blend the distinction between working in memory vs accessing the db.
From one side it is very convenient, however I really feel that such performance sensitive operation should be carefully considered and that most SQL should be written by hand.