.NET Remoting can soak up a lot of CPU even when you have only a few hundred calls per second. To determine whether it would be worth working on a channel implementation to improve performance I tinkered around yesterday with an in-process channel which eliminated the cost of moving the call data cross-process. The baseline was a named pipe channel which was achieving around 3000 calls/sec on my dev machine (for a method taking an int and returning a string). The in-process channel, which had client and server running on different threads and synchronized by an event, improved on this but only up to 4000 calls/sec. So it doesn't seem worthwhile to spend a lot of time trying to better the performance of the named pipe channel when any implementation has to transfer the call data cross-process and inevitably achieve considerably less than 4000 calls/sec. This involves marshalling the transport headers and request stream to the server process, and headers and response stream back to the client process.