New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1407016 - Remove calculate_stats() from Translation.save() #1140
Bug 1407016 - Remove calculate_stats() from Translation.save() #1140
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, just added some comments, mostly nits and name change suggestions.
I still need to look into stats_states_map
, because it doesn't seem to always work as expected (I managed to broke stats locally).
@mathjazz Hey, I moved some lines of code around that could produce those strange results, could you look if the problem still occurs? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well done, I can no longer reporoduce the issue.
Some more nits added.
Fix that and we're good to go I think.
6265905
to
ab1eb78
Compare
352ed16
to
80aea3d
Compare
@mathjazz Hey, Before patch:
After patch:
Could you run this script on your local machine and then (if that makes sense) on the staging to gather some numbers? |
Thanks! I ran the test case twice before and twice after the patch and in both cases the numebrs are consistent: Before:
After:
@jotes Did you want to make any further changes to the patch? I suggest we deploy it to prod, observe numbers in New Relic for a few days and then make further decisions. |
Hey,
If the result is consistent I think it wouldn't hurt to add tests before
this will land on the prod.
Could you run this test on the staging? To just have some baseline numbers
for the future reference.
…On Tue, 11 Dec 2018 at 12:46, Matjaž Horvat ***@***.***> wrote:
Thanks! I ran the test case twice before and twice after the patch and in
both cases the numebrs are consistent:
Before:
unreject avg 0.749211573601 min 0.495611190796 max 1.5232770443
reject avg 0.771279101372 min 0.508476018906 max 2.43999290466
After:
unreject avg 0.0389637184143 min 0.0276548862457 max 0.104743003845
reject avg 0.038744904995 min 0.0286099910736 max 0.11382484436
@jotes <https://github.com/jotes> Did you want to make any further
changes to the patch? I suggest we deploy it to prod, observe numbers in
New Relic for a few days and then make further decisions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1140 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIYMTLXcaWeJV1_xh8kzl4CbSopXw-Ibks5u35r-gaJpZM4ZDJ0E>
.
--
Kind regards
Jarek "jotes" Śmiejczak, a python programmer by day, a mozillian by heart...
Homepage: http://jotes.work, Github: http://github.com/jotes
Mobile: +48693027040, Mozillian: http://mozillians.org/u/jotes
|
Good point about the test case! I've ran the command on Stage and Prod - without the patch applied. I'll run it on stage again after the patch is deployed. Stage - BEFORE:
Stage - AFTER:
Prod - BEFORE:
Prod - AFTER:
|
@mathjazz Hey, |
@jotes Sounds good. However, note that the main idea of pushing this patch to prod at this stage is to gather performance numbers. And if they aren't great, we might need to revert this patch (including the tests). I'm not saying that we shouldn't write tests, but we also don't need 100% coverage, given that the code that is in prod right now also doesn't have it. Besides, if something goes south with stats, we can always fix it with Also, I don't know how thoroughly you plan to test this, and we might even be on the same page, I just wanted to give you a heads-up. :) |
Okay, I'll reduce the number of test-cases (especially plurals) and I'll
ping you when It's done.
…On Wed, 12 Dec 2018 at 03:52, Matjaž Horvat ***@***.***> wrote:
@jotes <https://github.com/jotes> Sounds good. However, note that the
main idea of pushing this patch to prod at this stage is to gather
performance numbers. And if they aren't great, we might need to revert this
patch (including the tests).
I'm not saying that we shouldn't write tests, but we also don't need 100%
coverage, given that the code that is in prod right now also doesn't have
it. Besides, if something goes south with stats, we can always fix it with
calculate_stats.
Also, I don't know how thoroughly you plan to test this, and we might even
be on the same page, I just wanted to give you a heads-up. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1140 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIYMTAsek6DwX1hio79KTSjzAVidm3MMks5u4G9qgaJpZM4ZDJ0E>
.
--
Kind regards
Jarek "jotes" Śmiejczak, a python programmer by day, a mozillian by heart...
Homepage: http://jotes.work, Github: http://github.com/jotes
Mobile: +48693027040, Mozillian: http://mozillians.org/u/jotes
|
pontoon/base/models.py
Outdated
@@ -2864,7 +2949,8 @@ def reject(self, user): | |||
self.approved_user = None | |||
self.approved_date = None | |||
self.fuzzy = False | |||
self.save() | |||
if save: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose is to change the state of translation and not trigger stats recalc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this approach doesn't even "change the state of translation", it prevents everything that happens in Translation.save()
. But why do we even need it? It doesn't seem like we use these update_stats/save
params anywhere in the codebase. If the sole purpose of that it to help with tests, I'd simply do translation.approved/reject = True/False
.
The fact that it's slightly different in each of the function (reject()
, unapprove()
, Translation.save()
) also doesn't help.
9018ecc
to
5d623e9
Compare
@mathjazz Can you look again? A couple of tests have been added (only for singulars). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work with tests! Left a few comments.
pontoon/base/models.py
Outdated
@@ -2864,7 +2949,8 @@ def reject(self, user): | |||
self.approved_user = None | |||
self.approved_date = None | |||
self.fuzzy = False | |||
self.save() | |||
if save: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this approach doesn't even "change the state of translation", it prevents everything that happens in Translation.save()
. But why do we even need it? It doesn't seem like we use these update_stats/save
params anywhere in the codebase. If the sole purpose of that it to help with tests, I'd simply do translation.approved/reject = True/False
.
The fact that it's slightly different in each of the function (reject()
, unapprove()
, Translation.save()
) also doesn't help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well done! Please add that comment and we can ship this!
Comparing performance 1 day before and 1 day after deployment of the patch to prod: Note that Counts for anything but
|
Comparing performance 3 days before and 3 days after deployment of the patch to prod:
|
Comparing performance 7 days before and 7 days after deployment of the patch to prod:
|
Howdy,
So, first of all -> I'm not good at naming things. Any suggestions are always welcome!
Main changes:
We don't make the full recalc of stats everytime a translaion is saved/approved/rejected and so on.
Instead of that, We create a small map with states of an entity before and after a translation.
Thanks to that, we're able to generate a diff and apply it to the all AggregatedStats objects.
To give you more perspective, I've made some benchmarks: https://gist.github.com/jotes/c040baa84faab7ce68bbc7875590e9f4
If you have any additional questions/suggestions/metrics that could be useful -> feel free to suggest them.
Misc changes:
calculate_stats
because it was unused.TODO: