Назад | Перейти на главную страницу

Как правильно рассчитывать на производительность AWS?

Я занимаюсь перемещением веб-приложения с локального сервера, на котором он работал, в другое место для последующего развертывания. В настоящее время я тестирую AWS и Rackspace и пытаюсь опробовать сайт на AWS. Я старался, чтобы эти две среды были как можно более похожими; оба используют довольно простой стек LAMP поверх Fedora 17 с одинаковыми версиями apache, php и т. д. Моя машина для разработки - это доморощенный ящик на базе чипа i7 860 с 32 ГБ памяти; в AWS я обычно использую экземпляр m1.small, созданный на основе их «стандартного» экземпляра Fedora 17, который в некоторых тестах описывается как «Intel Xeon E5-2650 0 @ 1,80 ГГц (1 ядро), память: 2048 МБ» программное обеспечение, которое я использовал. Корневое устройство моего экземпляра AWS настроено как том EBS.

Сайт запущен и работает на обоих устройствах, и я был рад увидеть, что производительность сайта примерно сопоставима, а AWS работает немного медленнее. Тем не менее, я также выполняю кодирование видео в рамках работы над сайтом с помощью версии ffmpeg, которую я создал из исходников на обоих сайтах. Здесь я получаю огромную разницу в производительности: мой сервер разработки примерно в 10 раз быстрее, чем AWS. Я провел несколько тестов, и они показали аналогичную разницу: тест Phoronix «apache» показывает, что мой сервер работает примерно в 12 раз быстрее, чем экземпляр AWS.

Итак, я озадачен. Я понимаю, что описание экземпляра AWS "E5-2650" предназначено только для описательных целей, и что на самом деле у меня нет машины с E5-2650 полностью. Но как правильно думать об этом? E5-2650 кажется безумно быстрым 8-ядерным чипом, по некоторым меркам примерно вдвое быстрее моего i7; может мне стоит подумать, что у меня фактически 1/8 такой машины (1 ядро ​​из 8)? Это все еще не дает мне 10x, но, может быть, это связано с (гораздо) большим объемом памяти моей машины разработки? Или я что-то напортачил с установкой AWS - я примерно на шаг выше полного новичка в AWS, но не намного, так что напортачить вполне возможно. Есть какие-нибудь советы?

У меня есть несколько вариантов для вашего рассмотрения:

Вариант 1: конкуренция за ввод-вывод

Несоответствие в производительности кодирования видео, вероятно, очень мало связано с процессором. Лучше посмотрите на конкуренцию за ввод-вывод. Пока вы кодируете, запустите top, и посмотрите значение %wa в шапке. Это процент времени, в течение которого сервер должен ждать запросов ввода-вывода. Вы хотите, чтобы это число было как можно меньше. В своих системах я начинаю вносить изменения, если вижу, что это число превышает 5% или около того, усредненное за 5-минутный период.

Если вы действительно наблюдаете высокую конкуренцию за ввод-вывод, вы можете сделать несколько вещей. Первым и, возможно, самым простым, было бы перейти на том EBS с выделенными IOP (PIOP). С их помощью вы можете указать, сколько операций ввода-вывода в секунду вам нужно. Вы заплатите за это дополнительно, но это, безусловно, самый простой способ повысить производительность ввода-вывода.

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

Я бы рекомендовал попробовать объем PIOP.

Вариант 2: регулирование ЦП

Еще одна вещь, на которую следует обратить внимание: вы используете m1.small. В этих небольших экземплярах AWS довольно агрессивно регулирует регулирование ЦП, поэтому вы можете подумать о переходе на более крупный экземпляр, возможно, модель с высоким ЦП, например c1.medium. Если AWS снижает нагрузку на ваш ЦП, вы увидите высокие значения в %st (steal) столбец на выходе top.

Вариант 3. Передайте это на аутсорсинг

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