RMagick на EC2/Nginx/Passenger производительность ужасна
У меня есть небольшое приложение 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 req/sec (что, вероятно, ограничено моим интернет-соединением, а не сервером EC2). Возврат 5 байтов дает мне более 250 запросов / сек.
3 ответа
Ответом на эту загадку было перекомпилировать ImageMagick и отключить OpenMP. По-видимому, все потоки боролись за контроль, а переключение процессов полностью снижало производительность. После перекомпиляции один ECU может обрабатывать больше запросов, чем 16 ECU с включенным OpenMP. Удивительно!
Существует так много возможностей... тот факт, что существует явное отсутствие параллелизма, может указывать на отсутствие надлежащей конфигурации Пассажира (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.