Interesting Blog Posts on High Performance Servers

| 3 Comments

There are some interesting blog posts by Rick Vicik over on the Windows Server Performance Team Blog. Most interesting for me is part three of the three part series on "Designing Applications for High Performance". Whilst parts one and two cover some useful ideas they're pretty general. Part three really digs into the implementation of I/O completion ports and how new API calls can help improve performance and reduce locking within the APIs themselves.

These two pieces of information were especially interesting to me: "While you don't need an event in the Overlapped structure when using Completion Ports because the event is never waited on, if you leave it out, the event in the file handle will be set and that incurs extra locking." - which looks like an easy win if all you need to do is call SetFileCompletionNotificationModes() with FILE_SKIP_SET_EVENT_ON_HANDLE on the socket when it's associated with the completion port.

Likewise; "Even if the I/O completes in-line (and PENDING is not returned), the I/O completion event is set and a completion is queued to the port unless the SetFileCompletionNotificationModes option is used." - will be worth profiling though the code changes are larger due to the fact that the completion would need to be handled in the code that called WSARecv() etc. and the fact that completions could now be handled on threads there weren't in the I/O pool needs to be considered...

Something to investigate for version 6.2 of The Server Framework perhaps.

3 Comments

Incorporating support for SetFileCompletionNotificationModes() into the code wasn't that hard. Right now my performance tests have yet to show any benefit to using both FILE_SKIP_SET_EVENT_ON_HANDLE and FILE_SKIP_COMPLETION_PORT_ON_SUCCESS but I imagine that a) it's pretty small anyway and b) any improvement is most likely to occur when there was likely to be contention on the lock which is no longer used.

Either way I expect that the code will stay in as a conditional compilation option for 6.2.

Hi!
Few months ago i saw your blog post about 'variable naming convention'. I could not find it. Is it possible for you to provide me its link.

The theme of that post is something like:

If there is a function Myfunction(bool throwOnFailure)

then you never call this function like:
MyFunction(true)

You like to call this function as:

bool throwOnFailure = false;
MyFunction(throwOnFailure)

Naeem,

You mean this one? http://www.lenholgate.com/archives/000283.html

Note that I'd probably force that boolean value to be changed to an enum these days; but the localised solution with the named boolean parameter works well if you can't alter the API itself.

Leave a comment