Модули IIS7 - управляемые или родные?

Question

, поскольку старые фильтры ISAPI рано или поздно умрут, я хочу переписать старый фильтр ISAPI, который использовался в IIS 6, в модуль для использования в IIS 7. Модуль будет использоваться глобально, что означает он будет использоваться на каждом сайте, на Windows Server 2008 R2 с установленным IIS 7.5, на котором будет размещено несколько тысяч веб-сайтов и около 50 пулов приложений.
Мой вопрос сейчас заключается в том, должен ли я писать этот модуль в управляемом или неуправляемом коде? Одной из моих проблем, связанных с управляемым кодом, является массовое потребление памяти из-за накладных расходов .NET Framework. Я не знаю, как это повлияет на производительность сервера.
Я уже писал модули как в управляемом, так и в неуправляемом коде. Так что это не беспокоит мое решение. Но я бы предпочел написать модуль на C #, если нет огромных недостатков.
Есть предложения по этому вопросу?

Answer 1

Рик Страл предложил здравый совет по этой теме, который я неоднократно повторял в статьях на learn.iis.net.

Также важно понимать потенциал неправильных действий со всей этой силой. Во-первых, имейте в виду, что управляемый код медленнее, чем собственный код на веб-сервере. Вводя управляемый код в главный сервер, вы снижаете производительность веб-сервера. В частности, переключение контекста между управляемым и неуправляемым кодом является дорогостоящим при работе в интегрированном режиме и при наличии управляемых модулей. Я поговорил с некоторыми разработчиками Microsoft, и они пристально следят за оптимизацией этих переключателей контекста, пытаясь как можно больше выполнять пакетные вызовы компонентов управляемого кода, оставаясь в управляемом коде как можно дольше.

Управляемый код не является обязательным по умолчанию - все базовые модули являются нативным кодом, поэтому добавление управляемых модулей является явным решением, которое вы должны принять. Если вы уже используете ASP.NET, то это решение, вероятно, не представляет никакой сложности. Но если вы используете необработанные расширения или модули ISAPI сегодня, вам, вероятно, придется серьезно взглянуть на посмотрите, будет ли управляемый код хорошо соответствовать производительности.

Короче говоря, если все приложения являются ASP.NET, то при написании управляемых модулей для IIS не должно быть никаких накладных расходов или вообще нет - простой выбор.

Однако, если веб-сайты не в противном случае будут загружать CLR, то выполнение этого модуля будет дорогостоящим, и вы захотите тщательно рассмотреть (измерить!) Воздействие на определить, стоит ли снижение производительности прироста производительности во время разработки.

Answer 2

Зависит.

Управляй, если можешь управлять всеми приложениями. Это позволяет чистый управляемый стек. Я бы настаивал на этом;)

По поводу памяти - забудь об этом. Шутки в сторону. Ядро IIS 7 управляется, подключаясь к устаревшему стеку по мере необходимости. Итак, у вас уже есть .NET, нравится вам это или нет. Кроме того, современные серверы обладают небольшим количеством памяти - даже при использовании 32-битных пулов (настоятельно рекомендуется) их еще 50;), а не 64 МБ ОЗУ для сервера;)