3 ms·
The parent reply hit the nail on the head with this: >Maybe the jobs can get broken down into subtasks that you can run in parallel. Unless you've explicitly
by ac2u 3y ago
The parent reply hit the nail on the head with this:
>Maybe the jobs can get broken down into subtasks that you can run in parallel.
Unless you've explicitly called out that your jobs are CPU heavy, I'm willing to guess that there's a lot of IO/network calls meaning your jobs are taking 6 mins.
If that's the case, and those network calls are to a third party, then you're actually sitting on untapped scalability from their ability to handle calls by not splitting your jobs up into tasks at the point at which they wait for network calls to finish.
- james-revisoai 3y agoIt feels like this but every time we remove such an issue (and you're right, it's usually I/O or OCR/ML inference), we just get another. Whether it's the cloud blocking new GPU allowance increases for a week (I think this is true for most small projects right now), or the fact we know certain traffic will be for at most 2 weeks and so isn't that useful, we just struggle with the strategic view of managing demand. Just feels like plasters after plaster and hoping we won't realise on Monday that half of users had extremely slow experiences due to a new bottleneck. It's almost like doing fast for 80% of users and never working for 20% is much worse(for UX and future business), than slow for all 50% if you know what I mean because of the importance of reliability... but there are basically few discussions that are this high level... that you can talk in understandable terms to the rest of the C-suite with. Sorry to sort of rant... maybe a first dev ops hire is best.
- yuppie_scum 3y agoNobody said this was going to be easy. Read the DevOps classics: The Phoenix Project, the DevOps Handbook, and the Google SRE book.