What can cause throughput to become really slow when an ISAPI filter implements SF_NOTIFY_SEND_RAW_DATA?

Question

I have an ISAPI filter for IIS6 that I've been developing for a while, but I just noticed something disturbing. Anytime I have the filter installed and I download a file, the file download becomes really slow. From a remote machine I'm getting ~120kb per second without the filter installed, and ~45kb per second with the filter installed.

This seems to be related to the SF_NOTIFY_SEND_RAW_DATA callback. Whenever I register for this callback, I get the slow downloads, when I don't register for it, everything is fine.

Even if I make my HttpFilterProc function just return immediately, like this:

DWORD WINAPI HttpFilterProc( PHTTP_FILTER_CONTEXT pfc, 
   DWORD notificationType,
   LPVOID pvNotification )
{   
    return SF_STATUS_REQ_NEXT_NOTIFICATION;
}

I've also tried returning SF_STATUS_REQ_HANDLED_NOTIFICATION with the same result.

Is it possible that I have some build setting on my DLL that is causing a slow execution of the callback function, or is this just the way it's going to be with ISAPI?

Answer 1

It has something to do with the internals of IIS and how it implements sending of data. This Microsoft blog post here: http://blogs.msdn.com/david.wang/archive/2005/12/14/How-IIS6-Compression-Schemes-interact-with-ISAPI-Filters.aspx sort of hints at moving data from kernel to user space and inability to use VectorSend. I don't fully understand what the guy is saying, but the take-away seems to be "avoid SF_NOTIFY_SEND_RAW_DATA if you can at all help it".