|
Home > Archive > Unix Programming > September 2005 > fast ipc
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Ara.T.Howard 2005-09-21, 5:54 pm |
|
i'm writing some code that needs to do synchronous ipc in the fastest way
possbile. essentially one process relays it's stdin and environment to
another process via named pipes and then relays stdout/stderr from that same
process.
the code works fine and is plenty fast. however, i'm wondering if there would
be any tricks regarding io setting (setbuf, etc) which would optimize io under
these situations.
i've considering doing a roll yer own mmap com protocol - but it seems like
all the kernel calls to lock it would outweigh any performance gains made...
maybe not. in any case, does anyone know of such a library? basically an ipc
library that implements blocking reads/writes using shared memory?
cheers.
-a
--
========================================
=======================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
========================================
=======================================
| |
| Pascal Bourguignon 2005-09-21, 5:54 pm |
| "Ara.T.Howard" <Ara.T.Howard@noaa.gov> writes:
> i'm writing some code that needs to do synchronous ipc in the fastest way
> possbile. essentially one process relays it's stdin and environment to
> another process via named pipes and then relays stdout/stderr from that same
> process.
>
> the code works fine and is plenty fast. however, i'm wondering if there would
> be any tricks regarding io setting (setbuf, etc) which would optimize io under
> these situations.
>
> i've considering doing a roll yer own mmap com protocol - but it seems like
> all the kernel calls to lock it would outweigh any performance gains made...
> maybe not. in any case, does anyone know of such a library? basically an ipc
> library that implements blocking reads/writes using shared memory?
Well unless you've got a multiprocessor system you'll want to minimze
the number of context switches. pipes have a small buffer.
In a system where the context switches occur each 1/1000 s, you'll
want a buffer between 1MB ~ 4MB. If you've got an older kernel with
context switches only each 1/100 s, you'll want bigger buffers, on the
order 10MB ~ 40MB.
Of course, you need to be able to produce and consume as much data.
If you can fill this size of buffer, then you can get better
performances using mmap and semaphores.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
| |
| Mark Rafn 2005-09-21, 5:54 pm |
| Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
>i'm writing some code that needs to do synchronous ipc in the fastest way
>possbile.
This kind of requirement usually leads to problems. Almost all optimization
is a tradeoff of some sort, and saying "sync IPC protocol throughput (or
latency?) is the single most important thing we do, with all other
considerations being secondary" doesn't seem correct to me.
What is your actual requirement for throughput (messages and KB per second)
and latency? Use numbers. This will drive the tradeoff decisions in using
IPC methods that are more or less difficult to implement, debug, maintain,
scale, or transition to different hardware or architectures.
For instance, are you willing to move to an IPC mechanism with more
throughput, but also a much higher CPU cost?
Performance requirements are certainly real. But so are many other
requirements, and looking at any one measurement by itself is just
about always wrong.
>essentially one process relays it's stdin and environment to
>another process via named pipes and then relays stdout/stderr from that same
>process.
Ok, and this is broken because pipes are too slow somehow?
>the code works fine and is plenty fast.
Or it's working fine, and you're looking for something to change for no
reason?
>however, i'm wondering if there would be any tricks regarding io setting
>(setbuf, etc) which would optimize io under these situations.
Are you IO bound on pipe performance? Where's this stdin/stdout coming from
that you can't keep up? I imagine a system redesign to use different
endpoint input and output or to skip the middleman entirely may give you
better results than optimizing IPC to be faster than the original io streams
can handle.
>i've considering doing a roll yer own mmap com protocol - but it seems like
>all the kernel calls to lock it would outweigh any performance gains made...
Why does it seem like this? More calls is not the same as slower. Some calls
take hundreds of times as long as others. You'll have to measure the
difference to tell what's faster for your app.
>maybe not. in any case, does anyone know of such a library? basically an ipc
>library that implements blocking reads/writes using shared memory?
In some systems, pipes are implemented using shared memory. Maybe you're
already soaking in it!
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
| |
| Rich Teer 2005-09-21, 5:54 pm |
| On Wed, 21 Sep 2005, Ara.T.Howard wrote:
> i'm writing some code that needs to do synchronous ipc in the fastest way
> possbile. essentially one process relays it's stdin and environment to
> another process via named pipes and then relays stdout/stderr from that same
> process.
>
> the code works fine and is plenty fast. however, i'm wondering if there would
> be any tricks regarding io setting (setbuf, etc) which would optimize io under
> these situations.
Others have posted much fine advice, but I'd add that you might want
to look at using doors if your target OS is Solaris and the IPC is
between processes on the same machine.
WHatever you do, don't fall into the trap of optimising too soon.
Have you measured the performance of your program and are you sure
that IPC is your bottle neck? Microoptimisations can become a real
time waster (of the developer)...
HTH,
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| Ara.T.Howard@noaa.gov 2005-09-21, 5:54 pm |
| On Wed, 21 Sep 2005, Pascal Bourguignon wrote:
> "Ara.T.Howard" <Ara.T.Howard@noaa.gov> writes:
>
>
> Well unless you've got a multiprocessor system you'll want to minimze
> the number of context switches. pipes have a small buffer.
>
> In a system where the context switches occur each 1/1000 s, you'll
> want a buffer between 1MB ~ 4MB. If you've got an older kernel with
> context switches only each 1/100 s, you'll want bigger buffers, on the
> order 10MB ~ 40MB.
>
> Of course, you need to be able to produce and consume as much data.
>
> If you can fill this size of buffer, then you can get better
> performances using mmap and semaphores.
hmmm. the process is relaying web pages from a cgi-server so the buffers are
nowhere near that big - only a few K. in fact, most coms occur with a single
read/write of 4096 so it sounds like mmap would not be worth it eh?
cheers.
-a
--
========================================
=======================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
========================================
=======================================
| |
| Ara.T.Howard@noaa.gov 2005-09-21, 5:54 pm |
| On Wed, 21 Sep 2005, Mark Rafn wrote:
> Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
>
> This kind of requirement usually leads to problems. Almost all optimization
> is a tradeoff of some sort, and saying "sync IPC protocol throughput (or
> latency?) is the single most important thing we do, with all other
> considerations being secondary" doesn't seem correct to me.
>
> What is your actual requirement for throughput (messages and KB per second)
> and latency? Use numbers. This will drive the tradeoff decisions in using
> IPC methods that are more or less difficult to implement, debug, maintain,
> scale, or transition to different hardware or architectures.
the protocol is similar to fastcgi but, instead of an apache module, and
compile binary is used to relay stdin/stdout/stderr to/from a running/looping
cgi-server. with fastcgi i can get about 180 rps and with this protocol only
around 90. the cgi is the same in either case so the overhead is either
fork/exec or io. i think it is io because testing the binary from command
line shows potential to handle about 100-400 request per second. thus i
expect the difference is in io. i don't actually know how many kb i need -
just requests per second. obviously for this application i need throughput
speed.
> For instance, are you willing to move to an IPC mechanism with more
> throughput, but also a much higher CPU cost?
yes.
>
> Ok, and this is broken because pipes are too slow somehow?
yes.
>
> Or it's working fine, and you're looking for something to change for no
> reason?
no.
>
> Are you IO bound on pipe performance? Where's this stdin/stdout coming from
> that you can't keep up? I imagine a system redesign to use different
> endpoint input and output or to skip the middleman entirely may give you
> better results than optimizing IPC to be faster than the original io streams
> can handle.
right. an apache module would do that. however, the whole point of this
system is to provide fastcgi-like performace with zero webserver dependance
other than being able to run cgi programs.
>
> Why does it seem like this? More calls is not the same as slower. Some
> calls take hundreds of times as long as others. You'll have to measure the
> difference to tell what's faster for your app.
googling and reading about a few people who did the same.
>
> In some systems, pipes are implemented using shared memory. Maybe you're
> already soaking in it!
i sure am hoping it does.
cheers.
-a
--
========================================
=======================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
========================================
=======================================
|
|
|
|
|