43 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
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.
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.
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.
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
Hey, that's sweet! I was doing something like that for local testing, but your solution is much more elegant. Thanks for sharing!
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%.
(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.
Created attachment 8906989 [details] [review] Link to GitHub pull-request: https://github.com/mozilla/pontoon/pull/713
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?
Priority: P2 → P3
I think we're good for now. :-)
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.