Нагрузочное тестирование

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

Конечно, вы не сможете обзвонить пользователей и попросить их быстрее щелкать кнопкой мыши, однако повышение нагрузки на сервер можно реализовать посредством повторного воспроизведения запросов. Существует много инструментов такого рода, из которых особенно положительное впечатление оставили два:

  • Httperf (http://www.hpl.hp.com/research/linux/httperf/)
  • Siege (http://www.joedog.org/JoeDog/Siege)

Оба инструмента позволяют взять файл, заполненный URL-адресами HTTP, и перебирать их с разной скоростью для обработки запросов сервером. Это дает возможность увеличивать нагрузку очень медленно и осторожно, что крайне важно в средах с одним компьютером — нагрузочное тестирование не должно парализовать ваш единственный работоспособный сервер. Безопасность метода оставляет желать лучшего, и его следует применять только для незначительного приращения нагрузки в надежных условиях — например, во время периода пониженного трафика.

Искусственное тестирование нагрузки, пусть даже посредством воспроизведения реальных запросов, имеет целый ряд ограничений. Несмотря на возможность контроля за интенсивностью запросов и самими запросами, они все равно не дают точного представления о поведении сервера в критической ситуации.

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

Другое ограничение точное представление отношений «клиент- сервер» присуще всем сценариям нагрузочного тестирования веб-ресурсов. При использовании Httperf или Siege вы сможете имитировать запросы от нескольких клиентов, но в действительности все запросы будут поступать от одного клиентского сервера, на котором выполняется сценарий. Одно из возможных решений основано на запуске сценариев на нескольких машинах. Программа Autobench (http://www.xenoclast.org/autobench/), написанная на Perl обертка для Httperf, обеспечивает возможность скоординированного выполнения сценария на нескольких хостах. Autobench также может собирать сводные результаты.

Но даже результаты Autobench отличны от результатов реальных запросов. Клиенты могут быть разбросаны но всей планете; они могут обладать сильно различающимися сетевыми задержками, скоростями подключения и множеством других переменных факторов.

С повышением интенсивности запросов с одной клиентской машины тоже необходима осторожность. Клиентские ресурсы могут кончиться раньше серверных, что приведет к искажению результатов. Будьте внимательны, чтобы во время этих искусственных тестов не были нарушены ограничения по количеству клиентских файловых дескрипторов, пропускной способности каналов и загрузки процессоров.

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

График сгенерирован на основе данных RRD для одного из вебсерверов Flickr в периоды ежедневных пиков и падений, отсортированных по возрастанию загрузки процессора. Он подтверждает, что загрузка процессора действительно прямо пропорциональна количеству активных процессов Apache, по крайней мере в диапазоне от 40 до 90 процентов загрузки процессора.

Из этого можно сделать вывод, что использование в Flickr загрузки процессора как единственной определяющей метрики мощности веб-серверов достаточно безопасно. Кроме того, эта метрика напрямую связана с объемом работы, выполняемой веб-сервером, и, можно надеяться, еще и с трафиком сайта. Взяв эту информацию за основу, мы в настоящее время установили верхний предел общей загрузки процессора, равный 85 процентам; это дает нам достаточный резерв для того, чтобы справиться со случайными выбросами, но при этом обеспечить эффективное использование серверов.

Дополнительный анализ показывает, что коэффициент между загрузкой процессора и активными процессами Apache составляет около 1,1, что позволяет легко рассчитать одну метрику по известному значению другой. В общем случае нахождение простой связи между статистикой использования системных ресурсов и работой, выполняемой на прикладном уровне, сильно пригодится при переходе к прогнозированию.