Проблема адекватной оценки производительности веб

ПРОБЛЕМА АДЕКВАТНОЙ ОЦЕНКИ ПРОИЗВОДИТЕЛЬНОСТИ
ВЕБ-СЕРВЕРОВ В КОРПОРАТИВНЫХ СЕТЯХ НА ПРЕДПРИЯТИЯХ ЦБП
О. В. Гусев, В. В. Поляков, А. В. Жуков, С. В. Поляков
ПетрГУ, Петрозаводск
В настоящее время интранет-архитектура стала одной из наиболее популярных при
реализации корпоративных информационных систем в независимости от размеров и
специфики предприятия. Преимуществами данной архитектуры являются ее относительно
низкая стоимость реализации и сопровождения, сочетаемая с широкими функциональными
возможностями.
Веб-сервера становятся привычными элементами вычислительных сетей
предприятий ЦБП и энергетики. Однако с ростом количества и увеличения сложности
задач, решаемых с использованием интранет-архитектуры, встает проблема определения
уровня загруженности основного компонента данной архитектуры – веб-сервера.
В условиях постоянного увеличения нагрузки может наступить ситуация, когда
производительности сервера будет недостаточно для решения поставленных задач.
С целью предотвращения перегрузки веб-серверов, с одной стороны, и
неэффективного расходования их аппаратных ресурсов – с другой, применяют различные
методы оценки уровня загруженности сервера.
Для оценки производительности веб-сервера необходимо выделить показатель,
который выступал бы в качестве меры производительности. Так как веб-сервер
обрабатывает поступающие к нему запросы (заявки), то в качестве такой меры можно
использовать количество успешно обрабатываемых заявок в секунду и время обработки
одной заявки.
Величины, в которых можно измерить производительность веб-сервера, разделяют
на качественные и количественные.
К качественным величинам можно отнести то, что видит пользователь на экране:
– сообщение об ошибке соединения с сервером;
– сообщения о превышении времени ожидания ответа, код ответа, возвращенного
сервером клиенту.
Основными количественными показателями производительности веб-сервера
являются промежутки времени от отправки запроса до получения первого и последнего
байтов ответа. Ясно, что время загрузки страницы (промежуток от получения первого байта
ответа до получения последнего) сильно зависит от размеров страницы. Однако при этом
понятно, что увеличение производительности подразумевает сокращение промежутков
собственно
загрузки
страницы
и получения первого байта ответа.
Стоит отметить, что в общем случае время ответа и скорость его получения зависят
от целого ряда аппаратных параметров сервера, таких как:
– количества и быстродействия процессоров;
– объема оперативной памяти;
– скорости жесткого диска;
– эффективной операционной системы.
Несомненно, важным условием быстродействия является выбор архитектуры
интранет-приложения. Среди основных видов архитектур интранет-приложений можно
выделить следующие:
– статические ресурсы – файлы, которые хранятся на сервере и отправляются
клиенту по запросу;
– CGI-, ISAPI-программы, запускающиеся на сервере в момент получения запроса и
динамически генерирующие ответ для каждого конкретного запроса;
– скрипты, интерпретируемые на сервере программы, создающие ответ
непосредственно перед отправкой.
Традиционные способы увеличения производительности сервера, к которым можно
отнести кэширование документов, эффективно работают лишь при обращениях к
статическим ресурсам. Для динамических ресурсов (веб-приложений и скриптов) такие
меры или неэффективны, или малоэффективны. Существуют несколько способов
увеличения быстродействия динамических ресурсов, однако самыми распространенными
по-прежнему остаются оптимизация кода приложений и аппаратная модернизация.
Говоря о производительности сервера, нельзя обойтись без оценки уровня
загруженности сервера: к сожалению, не существует какой-то одной характеристики,
позволяющей точно указать уровень загрузки веб-сервера. Даже уровень использования
процессора не является такой величиной – в результате экспериментов, проведенных на
веб-сервере кафедры ПМиК, выяснилось, что при полном использовании процессора
сервер вполне может достаточно хорошо справляться с поступающими на него запросами.
Подходы к проблеме оценки производительности веб-серверов
Оценка производительности веб-сервера происходит при помощи тестирования,
которое может быть двух видов:
– нормальное тестирование;
– экстремальное тестирование.
Выбор варианта тестирования зависит от того, для чего проводится оценка уровня
производительности веб-сервера: для определения текущего уровня использования
возможностей сервера либо для определения его потенциальных возможностей.
При нормальном тестировании поток запросов примерно соответствует штатному
для данной веб-службы.
При экстремальном тестировании поток запросов строится таким образом, чтобы
полностью исчерпать возможности сервера по обработке запросов, т. е. определить
предельные возможности веб-сервера по количеству запросов в секунду.
Стоит отметить, что при увеличении количества запросов кривая общей загрузки
сервера растет не пропорционально. Это стоит учитывать при анализе результатов.
Происходит это из-за того, что внутренние составляющие влияют на работу друг друга,
поэтому перегрузка хотя бы одного компонента, как правило, вызывает каскадное
уменьшение производительности остальных компонентов, от него зависящих, в результате
наблюдается резкий спад общего быстродействия.
Рис. 1. Фазы зависимости между интенсивностью входного потока запросов
и числом обработанных запросов
Выделяют три фазы зависимости между интенсивностью входного потока запросов
и числом обработанных запросов в единицу времени: при небольшом количестве время
ответа не зависит от числа запросов (эту фазу еще называют линейной). На второй фазе
время ответа слабо зависит от количества поступающих запросов; на фазе насыщения
каждый дополнительный запрос вызывает сильное увеличение времени ответа, здесь
вполне возможны ситуации, когда клиент может получить сообщение об ошибке или
перегрузке сервера.
Методика тестирования производительности для оценки уровня
эффективной загрузки веб-сервера корпоративной сети предприятия ЦБП
Для оценки количества запросов, которые потенциально может обработать сервер,
удобнее всего использовать распределенную трехуровневую схему. Во-первых, тогда
ситуация наиболее похожа на реальную ситуацию работы. Во-вторых, сервер, в
большинстве случаев, самый производительный компьютер в корпоративной сети,
поэтому для того, чтобы его тестировать, необходимо располагать достаточными
ресурсами. При реализации распределенной схемы сделать это довольно просто –
обеспечить достаточное количество вспомогательных элементов.
з ап
рос
запрос
Рабочие
единицы
тестирования
Ответ
Центр управления
тестированием
Локальная
сеть
Ответ
запрос
Веб-сервер
рос
з ап
Рис. 2. Трехуровневая схема тестирования интранет-серверов
При этом ключевую роль играет центр управления тестированием (иногда его еще
называют консолью управления тестированием). Он контролирует узлы управления
тестированием (сервера управления заданиями), которые в свою очередь контролируют
рабочие единицы тестирования. Рабочие единицы тестирования непосредственно
отправляют запросы к веб-службе, выступая в качестве клиентов. В некоторых случаях
уровень узлов управления может отсутствовать ввиду небольшого числа рабочих единиц,
однако на схеме представлен общий случай. Разделение схемы на уровни необходимо для
простоты администрирования всего комплекса.
Накопление информации о ходе тестирования осуществляется на уровне рабочих
единиц тестирования (регистрируются коды ответов, время получения первого и
последних байтов ответа с момента отправки запроса) и веб-сервера (журналы
производительности, файлы регистрации веб-сервера).
Продолжительность эксперимента выбирается исходя из многих факторов, таких как
количество приложений, установленных на сервере, конфигурация аппаратного
обеспечения и т. п. В среднем время проведения эксперимента составляет несколько
минут, однако оно может варьироваться в зависимости от специфики ресурса.
Подобные схемы тестирования производительности могут применяться как для
прогнозирования поведения веб-сервера в экстремальной ситуации, так и для отладки
приложений и обнаружения узких мест программного обеспечения до их промышленного
внедрения.
Литература
1. Рогов С. Тестирование производительности веб-серверов / С. Рогов, Д. Намиот //
http://www.osp.ru/os/2002/12/055.htm.
2. Черняк Л. Снова о тестах TPC / Л. Черняк // Открытые Системы. 2000. № 11.
3. Goschl S. Microsoft Web Applications Stress Tool. JUGAT Meeting, 12 Junе 2001 /
S. Goschl // www.javausergroup.at/events/was.pdf.
4. OpenSTA Documentation. Open System Testing Architecture Organization //
www.opensta.org/docs/index.html.
5. SPECweb99.
Standard
Performance
Evaluation
Corporation,
1999
//
www.spec.org/osd/web99/docs/whitepapers.html.