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 по дате отправления: