IIS 8.5 одиночный рабочий процесс против производительности Web Garden

Question

У меня есть простое приложение ASP.NET, которое просто изменяет размер изображений с помощью ImageResizer и ничего не делает. Для тестирования я отключил кэширование дисков, поэтому изображения изменяются по каждому запросу.

Когда я проверить производительность приложения с JMeter я получаю следующий среднее время отклика:

• одного процесса работника, 1 одновременных клиентов: ~ 200мса
• одного рабочего процесса, 10 одновременных клиентов: ~ 1200ms
• 4 рабочих процессов, 10 одновременных клиентов: ~ 300мс

Как вы можете видеть, когда я бегу одного рабочего процесса и 10 одновременных клиентов, время отклика увеличивается Др несмотря на имеющиеся аппаратные ресурсы: использование ЦП при тестировании производительности составляет ~ 30%, использование памяти - 150 МБ.

Как обсуждалось here,

Веб-сады были разработан для одной единственной причины - Предложение приложений , которые не является CPU переплет, но выполнять длительные запросы способности масштабировать и не использовать все потоки, доступные в рабочий процесс.

Это не выглядит как мое дело.

Итак, я не понимаю, почему я получаю такой результат. Я ожидаю, что даже один рабочий процесс обеспечит приемлемое время отклика до тех пор, пока он не достигнет пределов ресурсов. И 10 одновременных клиентов не зависят от нагрузки. Может ли кто-нибудь объяснить мне, где я ошибаюсь?

Моя конфигурация:

• Windows Server 2012 R2
• IIS 8.5 со всеми настройками по умолчанию (за исключением MaxWorkerThreads)
• четырёхъядерный i3 3.4GHz CPU
• 16 GB RAM

Мое приложение - это простое приложение ASP.NET MVC с ImageResizer, добавлено как в this instruction (опция 3 - Руководство I nstallation) и с плагином DiskCache отключен в Web.config

Answer 1

Я нашел ответ благодаря комментарию @ Ben.

Проблема заключается в том, что ImageResizer основан на GDI + (как указано на it's site), который содержит замки внутри (см. this и this сообщения). Вот почему он работает так медленно в одном процессе.

После выяснения причины проблемы я попробовал this solution. Ссылка на сборки WPF из приложения ASP.NET, вероятно, не самая лучшая идея, но это нормально для тестирования.

Теперь я получаю следующие результаты, когда я выполнять те же тестирование производительности, как и в вопросе:

• одного рабочего процесса, 1 параллельный клиент: ~ 90 мс
• одного рабочего процесса, 10 одновременных клиентов: ~ 120мс
• одного рабочего процесса, 40 одновременных клиентов: ~ 190ms
• одного процесса рабочий, 60 одновременных клиентов: ~ 400мс
• одного рабочего процесса, 80 одновременных клиентов: ~ 630ms

Как видите, приложение работает намного быстрее. Также он использует почти все доступные ресурсы ЦП под высокой нагрузкой, как я и ожидал изначально.

Таким образом, если вы обрабатывать изображения в приложении ASP.NET:

• не использовать GDI + на основе решения, если вы можете
• , если вы должны использовать GDI +, увеличение MaxWorkerProcesses в Приложеиние настройки пула