3 ms·
>whereas the async frameworks are all pure Python. No it's not pure python. It's a combination. The underlying event loop uses libuv, a C library that's makes
by leafboi 6y ago
>whereas the async frameworks are all pure Python.
No it's not pure python. It's a combination. The underlying event loop uses libuv, a C library that's makes up the underlying core of nodejs. The marker of "Uvicorn" is an indicator of this as "Uvicorn" uses uvlib.
Overall the benchmark is testing a bit of both. The event loop runs on C but it has to execute a bit of python code when handling the request.
>If it's being done via a database on the local machine, and the communication with that database is not being done by something like Unix sockets, but by direct calls into a database library, then that's obviously going to cause latency problems because the worker can't yield during the database call.
I am almost positive it is being done with some form of non blocking sockets. The only other way to do this without sockets is to write to file and read from file.
There is no "direct library calls" as the database server exists as a separate process to the server process. Here's what occurs:
1. Server makes a socket connection to database.
2. Server sends a request to database
3. database receives request, reads from database file.
4. database sends information back to server.
Any library call you're thinking of that's called from the library here may be a "client side" library meaning that the library actually makes a socket connection to the sql server.
- pdonis 6y ago> I am almost positive it is being done with some form of non blocking sockets. Database libraries in Python that support this (as opposed to blocking, synchronous sockets, which are of course common) are pretty thin on the ground. That's why I would have liked to see more details in the article about exactly how the benchmark was doing the database queries. > There is no "direct library calls" as the database server exists as a separate process to the server process. Yes, you're right, I wasn't being very clear. The key question is, as above, whether nonblocking sockets are being used or not.
- zzzeek 6y agothe psycopg2 driver for PostgreSQL supports an async mode which uses PostgreSQL's full blown non-blocking API, this is what I used when I did my tests and might be what was used here. There is also the asyncpg driver that is native to PG's non-blocking API. PG is the one database that does lend itself to async because it has a fully non-blocking client library available. https://www.postgresql.org/docs/12/libpq-async.html https://www.postgresql.org/docs/12/libpq-async.html https://www.psycopg.org/docs/advanced.html#green-support https://www.psycopg.org/docs/advanced.html#green-support https://github.com/MagicStack/asyncpg https://github.com/MagicStack/asyncpg