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

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

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

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

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

Как обсуждено здесь,

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

Это не кажется как мой случай.

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

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

  • Windows Server 2012 R2
  • IIS 8.5 со всеми настройками по умолчанию (кроме MaxWorkerThreads)
  • четырехъядерный процессор i3 3.4 ГГц
  • 16 ГБ ОЗУ

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

Источник

1 ответ

Решение

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

Проблема в том, что ImageResizer основан на GDI+ (как указано на его сайте), который содержит блокировки внутри (подробности см. В этом и этом постах). Вот почему он работает так медленно в одном процессе.

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

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

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

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

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

  • не используйте решение на основе GDI+, если можете
  • если вам нужно использовать GDI+, увеличьте MaxWorkerProcesses в настройках пула приложений
Источник
Другие вопросы по тегам