fix: improve autoscaling based on database config. - #206
Conversation
|
@pantierra could you add a short description for this PR? @thenav56 could review and merge if approved? |
|
Sure @wrynearson Hi @pantierra Can you rebase your branch on the latest develop? There are merge conflicts. Merging this PR will update both staging and production. Do you think we should try it on staging first? |
f7a8c23 to
b737abb
Compare
|
Fixed the merge conflict. Ready for your review again. |
thenav56
left a comment
There was a problem hiding this comment.
LGTM, let me know if we are good to deploy this to both staging and prod
|
@thenav56 I think this is straightforward enough and roll-backable enough that I feel comfy going ahead with deploying to staging and prod - let's do it! @pantierra is out today, but I think @wrynearson can help test after this has been deployed - I don't imagine this will have a huge impact either way, but ofc good to do as part of overall improvements. |
|
ArgoCD sync is green for both staging and production. |
|
@wrynearson mind doing just a quick sanity check with one of your notebooks or so hitting both staging and production and seeing that at least there is no major regression in responses / performance? |
|
Seems like responses still perform in a similar way to before the merge – still with many A single-country ( |
|
@wrynearson 👍 ya, did not expect this to cause much change for requests from a single user - as long as there does not seem to be any significant regression, I think this is good, and ya, we will only be able to really tell once we have all the db fixes in, as right now my strong hunch is that the db is the bottleneck, and not API container scaling. Thanks for testing! |
No description provided.