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 wou
ld
be any tricks regarding io setting (setbuf, etc) which would optimize io und
er
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 i
pc
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
 ========================================
====================================
===

[ Post a follow-up to this message ]

"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 sa
me
> process.
>
> the code works fine and is plenty fast.  however, i'm wondering if there w
ould
> be any tricks regarding io setting (setbuf, etc) which would optimize io u
nder
> these situations.
>
> i've considering doing a roll yer own mmap com protocol - but it seems lik
e
> 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

[ Post a follow-up to this message ]

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 sam
e
>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...[/vbcol
]

Why does it seem like this?  More calls is not the same as slower.  Some cal
ls
take hundreds of times as long as others.  You'll have to measure the
difference to tell what's faster for your app.
[vbcol=seagreen]
>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/>

[ Post a follow-up to this message ]

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 sa
me
> process.
>
> the code works fine and is plenty fast.  however, i'm wondering if there w
ould
> be any tricks regarding io setting (setbuf, etc) which would optimize io u
nder
> 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

[ Post a follow-up to this message ]

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 ar
e
nowhere near that big - only a few K.  in fact, most coms occur with a singl
e
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
 ========================================
====================================
===

[ Post a follow-up to this message ]

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 optimizati
on
> 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 usin
g
> 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/loopin
g
cgi-server.  with fastcgi i can get about 180 rps and with this protocol onl
y
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 fr
om
> 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 strea
ms
> 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 th
e
> 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
 ========================================
====================================
===

[ Post a follow-up to this message ]