Open theobouwman opened 2 weeks ago
Since it is done in single trace, I guess it was processed in one handler. Sqlalchemy session releases connection to pool internally on the end of transaction. On the next request it is obtained again, but depending on what else happens in the service it can be reused on new connection is created.
We need to see pool size and if there we concurrent requests processed.
I am also a bit nervous about seeing 700ms delay in single span. What was there?
I am not sure, it is related to dishka. Do you have more questions regarding this?
The 700ms delay is because multiple external apis are being called. I think it is because sessions get openend and closed multiple times in the /auth/token request. Like after get_by_email
and get_all_by_uid
the session is closed automatically, so when it needs a session after that it creates one. So i need to figure out how to prevent this and keep one session per request.
We are using dishka for DI with SQLALchemy and postgres with connection pooling. As you can see in some tracing examples below, there is sometimes a
db connect
span with is correct. But we also have API calls where multipledb connect
span are registered (see second screenshot). Are we doing something completely wrong?Here our DI:
Screenshot of trace 1:
Screenshot of trace 2:
Here our
user_repo
code:And here the
user_service
code: