Re: LISTEN/NOTIFY benchmarks?

prashanth(at)jibenetworks(dot)com kirjutas T, 29.04.2003 kell 04:14:
> Hi,
>
> I'm looking for information on the scalabality of the LISTEN/NOTIFY
> mechanism. How well does it scale with respect to:
>
> - hundreds of clients registered for LISTENs
>
> I guess this translates to hundreds of the corresponding backend
> processes receiving SIG_USR2 signals. The efficiency of this is
> probably OS-dependent. Would anyone be in a position to give me
> signal delivery benchmarks for FreeBSD on Unix?
>
> - each client registered for thousands of LISTENs
>
> From a look at backend/commands/async.c, it would seem that each
> listening backend would get a signal for *every* LISTEN it
> registered for, resulting in thousands of signals to the same
> listening backend, instead of only one.

But as the signals are usually generated async, you have no way to know
if a particular backend has already received a signal.

Or do you mean some mechanism that remembers "signals sent" in some
shared structure that the receiving backend can then clear when it
actually receives the signal ?

That could mean lock contention on that shared structure, unless we
decide that it is cheaper to just consult it without locking it and
accept an occasional delivery of unneeded signals.

> Would it help if this was
> optimized so that a signal was sent only once? Again, info on
> relevant signal delivery benchmarks would be useful.

I still suspect that replacing pg_listener table from the mechanism
would give gains faster. Of course we could rework the signal mechanism
as well while doing it.

> I'm not an expert on signals, not even a novice, so I might be totally
> off base, but it seems like the Async Notification implementation does
> not scale. If it does not, does anyone have a solution for the
> problem of signalling a each event in a possibly very large set of
> events to a large number of clients?

-----------------
Hannu