Open microamp opened 2 days ago
Example: /api/rpc/rpc_person/
It first runs
RpcPerson.objects.all()
to get all instances of RpcPerson
, which runs the following SQL query under the hood.
SELECT "rpc_rpcperson"."id",
"rpc_rpcperson"."datatracker_person_id",
"rpc_rpcperson"."hours_per_week",
"rpc_rpcperson"."manager_id"
FROM "rpc_rpcperson"
And then, for each row in the result set, it will spawn two additional queries (i.e. 2N+1); one for capabilities, another for roles.
Since there will be only a small number of users, I don't think it will be a problem performance-wise - it's just an example.
Much of the infrastructure so far is designed to drive the iterative review process with the RPC - it's just enough to get UI working just enough to get feedback.
We are close, but not quite to, the point that we have a stable enough idea of what the queries need to return that we should focus on performance. We know, for instance, that most of the early api endpoints dramatically over-return for the views needs, and they will need to be significantly refactored before we optimize them.
Detecting N+1 queries early in the development process would be beneficial.
Scout: https://scoutapm.com/blog/django-and-the-n1-queries-problem
Additionally, other tools are available for use during local development.
Let me know if we are already doing something similar internally.