Because we had a shitty codebase that made 350 SQL calls on one page (the user dashboard), so the primary page that everyone used went from < 500ms to > 8 seconds, and the end client who had to test and accept this change didn't like it. It became unusable.
To (re?)clarify - this was 18ms per query to the SQL cloud (from a google compute engine).
Yes, were there things that could be done to reduce that? Of course. The other guy on the project put some caching in, reduced duplicate DB calls, etc, and got it down to around 3-4 seconds, but without severely diving in and learning far more about this inherited codebase, there wasn't much that could be done to make it much faster.
The other steps involved heavier caching, which changed the actual functionality of the service that was contracted before. "real time status updates" had a functional definition of being within X seconds, IIRC. Caching everything so 'new' information wasn't necessarily available to an end user for, say, 3 minutes, wasn't an option, without getting a lot of buy-in from a lot of people. Not saying it wouldn't work technically, but the client relationship was already strained.
The move to google was primarily to 'save money' (because someone had $10k service credit with google), but the effort to make it work well on google cloud and SQL combo (wasn't my call) was too much.
You can say this isn't google's fault entirely - you'd probably have a strong case - but not everyone is moving pristine clean/strong/good code over, and problems with the original base were amplified by seemingly small issues.
I hope you don't think I'm blaming your code base, but just out of pure curiosity, as an amateur question could you mention why the SQL calls couldn't be done in parallel -- did each one depend on the next or something?
At the high level I get everything you just said, just curious about this point, if you remember.
To (re?)clarify - this was 18ms per query to the SQL cloud (from a google compute engine).
Yes, were there things that could be done to reduce that? Of course. The other guy on the project put some caching in, reduced duplicate DB calls, etc, and got it down to around 3-4 seconds, but without severely diving in and learning far more about this inherited codebase, there wasn't much that could be done to make it much faster.
The other steps involved heavier caching, which changed the actual functionality of the service that was contracted before. "real time status updates" had a functional definition of being within X seconds, IIRC. Caching everything so 'new' information wasn't necessarily available to an end user for, say, 3 minutes, wasn't an option, without getting a lot of buy-in from a lot of people. Not saying it wouldn't work technically, but the client relationship was already strained.
The move to google was primarily to 'save money' (because someone had $10k service credit with google), but the effort to make it work well on google cloud and SQL combo (wasn't my call) was too much.
You can say this isn't google's fault entirely - you'd probably have a strong case - but not everyone is moving pristine clean/strong/good code over, and problems with the original base were amplified by seemingly small issues.