fast ipc
in [Unix Programming]
|
Prev: core dump
Next: HTTPS client library?
From: Ara.T.Howard on 21 Sep 2005 15:36 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 ===============================================================================
From: Pascal Bourguignon on 21 Sep 2005 16:27 "Ara.T.Howard" <Ara.T.Howard(a)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
From: Mark Rafn on 21 Sep 2005 16:49 Ara.T.Howard <Ara.T.Howard(a)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(a)dagon.net <http://www.dagon.net/>
From: Rich Teer on 21 Sep 2005 17:14 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
From: Ara.T.Howard on 21 Sep 2005 18:06
On Wed, 21 Sep 2005, Pascal Bourguignon wrote: > "Ara.T.Howard" <Ara.T.Howard(a)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. 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 =============================================================================== |