Концепция мощности веб-сервера привязана к конкретному приложению. В общем случае веб-сервер рассматривается как front-end машина которая принимает запросы пользователей, обращается к back-end-pесурсам (например, базам данных), а затем на основании результатов этих обращений генерирует ответы. Одни приложения обращаются к базам данных с простыми, быстрыми запросами, другие с меньшим количеством более сложных запросов. Одни сайты предоставляют в основном статические страницы, другие генерируют главным образом динамический контент. На основании метрик прикладного уровня, как впрочем и системного, формируется обобщенное представление об использовании веб-сервера, которое служит основой для планирования мощностей.

Планирование мощностей для веб-серверов (статических и динамических) ориентируется на пиковые нагрузки, а следовательно, имеет нежесткий характер в отличие от потребления дискового пространства. Серверы ежедневно потребляют широкий спектр аппаратных ресурсов, а их «предел прочности» находится где-то в районе полного поглощения этих ресурсов. Ваша задача заключается в выявлении периодических пиков и использовании их для управления траекторией планирования мощностей. Как и для любого ресурса с пиковыми нагрузками, вы должны определить, когда возникают такие пики, а затем проанализировать причины их циклического возникновения.

Реальный пример: сбор метрических данных для веб-сервера

В качестве примера рассмотрим метрики отдельного веб-сервера на базе Apache, собираемые с разной периодичностью (час, день, неделя). На рисунке представлены графики для всех трех частот сбора данных, на основе которых мы попытаемся определить периодичность пиковых нагрузок.

Распределение количества запросов Apache по часам, дням и неделям

На почасовом графике никакие закономерности не наблюдаются, тогда как на ежедневном графике видно плавное снижение и подъем. В контексте планирования мощностей наибольший интерес представляет еженедельный график, на котором видно, что по понедельникам веб-сервер обрабатывает наибольший трафик. Как говорится, «это то самое место, начинаем копать».

Для начала следует сузить состав анализируемых аппаратных ресурсов. Чтобы сократить список, мы будем игнорировать ресурсы, работающие в рамках своих возможностей во время пиковых нагрузок. Использование памяти, дисковые операции ввода/вывода и сетевые ресурсы (не рассматриваемые сейчас) даже близко не подходят к своим ограничениям во время пиковых нагрузок. Исключив эти ресурсы из списка потенциальных «узких мест», мы получим достаточно важную информацию о мощности нашего веб-сервера. Остается процессорное время, которое, как можно предположить, и является критическим ресурсом. На рисунке показаны два графика загрузки процессора.

Системная и пользовательская загрузка процессора на веб-сервере: представление по дням

Из рисунка видно, что на пике (с объединением пользовательской и системной загрузки) процессор загружен лишь немногим более чем на 50%. Давайте сравним эти данные с фактической работой, выполняемой веб-сервером, и посмотрим, приводит ли загрузка процессора к видимым последствиям на прикладном уровне. На рисунке ниже, представлено количество активных процессов Apache для анализируемого нами времени.

Занятые процессы Apache: представление по дням

Графики, приведенные выше, подтверждают то, что и так очевидно, — количество активных процессов Apache пропорционально загрузке процессора. Согласно самым свежим данным RRD, на 50,7 процентах загрузки процессора (45,20 пользовательская + 5,50 системная) задействовано 46 процессов Apache.

Если предположить, что связь между загрузкой процессора и количеством активных процессов Apache остается неизменной (то есть прямо пропорциональной), до того момента, когда загрузка процессора достигнет какого-то высокого (и вероятно, небезопасного) уровня, не встретившегося на наших графиках, можно вполне обоснованно считать, что мощность процессора в нашей системе достаточна.