1407016 - Speed up saving translations

Status: RESOLVED FIXED

(Webtools Graveyard :: Pontoon, enhancement, P2)

Description

[Matjaz Horvat [:mathjazz]]

When a new translation is submitted, or existing translation is (un)approved or rejected, we update stats using the TranslatedResource.calculate_stats() method.

It identifies translation status *for each string within the file* and then calculates diff for each status count on a file level. It uses the diff to update stats for corresponding TranslatedResource, Project, Locale and ProjectLocale instance (stats are denormalized for performance reasons).

While this works well during sync or file upload, it's far from optimal when only one string is updated (like on translation submit).

Instead, we should calculate the diff by checking translation status *for the edited string* before and after submission. Quick testing shows that saving a translation should be 60-80% faster with this optimization.

Marking as P2 as this is a substantial optimization of a critical task. New Relic says that saving a translation is the 3rd most common task (after opening a string for editing and accessing a team page).

Note: This is a continuation of bug 1344658.

Comment 1

[Jarek Śmiejczak [:jotes]]

:mathjazz
The good news is: The problem is reproducible on my machine.

Average response time is around ~100ms for `unapprove`/`reject` views. I can verify that calculate_stats takes around 50-60% of the total time of the request.

I'll post the performance comparison in the PR.

Comment 2

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pontoon/pull/1140

Comment 3

[[github robot]]

Commit pushed to master at https://github.com/mozilla/pontoon

https://github.com/mozilla/pontoon/commit/a18fdd7dc2d204ab6376233b82d573df6119450b
Fix bug 1407016:  Speed up saving translations (#1140)

This patch replaces the expensive file-level calculate_stats() method
with EntityLocale-level get_stats() and get_stats_diff() methods.