Async client libraries - not worth it?
Hi,
I’m writing a new web app, and I’ve been experimenting with some async DB access libraries [1]Mentioned here: https://github.com/pgjdbc/pgadba/issues/17. I also see some discussion online about a future Java standard to replace or supplement JDBC with an async API.
While I understand the benefits of async in some situations, it seems to me that these libraries are not going to give much performance benefit, given the architecture of a PostgreSQL server. (Nothing against PG; probably most RDBMSs are like this.)
I wonder if anyone else has looked at this and agrees, or not. ?
A client library with an async-style API may allow 100,000s of concurrent “operations”, but since the PG server itself doesn’t handle connections on that scale (and has no plans to, I assume?), the client library is really maintaining a queue of operations waiting for a connection pool. Maybe there is some performance benefit there, but the most important point - to free up the front end to handle many HTTP connections - can also happen by combining an operation queue with a synchronous API.
Rob
[1]: Mentioned here: https://github.com/pgjdbc/pgadba/issues/17
On Mon, 17 Jun 2019 at 01:34, Rob Nikander <rob.nikander@gmail.com> wrote:
Hi,
I’m writing a new web app, and I’ve been experimenting with some async DB
access libraries [1]. I also see some discussion online about a future Java
standard to replace or supplement JDBC with an async API.While I understand the benefits of async in some situations, it seems to
me that these libraries are not going to give much performance benefit,
given the architecture of a PostgreSQL server. (Nothing against PG;
probably most RDBMSs are like this.)I wonder if anyone else has looked at this and agrees, or not. ?
A client library with an async-style API may allow 100,000s of concurrent
“operations”, but since the PG server itself doesn’t handle connections on
that scale (and has no plans to, I assume?), the client library is really
maintaining a queue of operations waiting for a connection pool. Maybe
there is some performance benefit there, but the most important point - to
free up the front end to handle many HTTP connections - can also happen by
combining an operation queue with a synchronous API.Rob
https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db
Seems to be worth it.
Now it appears that ADBA is going to die on the vine, R2DBC and vertx seem
to be pretty good
Dave Cramer
davec@postgresintl.com
www.postgresintl.com
On Jun 17, 2019, at 1:12 PM, Dave Cramer <pg@fastcrypt.com> wrote:
https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db <https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db>
Seems to be worth it.
Now it appears that ADBA is going to die on the vine, R2DBC and vertx seem to be pretty good
The “async” frameworks are faster, but I think they might be getting the performance gain not from the async DB API, but from the fact that they don’t block OS threads that are handling frontend HTTP requests. They may be using an async DB API to achieve that, but they *could* (I think) also use traditional JDBC and other general purpose concurrency tools from Java’s standard library. That way would be easier to reason about, in my opinion.
I may just have to write something both ways and wait to get real world experience with it to see how it goes.
On Mon, 17 Jun 2019 at 07:35, Rob Nikander <rob.nikander@gmail.com> wrote:
On Jun 17, 2019, at 1:12 PM, Dave Cramer <pg@fastcrypt.com> wrote:
https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=db
Seems to be worth it.
Now it appears that ADBA is going to die on the vine, R2DBC and vertx seem
to be pretty goodThe “async” frameworks are faster, but I think they might be getting the
performance gain not from the async DB API, but from the fact that they
don’t block OS threads that are handling frontend HTTP requests. They may
be using an async DB API to achieve that, but they *could* (I think) also
use traditional JDBC and other general purpose concurrency tools from
Java’s standard library. That way would be easier to reason about, in my
opinion.I may just have to write something both ways and wait to get real world
experience with it to see how it goes.
Yes, the async framework is faster, but ultimately they have to return
something from the database which effectively makes them "block". Postgres
can pipeline requests if the client is written correctly so it is
conceivable that this would be much faster.
Dave
On Jun 17, 2019, at 3:57 PM, Dave Cramer <pg@fastcrypt.com> wrote:
[…] Postgres can pipeline requests if the client is written correctly so it is conceivable that this would be much faster.
Can the JDBC driver do this? I don’t see it documented anywhere.
On Mon, 17 Jun 2019 at 09:43, Rob Nikander <rob.nikander@gmail.com> wrote:
On Jun 17, 2019, at 3:57 PM, Dave Cramer <pg@fastcrypt.com> wrote:
[…] Postgres can pipeline requests if the client is written correctly soit is conceivable that this would be much faster.
Can the JDBC driver do this? I don’t see it documented anywhere.
No, as it's blocking. It's conceivable that we could do it in the batch
stuff .
Dave Cramer
davec@postgresintl.com
www.postgresintl.com