Содержание к диссертации
Введение
Глава 1. Анализ предметной области и определение целей исследования 7
1.1 Определение составляющих эффективности функционирования 7
1.2 Анализ существующих технологий тестирования 17
1.3 Анализ существующих средств тестирования web-серверов 19
1.4 Общие подходы к тестированию web-серверов 28
1.5 Выводы .- 32
Глава 2. Разработка алгоритмов для реализации методики оценки эффективности функционирования WEB-cepвepa 33
2.1 Исследование среды функционирования 34
2.2 Построение и исследование математической модели функционирования web-сервера 34
2.3 Адаптация тестовой модели к реальным условиям работы web-серверов 42
2.4 Разработка методики оценки эффективности функционирования web-сервера 47
2.5 Разработка программного генератора нагрузки 76
2.6 Разработка методики локализации «узких мест» в аппаратной части web-сервера с учетом его специфики работы 83
2.7 Выводы 95
Глава 3. Постановка и проведение модельных экспериментов 96
3.1 Исследование математической модели 97
3.2 Реализация методики оценки эффективности функционирования 100
3.3 Реализация методики поиска «узких мест» в работе web-сервера 109
3.3 Общие рекомендации ПО
3.4 Выводы 113
Заключение 114
Список литературы
- Определение составляющих эффективности функционирования
- Анализ существующих технологий тестирования
- Построение и исследование математической модели функционирования web-сервера
- Исследование математической модели
Введение к работе
Вычислительные и коммуникационные системы используются все чаще и с каждым днем все глубже входят в нашу повседневную жизнь. Компании и отдельные пользователи все больше зависят в своей работе от web-приложений. Web-приложения соединяют различные отделы внутри компаний, различные компании и простых пользователей. Web-приложения очень динамичны, а их функциональные возможности непрерывно растут. Непрерывно возрастает потоковый трафик средств информации и запросов, формируемых переносными и встроенными устройствами. Вследствие этого возрастает сложность систем такого рода. Очевидно, что для понимания, анализа, разработки и управления такими системами нужны количественные методы и модели, которые помогают оценить различные сценарии функционирования, исследовать структуру и состояние больших систем. Наблюдаются тенденции к постоянному росту спроса на web-службы. Таким образом, проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых web-служб и увеличении пользователей Internet. Чтобы избежать многих проблем, связанных с несоответствием реальной и ожидаемой пользователями производительности, необходимы специальные методики планирования производительности.
За последние несколько лет в технологии управления информационными системами изменилась точка зрения на проблему эффективности функционирования web-приложений. Еще недавно считалось, что основными критериями качества работы информационной системы являются характеристики работы оборудования. Считалось, что если значения этих характеристик не превышают установленные пределы, то информационная система работает хорошо. Поэтому основное внимание уделялось вопросам управления активным оборудованием сети.
В соответствии с современной концепцией управления информацион-
5.
ными системами [66, 70] считается, что выводы об их качестве работы следует делать на основании качества работы web-приложений. Если качество работы web-приложений высокое, то информационная система работает хорошо, иначе - плохо. При этом характеристики работы оборудования также важны, но используются, в первую очередь, для выяснения того, почему web-приложения работают плохо и что надо сделать, чтобы улучшить их работу.
На сегодняшний день существует достаточно большое количество компаний
'/ [42, 58, 67, 77, 78, 18, 33, 63], которые занимаются исследованием эффективно-
сти функционирования web-приложений. Причем эти компании предлагают на рынке как собственные услуги по оценке эффективности функционирования приложений заказчиков, так и программные продукты для самостоятельного использования. Был проведен анализ имеющихся средств для оценки эффективности функционирования, который показал, что:
На данный момент нет четко определенного определения того, в чем за-
<# ключается оценка эффективности функционирования web-приложения.
Трактовка определения, как правило, диктуется заказчиком, либо предлагается исполнителем, исходя из имеющихся технических средств для реализации тестирования web-приложения заказчика.
Практически любое web-приложение работает в уникальной среде функ-
V ционирования. Уникальность определяется сочетанием широкого набора
параметров (конфигурация оборудования, используемое программное
обеспечение, архитектура web-приложения, количество и состав целевой
аудитории, режим работы и т.п.). Это приводит к разработке программных
средств тестирования именно конкретной рассматриваемой среды, в кото-
** рой функционирует web-приложение.
Как следствие этого - отсутствие единой технологии оценки эффективно-
сти функционирования web-приложения.
Подводя итог, можно сказать, что проблема эффективности функционирова-
6.
ния является актуальной, и приоритетность этой проблемы непрерывно возрастает с развитием Interaet-технологий. Детальное исследование режимов работы web-серверов и удаленных пользователей позволило бы систематизировать имеющуюся информацию и разработать методику для оценки эффективности функционирования web-сервера на практике.
/.
Определение составляющих эффективности функционирования
Под временем отклика понимается время, прошедшее с момента отправки запроса, до момента получения последнего пакета из ответа на этот запрос [26, 47, 52]. Обязательными составляющими времени отклика являются время обработки запросом на сервере и сетевая задержка. Время обработки запроса на сервере зависит от типа запроса, мощности сервера и его загруженности на момент обработки этого запроса. Сетевая задержка состоит из задержки распространения сигнала по каналам связи и задержки, вносимой активным сетевым оборудованием. Величина сетевой задержки может быть определена с помощью теста QoS (Quality-of-Service). В принципе с помощью этого теста можно получить интегральную оценку качества работы IP-сети. Такой оценкой является совокупность трех характеристик: сетевой задержки, разброса времени прихода пакетов, числа потерянных пакетов. Если в ІР-сети имеет место дефект или «узкое место», то это обязательно отразится на значениях хотя бы на одной из этих характеристик. Поэтому, если эти характеристики в норме, то остальные характеристики, такие как число ошибок передачи данных на канальном уровне, утилизация портов активного оборудования сети и т.п., как правило, можно не анализировать. Значимыми характеристиками в тесте QoS являются следующие параметры: Круговая задержка (round trip delay). Разброс времени прихода пакетов (jitter). Процент потерянных пакетов (packet lost). Число удачных измерений.
Круговая задержка (мс) - это суммарное время, требуемое для передачи пакета от Отправителя к Получателю и обратно. В общем случае круговая задержка включает в себя три вида задержек: задержку распространения сигнала по каналам связи (propagation delay), задержку, вносимую активным сетевым оборудованием (transport delay), задержку, вносимую входным буфером, компенсирующим разброс времени прихода пакетов (jitter buffer delay). Суммарное значение первых двух задержек обычно называют сетевой задержкой (network delay). Однако, при необходимости, можно исключить последний тип задержки (т.к. последняя операция выполняется на машине пользователя) и тогда можно считать, что круговая задержка - это сетевая задержка в обе стороны (propagation delay + transport delay).
При анализе результатов измерений сетевой задержки следует помнить о двух обстоятельствах. Во-первых, значение сетевой задержки не всегда эквивалентно значению круговой задержки, деленному на два. Дело в том, что многие сетевые технологии асимметричны, т.е. производительность в одном направлении может отличаться от производительности в другом направлении. Кроме этого, тестовый трафик в одном направлении может идти по одному маршруту, а в другом направлении - по другому маршруту.
Разброс времени прихода пакетов (мс). Данный параметр характеризует разброс времени прихода числа пакетов за заданный период времени. Иногда этот параметр называют «разброс задержек». Этот параметр может быть вычислен следующим образом. Отправитель, отправляя пакет Получателю, присваивает ему временную метку. Когда Получатель принимает пакет, он присваивает ему еще одну временную метку. На основании этих меток Получатель вычисляет время передачи каждого пакета по сети. В тесте передача пакетов между Отправителем и Получателем осуществляется пачками. Например, каждую минуту в каждом направлении передается пачка из 500 пакетов. Для каждой пачки вычисляется среднее арифметическое значение разброса времени прихода пакетов. Затем вычисляется разброс в одну и другую сторону и из этих значений выбирается наибольшее. Это и есть разброс времени прихода пакетов или «jitter» между парой IP-адресов (Отправителем и Получателем).
Процент потерянных пакетов (%). Данный параметр определяет максимальное число пакетов, потерянных при передаче от Отправителя и Получателя или в обратном направлении за определенный период времени. Существуют две основные причины потери пакетов в IP-сети. Первая причина - это плохое качество среды передачи данных: высокая загрузка, наличие ошибок и т.п. Вторая причина - это слишком большой разброс времени прихода пакетов, вследствие чего пакеты не попадают в буфер (jitter buffer) и отбрасываются приемником. Принято считать, что максимальное пороговое значение числа потерянных пакетов составляет 5%. При анализе процента потерянных пакетов желательно учитывать характер потерь. Потеря пакетов может носить случайный характер, например, когда пакеты теряются по одному и в непредсказуемые моменты времени, а может носить «взрывной» характер, т.е. наблюдается резкий всплеск потери большого числа пакетов за короткий период времени.
Анализ существующих технологий тестирования
В применении к тестированию Internet-приложений часто употребляют термины load testing («нагрузочное тестирование») и stress testing («стрессовое тестирование») [42, 58, 63]. Первый термин обозначает измерение производительности системы в условиях ожидаемой нормальной загруженности, а при стрессовом тестировании уровень нагрузки превышает возможности системы по обслуживанию пользователей. Стрессовое тестирование позволяет определить минимальные величины ресурсов, необходимых для работы приложения, оценить предельные возможности системы (скажем, максимальное число пользователей или максимальную плотность потока запросов) и обнаружить факторы, ограничивающие эти возможности (т.е. найти «узкие места» системы). Кроме того, целью стрессового тестирования может являться обнаружение ошибок в серверном приложении, а также тестирование способности системы к сохранению целостности данных в аварийных ситуациях и к восстановлению после таких ситуаций. Оба типа тестирования часто объединяют под общим наименованием performance testing («тестирование производительности»).
Серверы в сети - типичные системы массового обслуживания, обрабатывающие поток заявок, поступающих в случайные моменты времени. Системы состоят из некоторого числа обрабатывающих единиц - каналов обслуживания [1]. В качестве заявок выступают пользовательские запросы. Пропускная способность системы массового обслуживания зависит от числа каналов и их производительности, а также, что особенно важно для реалистичности тестирования, от характера потока заявок.
Надежность характеризуется вероятностью отказа в обслуживании, а производительность можно измерить либо числом обработанных в единицу времени запросов, либо временем, затрачиваемым на обработку одного запроса. Для оценки качества обслуживания более содержательны временные характеристики - среднее время обработки и дисперсия времени обработки. Наибольшую значимость эти характеристики приобретают в случаях, когда предельное время обработки фиксировано, как, например, для систем резервирования билетов, электронной коммерции, разнообразных банковских приложений и т.д.
Важную информацию предоставляет также анализ зависимости между интенсивностью входного потока запросов и числом обработанных запросов в единицу времени (рис. 1.4). Можно выделить три фазы этой зависимости: линейный рост производительности, отклонение от линейности и насыщение. На первой фазе среднее число обрабатываемых запросов в единицу времени линейно возрастает с увеличением нагрузки, среднее время обработки запроса постоянно. На второй фазе рост производительности уменьшается с ростом нагрузки, среднее время обработки увеличивается. На фазе насыщения роста производительности не происходит, время обработки с увеличением нагрузки неограниченно растет. На форму зависимости пропускной способности от нагрузки влияют: конфигурация оборудования, параметры операционной системы (число нитей управления, размер файла подкачки) и настройки самого приложения. Исследование вида этой зависимости позволяет выявить факторы, оказывающие наибольшее воздействие на производительность, а также обнаружить недостатки проектирования и разработки серверного приложения.
Определенный интерес представляет стабильность пропускной способности приложения, или независимость среднего времени ожидания от выбора интервала времени. Существенные изменения времени ожидания при постоянстве внешних условий сигнализируют о наличии в системе «узких мест», т.е. несбалансированности работы компонентов приложения, операционной системы или оборудования, вследствие которой происходит снижение производительности.
Поведение виртуальных пользователей определяется сценариями, задающими порядок обращения к ресурсам, время задержки между запросами для одного пользователя, а также некоторые другие параметры.
Стандартные тестовые наборы. В группу стандартных тестовых наборов входят SPECweb от Standard Performance Evaluation [67, 71], WebBench компании eTestingLabs [77], WebStone, разработанный MindCraft [78], а также TPC-W от Transaction Processing Performance Council [18, 73]. Первые три пакета позволяют измерять производительность сервера в ответ на запросы статических HTML-страниц или динамического содержимого, генерируемого с помощью CGI-скриптов или API-интерфейса Web-сервера (ISAPI или NSAPI). Поддерживается обработка запросов с использованием SSL. TPC-W в большей мере предназначен для тестирования систем электронной коммерции и потому включает доступ к базам данных, а также позволяет оценить показатель цена/производительность.
Построение и исследование математической модели функционирования web-сервера
Предложенная математическая модель рассматривает систему как «черный ящик». В этом случае, ее отдельные компоненты не моделируются явным образом, а рассматривается только функция производительности. Модель про изводительности уровня системы представляется в виде диаграммы переходов, отражающей состояния, в которых система может пребывать, а также переходы из одного состояния в другое. Общий вид этой модели представлен на рис. 2.2.
Состояние обозначает количество запросов, одновременно обрабатываемых на сервере. Поскольку ресурсы любого сервера конечны, то количество состояний для предложенной модели также конечно. Для каждого состояния і существуют две функции, одна из которых f(ti+i) описывает переход в следующее состояние, а функция g(ii-i) - возврат в предыдущее состояние. Функции f(t) и g(i) являются весовыми функциями, зависящими от времени. Поскольку процесс поступления запросов носит случайный характер, то и времена переходов между состояниями тоже будут различными. Использование математической модели позволило определить динамику поведения web-сервера, выявить и проанализировать факторы, влияющие на изменение состояний web-сервера.
Процессор обрабатывает поступающие запросы не последовательно, а параллельно. Другими словами, если на вход в одном случае будут последовательно поданы два одинаковых запроса, а в другом случае эти же два запроса будут поданы одновременно, то суммарное время обработки в первом случае будет больше, чем во втором случае. Для того чтобы можно было прогнозировать поведение web-сервера, необходимо получить сведения о его работе, а именно, сведения о количестве одновременно обрабатываемых запросов и времени отклика в зависимости от имеющейся нагрузки на сервере. Этого можно добиться несколькими способами. Например, в процессе тестирования сервера, регулируя входной поток запросов, добиться того, чтобы одновременно обрабатывалось строго определенное количество запросов. Поскольку обрабатываться на сервере будет одно и тоже количество запросов, то можно говорить о том, что полученное время отклика будет описывать производительность сервера при одновременной обработке заданного числа запросов. В процессе тестирования необходимо получить сведения о времени обработки запроса на сервере.
Как уже отмечалось в первой главе, для создания нагрузки требуемой величины в тестовых условиях используются генераторы нагрузки. Генератор нагрузки - это специальный программный комплекс, который моделирует работу большого числа пользователей. Работа генератора нагрузки заключается в выполнении заданного сценария тестирования. В сценарии тестирования указываются те ресурсы, которые будут запрашиваться с web-сервера, а также указывается периодичность обращения к этим ресурсам. Кроме того, как правило, для ограничения уровня создаваемой нагрузки используется возможность указания количества одновременных подключений. Возникает вопрос: «Если ресурсы с тестируемого web-сервера запрашивать непрерывно, то будут ли совпадать количество одновременно обрабатываемых запросов на сервере с количеством одновременных подключений, установленных на генераторе нагрузки?». Если да, то тогда, устанавливая на генераторе нагрузке количество одновременно подключений и непрерывно запрашивая их с web-сервера, мы, фактически, получаем сведения о количестве одновременно обрабатываемых запросов. Сведения о времени отклика, которое будет наблюдаться в данной системе, можно получить из отчета, который сформирует генератор нагрузки. Таким образом, увеличивая количество одновременных подключений к web-серверу, мы получим численное значение времени отклика (ВО) для заданного количества одновременно обрабатываемых запросов.
Если действительно окажется так, что генератор нагрузки поддерживает установленное количество одновременных подключений, то на основании полученных численных значений можно будет построить зависимость времени отклика от количества одновременно обрабатываемых запросов на web-сервере. Для проверки характера работы генератора нагрузки была предложена экспериментальная установка, изображенная на рис. 2.4.
Исследование математической модели
Программа-агент, позволяющая определить набор необходимых счетчиков, представлена нарис. 3.10.
Программа-агент позволяет пользователю определить любой набор счетчиков и выполнить сбор статистики по ним в процессе проведения эксперимента.
При поиске «узких мест» в аппаратной части web-сервера была использована та же методика, что и при оценке эффективности функционирования. На основании полученных результатов и проведения сравнительного анализа с эталонной таблицей пороговых значений был сделан вывод, что узким местом тестируемого web-сервера является недостаточный объем оперативной памяти. Для проверки правильности этого результата было выполнено увеличение объема памяти в два раза и проведено повторное тестирование. Оказалось, что увеличение памяти позволило увеличить общую производительность на 23%. Затем был выполнен возврат к данной конфигурации, и была произведена последовательная замена остальных аппаратных компонент. В результате проведения той же серии экспериментов было выявлено незначительное увеличение производительности, а на основании результатов, полученных с помощью методики локализации «узких мест», оперативная память была определена как «узкое место». Полученные результаты дают основание считать, что методика определения «узких мест» дает правильные результаты.
Наиболее простой вариант для анализа представляет собой web-сервер, работа которого относится к третьей группе, а именно части насыщения графика. Определить этот факт достаточно просто. Необходимо провести выборку значений из базы данных по временам обработки запросов и по кодам ответов. Наличие таких записей в базе данных скажет о том, какие дни в первую очередь необходимо проанализировать при создании модели нагрузки. Увеличение нагрузки в данном случае выполнять бессмысленно, ведь система и так не справляется с текущей нагрузкой. В некоторых случаях целесообразно уменьшить интенсивность нагрузки с целью уточнения того устройства, в работе которого раньше всех остальных устройств произошло превышение допустимого порогового значения. Полученная модель нагрузки может быть также использована при тестировании работы web-сервера после его модификации. В общем случае, в итоге улучшения, web-сервер перейдет или во вторую часть графика, или в первую.
Для серверов, относящихся ко второй группе и находящихся в части отклонения от линейности графика на рис.3.11, еще не достигнут уровень насыщения, а поэтому есть некоторый запас свободных ресурсов у системы. Все запросы, поступающие в систему, обрабатываются. Поэтому необходимо повторить эксперимент, проведенный в первом случае, и выяснить есть ли запросы, которые система не успевает обработать за отведенное время. Если да, то проанализировать полученные результаты и оценить степень загруженности каждого из устройств. Наиболее вероятен вариант, что загруженность ни одно из устройств не достигает критического уровня. В этом случае наиболее целесообразно заменить самое загруженное устройство. Если система работает в допустимых пределах, то тогда необходимо выполнить весь алгоритм тестирования, для того чтобы определить наибольшую допустимую нагрузку при заданном времени отклика. А именно: Сформировать модель нагрузки для данного web-сервера.
