From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Teach pgbench to benchmark LISTEN/NOTIFY? |
Date: | 2025-10-02 06:09:37 |
Message-ID: | 4950f2bb-1526-49d8-9a0e-8f3323b4eed5@app.fastmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-10-02 06:30:19 | RE: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Previous Message | John Naylor | 2025-10-02 05:44:21 | Re: GB18030-2022 Support in PostgreSQL |