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

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_开发者_如何学CFILTER_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?

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".