Teach pgbench to benchmark LISTEN/NOTIFY? - Mailing list pgsql-hackers

From Joel Jacobson
Subject Teach pgbench to benchmark LISTEN/NOTIFY?
Date
Msg-id 4950f2bb-1526-49d8-9a0e-8f3323b4eed5@app.fastmail.com
Whole thread Raw
List pgsql-hackers
Dear fellow hackers,

Benchmarking LISTEN/NOTIFY is quite complex, due to the two commands
depending on each other. It's not only how fast each command can be
executed that matters, it's also the delivery of the notifications.

I've come up with a benchmark that seems very suitable as a baseline,
which measure how many round-trips can be made per second, between two
processes that both LISTEN on their own unique channels, and then NOTIFY
the other as soon as a notification is received; a typical ping-pong setup.

Using this as a baseline, we can then measure the effect of things like
additional listening backends on other channels, to observe how the
ping-pong round-trips per second is affected.

I don't think pgbench is currently capable of such a benchmark,
and I wonder if people think it could be interesting adding such
capabilities to it?

I haven't thought much about the command line options,
but maybe something along these lines?

$ ./pgbench --listen-notify-benchmark
pgbench: starting LISTEN/NOTIFY round-trip benchmark
pgbench: round-trips per iteration: 100
pgbench: idle listeners added per iteration: 10

idle_listeners  round_trips_per_sec
            10               1351.1
            20               1278.7
            30               1149.8
            40               1070.6
            50                905.5
            60                765.4
            70                730.5
            80                640.3
            90                571.2
pgbench: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL:  sorry, too many clients already
pgbench: reached max_connections at 97 idle listeners
            97                516.4
pgbench: cleaning up connections
pgbench: LISTEN/NOTIFY benchmark completed

/Joel



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: GB18030-2022 Support in PostgreSQL
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: POC: enable logical decoding when wal_level = 'replica' without a server restart