1397725 - [tracker] Improve performance of Pontoon's webapp

Status: RESOLVED FIXED

(Webtools Graveyard :: Pontoon, enhancement, P3)

Description

[[DEACTIVATED] Adrian Gaudebert]

Pontoon is working well, but sometimes it's slow. What do we mean by slow? Some queries take well over 5 seconds, and that's not acceptable. We want to make the website generally faster, bits by bits, and this bug covers that work. 

To track performance of our application, we use New Relic - https://rpm.newrelic.com/ 
We can make good use of Web Page Test as well - https://www.webpagetest.org/

We haven't defined any rules or goals, at the moment we're just taking the obviously slow parts of the app and try to make them fast. But I believe it would be good to set us some rules, like: total load time must not be longer than 2 seconds, or total page weight must not be greater than 200Kb, for example.

Comment 1

[[github robot]]

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

https://github.com/mozilla/pontoon/commit/f8c92972578c5288f07a3af60dd37a80e7c525d7
Bug 1397725: Cache locale projects in translate view (#703)

This splits the number of DB queries and the page load time of the
translate view in half.

Also remove checks that are always True: the project selector widget
is only loaded inside the translate view, to which we always pass a
project and a locale.

Comment 2

[[github robot]]

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

https://github.com/mozilla/pontoon/commit/4348922f5a255fb40456eb9756ca7e9ea5458cb9
Bug 1397725: Prefetch notifications project data (#704)

The average call to the /notifications page triggers 178 base_project
select DB queries, which makes the page slow. With this fix, the number
goes down to 2 and the page is much faster.

We use the same trick on the notifications menu. The impact is less
obvious, because we usually only load the latest 7 notifications.

Comment 3

[ryan]

hi @all - i noticed that you were doing a load of performance speedups.

In pootle we have a contextmanager that lets us print out the sql that django uses in a given chunk of code. Its really handy for debugging slow/repeated/unnecessary sql calls so i thought i would share.

it can be used like:


> from pootle.core.debug import debug_sql
> 
> with debug_sql():
>     do_something_that_makes_slow_sql_calls()


the source is here - https://github.com/translate/pootle/blob/master/pootle/core/debug.py#L54 - feel free to crib it if its useful

cheers

Comment 4

[[DEACTIVATED] Adrian Gaudebert]

Hey, that's sweet! I was doing something like that for local testing, but your solution is much more elegant. Thanks for sharing!

Comment 5

[[github robot]]

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

https://github.com/mozilla/pontoon/commit/1206e52aaa5c3c7474145316117513a89681e3fa
Bug 1397725: Faster Teams and Projects heading data (#705)

Use python to get top instances and aggregated data from projects and
locales QuerySets. It's faster than querying the DB with order_by() and
aggregate().

Speed up available Locales query by 90%.

Comment 6

[Matjaz Horvat [:mathjazz]]

(In reply to ryan from comment #3)
> In pootle we have a contextmanager that lets us print out the sql that
> django uses in a given chunk of code. Its really handy for debugging
> slow/repeated/unnecessary sql calls so i thought i would share.

Thanks for chiming in, ryan. This is very helpful, thanks!

We have Django Debug Toolbar enabled by default in DEV mode, which is also nice, but doesn't help with AJAX requests for example.

Comment 7

[GitHub Bugzilla PR Linker]

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

Comment 8

[Matjaz Horvat [:mathjazz]]

Lowering priority now that performance has been noticeably improved, which is also reflected in the New Relic data (Apdex > 0.95).

Is there are good reason to keep this tracker around?

Comment 9

[[DEACTIVATED] Adrian Gaudebert]

I think we're good for now. :-)