У меня есть небольшое приложение RoR, которое генерирует изображения с помощью RMagick, и его производительность далеко не такая, как я думал. Конфигурация сервера представляет собой 64-битный образ Ubuntu 11.04 на EC2, работающий под управлением Rails 3.1RC4 / Ruby 1.9.2 / Nginx / Passenger. Я пробовал несколько разных типов инстансов Amazon, от маленьких (с 32-битным изображением) до c1.xlarge, и результаты очень похожи.
Запуск ApacheBench (ab -n 10 -c 1) дает мне приемлемое среднее время отклика в 300 мс, а тест завершается примерно через 2 секунды, но увеличение его до 5 одновременных или даже 2 одновременных запросов снижает производительность до 1500 мс, и тест занимает дольше. Даже для большого типа экземпляра команда ab run (ab -n 10 -c 10) замедляет работу системы до 5000 мс. Я ожидал, что время отклика останется в значительной степени постоянным, но общее время упадет. Это неверное предположение? В каждом тесте память никогда не поднимается очень высоко (<1 ГБ), но процессоры работают на 100%. Мой MacBook Pro, работающий в режиме разработки, может соответствовать этим числам.
Кажется, что что-то где-то однопоточное. Приложение почти настолько простое, насколько это возможно, и единственная сложность - это вызовы RMagick. Есть ли что-то в RMagick, что вызывает проблемы с потоками? Есть ли лучший сервер приложений RoR для этого типа вещей (Unicorn, Mongrel cluster и т. Д.)? Я неправильно использую ApacheBench?
ОБНОВИТЬ
Я добавил в конфигурацию несколько новых текстовых маршрутов, и они работают очень хорошо. Возврат 32 КБ обычного текста практически не вызывает проблем с процессором, и я могу достичь 72 запросов в секунду (что, вероятно, ограничено моим подключением к Интернету, а не сервером EC2). Возвращение 5 байтов дает мне более 250 запросов / сек.
Существует так много возможностей ... тот факт, что существует явное отсутствие параллелизма, указывает на отсутствие надлежащей конфигурации Passenger (passenger_max_pool_size - ключевая переменная), но при использовании rmagick проблема может заключаться в дисковом вводе-выводе (тома EBS имеют ужасающую - и непостоянную - производительность). С другой стороны, тот факт, что статистика вашей системы говорит о том, что ЦП работает на максимум, указывает на то, что либо rmagick безумно жует ЦП (делает какие?) или другая неэффективность вашего кода, из-за которой процессоры зависают (хотя, если вам удастся вытащить это на c1.xlarge, я впечатлен).
Увеличьте размер пассажирского пула и собирайте более точную статистику по процессам и всей системе о том, что на самом деле происходит, и ответ должен появиться сам.
Мы только что отладили причину проблемы с производительностью в стеке Rails 3 + Nginx + Passenger + PostgreSQL на EC2. микро экземпляры. Они делают так называемое регулирование ЦП, что довольно хорошо объясняется в этом сообщении в блоге: http://gregsramblings.com/2011/02/07/amazon-ec2-micro-instance-cpu-steal/
Мы провели несколько стресс-тестов и не смогли найти узкое место, но вся система тормозила. Именно тогда мы увидели 100% кражу процессора.
Решение состоит в том, чтобы перейти на малый тип экземпляра, который, похоже, не выполняет регулирование, или попробовать другую службу хостинга, такую как Rackspace.
Ответом на эту загадку было перекомпилировать ImageMagick и отключить OpenMP. По-видимому, все потоки боролись за контроль, и переключение процессов полностью убивало производительность. После перекомпиляции один ECU мог обрабатывать больше запросов, чем 16 ECU с включенным OpenMP. Удивительный!