当 ISAPI 过滤器实现 SF_NOTIFY_SEND_RAW_DATA 时，什么会导致吞吐量变得非常慢？
我有一个用于 IIS6 的 ISAPI 过滤器，我已经开发了一段时间，但我刚刚注意到一些令人不安的事情。每当我安装过滤器并下载文件时，文件下载都会变得非常慢。在没有安装过滤器的情况下，从远程计算机上我每秒获得约 120kb 的数据，在安装过滤器的情况下每秒获得约 45kb 的数据。
这似乎与 SF_NOTIFY_SEND_RAW_DATA 回调有关。每当我注册此回调时，我都会下载缓慢，当我不注册时，一切都很好。
即使我让我的 HttpFilterProc 函数立即返回，如下所示：
DWORD WINAPI HttpFilterProc( PHTTP_FILTER_CONTEXT pfc,
DWORD notificationType,
LPVOID pvNotification )
{
return SF_STATUS_REQ_NEXT_NOTIFICATION;
}
我也尝试返回 SF_STATUS_REQ_HANDLED_NOTIFICATION 并获得相同的结果。
是否有可能我的 DLL 上有一些构建设置导致回调函数执行缓慢，或者这就是 ISAPI 的情况？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这与IIS的内部结构以及它如何实现数据发送有关。此 Microsoft 博客文章位于：http://blogs.msdn.com/david.wang/archive/2005/12/14/How-IIS6-Compression-Schemes-interact-with-ISAPI-Filters.aspx 一些关于将数据从内核移动到用户空间以及无法使用 VectorSend 的提示。我不完全明白这个人在说什么，但要点似乎是“如果你能帮助的话，请避免 SF_NOTIFY_SEND_RAW_DATA”。
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".