Что может привести к тому, что пропускная способность станет очень низкой, когда фильтр ISAPI реализует SF_NOTIFY_SEND_RAW_DATA? - PullRequest
Новая
       8

Что может привести к тому, что пропускная способность станет очень низкой, когда фильтр ISAPI реализует SF_NOTIFY_SEND_RAW_DATA?

1 голос
/ 17 ноября 2009

У меня есть ISAPI-фильтр для IIS6, который я разрабатывал некоторое время, но я только заметил, что что-то беспокоит. Каждый раз, когда у меня установлен фильтр, и я загружаю файл, загрузка файла становится очень медленной. С удаленного компьютера я получаю ~ 120 КБ / с без установленного фильтра и ~ 45 КБ / с с установленным фильтром.

Похоже, это связано с обратным вызовом 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?

1 Ответ

0 голосов
/ 27 января 2010

Это как-то связано с внутренними компонентами 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, если вы вообще можете помочь».

...