Re: LISTEN/NOTIFY benchmarks?

Поиск
Список
Период
Сортировка
От Sean Chittenden
Тема Re: LISTEN/NOTIFY benchmarks?
Дата
Msg-id 20030430012604.GB94932@perrin.int.nxad.com
обсуждение исходный текст
Ответ на Re: LISTEN/NOTIFY benchmarks?  (Gavin Sherry <swm@linuxworld.com.au>)
Ответы Re: LISTEN/NOTIFY benchmarks?
Список pgsql-hackers
> > > 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?
> > 
> > <brainfart_for_the_archives> Hrm.... I should see about porting
> > kqueue/kevent as a messaging buss for the listen/notify bits to
> > postgresql... that does scale and it scales well to tens of
> > thousands of connections a second (easily over 60K, likely closer
> > to 1M is the limit)....  </brainfart_for_the_archives>
> 
> Except that it is FreeBSD specific -- being system calls and all --
> if I remember correctly. If you're going to move to a system like
> that, which is a good idea, best move to a portable system.

You can #ifdef abstract things so that select() and poll() work if
available.  Though now that I think about it, a queue that existed
completely in userland would be better... an shm implementation that's
abstracted would be ideal, but shm is a precious resource and can't
scale all that big.  A shared mmap() region, however, is much less
scarce and can scale much higher.  mmap() + semaphore as a gate to a
queue would be ideal, IMHO.

I shouldn't be posti^H^H^H^H^Hrambling though, haven't slept in 72hrs.
:-/  *stops reading email*  -sc

-- 
Sean Chittenden



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: LISTEN/NOTIFY benchmarks?
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: current breakage with PGCLIENTENCODING