7a548ea101
Before this change, we used extremely inefficient outer joins as part of a single query of lookup, which was spiking our CPU usage to nearly 100% on the query. We now issue two separate queries for popularity and action account, by doing a lookup of the previously found IDs. Interestingly enough, because of the way the queries are now written, MySQL can actually do both queries *directly from the indicies*, which means they each occur in approx 20ms! Verified by local tests, postgres tests, and testing on staging with monitoring of our CPU usage during lookup |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| billing.py | ||
| build.py | ||
| discovery.py | ||
| image.py | ||
| logs.py | ||
| organization.py | ||
| permission.py | ||
| prototype.py | ||
| repoemail.py | ||
| repository.py | ||
| repositorynotification.py | ||
| repotoken.py | ||
| robot.py | ||
| search.py | ||
| subscribe.py | ||
| suconfig.py | ||
| superuser.py | ||
| tag.py | ||
| team.py | ||
| trigger.py | ||
| user.py | ||