Seems the insanely bad coding and ignorance of speed and performance goes all the way to the backend too!
Disappointing.
When you can't use more than a couple seconds of CPU time per transaction, or you have a fixed and spartan heap size for a big algorithm, you learn good habits real quick.
I imagine a lot of engineers today haven't had the experience of working within hardware limits, hence all the waste everywhere.
hmm, i guess that explains why salesforce is universally known for being slow; 2 seconds is an eternity.
we deliver every full page on the site within 250ms from initial request to page fully loaded (with js and css fully executed and settled). images/videos finish later depending on sizes and qtys.
i think it's expected that if you're doing some editing/reporting/exporting en masse, then a couple seconds could be okay (assuming it's thousands or tens of thousands of records, not a hundred). but not for single-record actions / interactions.
One large bank I used to work for had a payment processing system doing about 40 thousand transactions per day. It ran on about $8 million worth of hardware - mainly IBM mainframe. I was impressed until I found out each transaction was essentially a 60-100 byte text message. I can confidently say a well designed system can do 1000 times that load on an iPhone.
but companies throw money, hardware and vendor lock-in at problems way before commiting to sound engineering practices.
i have a friend who works at an online sub-prime lender, says their ruby backend does hundreds of queries per request and takes seconds to load. but they have money to burn so they just throw hardware at it. they spend mid-five figures per month on their infrastructure and third party devops stuff).
meanwhile, we run a 20k/day pageview ecommerce site on a $40/mo linode at 25% peak load. it's bonkers how much waste there is.
i think offloading this stuff to "someone else" and micro-services just makes you care even less about how big a pile of shit your code is.