views:

262

answers:

1

Looking at this example of named pipes using Overlapped I/O from MSDN, I am wondering how scaleable it is? If you spin up a dozen clients and have them hit the server 10x/sec, with each batch of 10 being immediately after the other, before sleeping for a full second, it seems that eventually some of the instances of the client are starved.

Server implementation: http://msdn.microsoft.com/en-us/library/aa365603%28VS.85%29.aspx

Client implementation (assuming call is made 10x/sec, and there are a dozen instances). http://msdn.microsoft.com/en-us/library/aa365603%28VS.85%29.aspx

+1  A: 

The fact that the web page points out that:

  • The pipe server creates a fixed number of pipe instances.

and

  • Although the example shows simultaneous operations on different pipe instances, it avoids simultaneous operations on a single pipe instance by using the event object in the OVERLAPPED structure. Because the same event object is used for read, write, and connect operations for each instance, there is no way to know which operation's completion caused the event to be set to the signaled state for simultaneous operations using the same pipe instance

you can probably safely assume that it's not as scalable as it could be; it's an API usage example after all; demonstration of functionality is usually the most important design constraint for such code.

If you need 12 clients making 10 connections per second then I'd personally have the server able to handle MORE than just 12 clients to allow for the period when the server is preparing for a new client to connect... Personally I'd switch to using sockets but that's just me (and I'm skewed that way because I've done lots of high performance socket's work and so have all the code)...

Len Holgate
Well putting sockets aside, since I think the focus here is the Windows asynchronous I/O constructs being used, I guess the question is what's a better way to get asynchronous I/O for named pipes with low CPU util. Would doing simultaneous I/O on a single pipe instance really be better performance? Would it beat simply upping the number of instances?I presume that is what you suggested doing above when you said you'd have more than 12 instances if 12 clients were needed?
Leeks and Leaks
I'd use IO Completion Ports if possible as that will give you the most scalable I/O at the expense of some more complexity (you'd also be allowing multiple read/write operations which would mean that you'd be managing multiple 'per operation' OVERLAPPED structures and this would give higher read/write performance). However, perhaps it would be better for you to describe the actual problem in more detail; "starved" is a little vague. Are these clients failing to connect? or failing to send/recv? What problem are you trying to solve here?
Len Holgate