Date: Mon, 24 Jan 2000 11:39:29 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Scott Hess" <scott@avantgo.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs. Message-ID: <200001241939.LAA91219@apollo.backplane.com> References: <01b601bf6696$60701930$1e80000a@avantgo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I've found an odd performance issue that I cannot explain. I'm using
:socketpairs to communicate with multiple rfork(RFPROC) processes.
:Initially, I used a seperate socketpair to communicate requests to each
:...
:
:Unfortunately, I've found that having a group of processes reading from a
:group of socketpairs has better performance than having them all read from
:a single socketpair. I've been unable to determine why. I've reduced the
:problem down to a simple program, included as an attachment (sorry about
:that). The results of two runs of the program:
The problem is that when you have N processes waiting on a single
socket and you write to the socket, all N processes will wake up even
though only one will get the data you wrote.
This is very similar to the select() problem -- N processes select()ing
on the same descriptor (typically a socket listen descriptor), new
connection comes in, all N processes are woken up even though only one's
accept() will succeed.
As an alternative to socket pairs, I would consider using SysV shared
memory and SysV semaphores. Under -current you can use shared file
mmap()'s with MAP_NOSYNC as an alternative to using SysV shared memory,
but the SysV shared memory calls will be more portable. ( When messing
with SysV shared memory the system utility 'ipcs -a' comes in useful ).
man -k shm
man ipcs
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001241939.LAA91219>