Mathieu Pillard

I created [a dashboard to monitor performance of all "external" services in AMO](https://earthangel-b40313e5.influxcloud.net/d/SEUKky0Gz/amo-external-services-perf?orgId=1). It doesn't distinguish between taar and taar lite (we use the same statsd timer) but it clearly...

Perf hit does coincide with [the date we switched TAAR to GCP](https://bugzilla.mozilla.org/show_bug.cgi?id=1651393#c27) (09/24). That cost us ~200ms per call, which is not great, but I still can't explain the second...

Revisiting this issue with some profiling data on dev. We can see that for both the call to taar-lite and taar... it's happening twice! That's because we're calling `https:////` -...

Actually that's wrong - in both cases, we are ending with a `/`. Sometimes taar does take a while to answer...

See also https://github.com/mozilla/addons/issues/8118

See also https://github.com/mozilla/taar/issues/113

There are a couple compounding issues causing this: - When the queryset has a `distinct()`, Django wraps the full query in a subquery and counts on that. We can try...

Closing because mozilla/addons-server#15401 should help, please re-open if that's no the case once it hits prod.

The rather dramatic perf hit can be seen on Grafana: https://earthangel-b40313e5.influxcloud.net/d/sGEtfYcZk/amo-reviewer-tools-performance-and-monitoring?viewPanel=8&orgId=1&from=now-90d&to=now

The problematic query in all its glory: ```sql SELECT DISTINCT `addons`.`created`, `addons`.`modified`, `addons`.`id`, `addons`.`guid`, `addons`.`slug`, `addons`.`name`, `addons`.`defaultlocale`, `addons`.`addontype_id`, `addons`.`status`, `addons`.`icontype`, `addons`.`icon_hash`, `addons`.`homepage`, `addons`.`supportemail`, `addons`.`supporturl`, `addons`.`description`, `addons`.`summary`, `addons`.`developercomments`, `addons`.`eula`, `addons`.`privacypolicy`, `addons`.`averagerating`,...