Прогноз выполнения приложения

Поволжский Государственный Университет Телекоммуникаций и
Информатики
Отчет по лабораторной работе №7
По дисциплине: Проектирование и Моделирование Сетей ЭВМ
На тему: ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ
ПРИЛОЖЕНИЙ ORACLE
Выполнил: студент группы ИТ-72
Айбятов Д.Т.
Проверил: Тарасов В.Н.
Самара, 2011
Цель работы: Цель лабораторной работы - решение
задачи
анализа
производительности
двухуровневого
(клиент/сервер)
приложения
Oracle.
Также
будут
исследованы возможные узкие места, которые могут
привести к большому времени отклика.
Приложение
выполняется
следующим
образом:
клиенты получают доступ к Oracle Server в Центре данных
через сеть Metropolitan Area Network (MAN) с широкой
полосой пропускания и малым временем задержки. Время
отклика клиентского приложения равно 12 секундам.
При
решении
проблемы
производительности
приложения при помощи АСЕ важно выбрать правильный
метод перехвата трафика. Модуль АСЕ сконструирован
таким образом, чтобы можно было анализировать
единственную транзакцию приложения. В лабораторной
работе
будут
использоваться
реальные
данные:
трассировочный
файл,
который
содержит
трафик
приложения (из сниффера). Необходимо отфильтровать
остальные пакеты, потому что АСЕ считает их частью
субъекта приложения. В идеальном случае зада ча состоит в
том,
что
необходимо
захватить
трассу,
которая
представляет собой только одну транзакцию. А в реальном
случае, нужно будет фильтровать посторонние сообщения.
Сообщения в принципе можно отфильтровать в три
момента времени:
- при захвате трассирующего файла из сети;
- во время поступления данных;
- внутри редакторов АСЕ, как показано в данной
лабораторной работе.
В этой работе захваты трасс происходят одновременно для
клиента и для сервера. Эти захваты затем соединяются,
чтобы получить наилучший показатель задержек на
каждом отдельном компьютере и сети в целом
(Предыдущие
лабораторные
работы
были
сосредоточены на сетях и Интернете (от физического - 1 до
транспортного - 4 уровней OSI). Однако для пользователей
не меньший интерес представляет прикладной уровень -7.
Лабораторная
работа
использует
модуль
OPNET`s
Application Characterization Environment (ACE), для
обнаружения и устранения неполадок и оценки времени
отклика для конкретного приложения Oracle.
Модуль АСЕ осуществляет визуализацию и оценку
характеристик, что помогает при анализе приложения.
Менеджеры сетей и разработчики приложений могут
использовать АСЕ для того, чтобы:
- устранить узкие места в сети и приложении;
- диагностировать проблемы приложения;
- исследовать
предложенные
установки
для
существующих приложений;
- прогнозировать
выполнение
приложения
при
различных конфигурациях и условиях работы сети. )
Выполнение работы:
1)
Визуализация приложения
После получения «окна выбора проекта» появляется «карта
обмена данных». Используя эту карту, н еобходимо
проанализировать приложение в деталях
Карта обмена данных
Эта карта показывает данные, перемещаемые между
уровнями приложений Oracle по оси времени. Цвета
сообщений приложения представляют размер сообщения.
Каждая цветовая группа представляет гистограмму
распределения размеров сообщений.
1. Порядок уровней может быть изменен, чтобы
облегчить интерпретацию карты путем перемещения имени
уровня вверх или вниз. В этом случае нужно сохранять
уровни в прежнем порядке – уровень Oracle_Client
наверху, а уровень Oracle_Server внизу.
2. В каждой группе около одной трети сообщений
являются желтыми (101 – 500 байт на сообщение) и около
двух третей – оранжевыми (1 – 100 байт на сообщение).
Это говорит о том, что приложение посылает много
маленьких сообщений.
3. Необходимо разделить сообщения, следующие в
разных направлениях и выбрать пункт View > Split Groups.
4. Теперь сообщения разделены на две группы, и
можно обнаружить больше деталей. Можно увидеть, что:
- верхняя группа представляет сообщения от клиента к
серверу, а правая – от сервера к клиенту;
- в группе сообщений клиент-сервер около половины
сообщений являются оранжевыми;
- в группе сообщений сервер-клиент около двух третей
сообщений являются оранжевыми.
5. Следует посмотреть контекстное окно указателя,
поместив мышь над первой группой сообщений. Это окно
показывает, что первая группа сообщений представляет 183
сообщения в каждом направлении.
Карта обмена данных после разделения сообщений
Анализ задержек при помощи модуля AppDoctor
Модуль AppDoctor`s Summary of Delays позволяет
понять причину задержки протокола приложения. Он
разделяет общее время отклика приложения на четыре
компоненты.
1. Задержка обработки уровня – это общее время,
которое затрачивается на обработку приложения на каждом
уровне, включая время на раздумье пользователя.
2. Задержка из-за времени запаздывания – это
компонента задержки, связанная со временем запаздывания
в сети.
3. Задержка из-за полосы пропускания – это компонента
задержки,
обусловленная
ограниченностью
полосы
пропускания сети.
4. Задержка «протокол/перегрузка» - это метрика
ограничения
сети
для
прохождения
пакета.
Это
ограничение может быть вызвано очередью пакетов в сети
или механизмами текущего контроля, установленными
сетевыми протоколами.
Для
анализа
задержек
протокола
приложений
необходимо выполнить последовательность действий.
1. Выбрать AppDoctor > Summary of Delays .
2. Поместить курсор на красную часть карты, чтобы
увидеть контекстное окно указателя \
Вывод. Наиболее значимым фактором, влияющим на время
отклика, является воспроизведение задержки. Для этой
транзакции оно является причиной почти 60% времен
отклика продолжительностью в 12 секунд
Обзор функции AppDoctor`s Diagnosis
Эта функция проверяет текущую транзакцию по
сравнению с исходами, которые часто вызывают проб лемы
выполнения сетевых приложений, сгруппированных по
категориям.
Для того, чтобы отобразить данную функцию на экране,
необходимо выбрать функцию AppDoctor > Diagnosis из
меню.
Окно функции AppDoctor`s Diagnosis
Нужно исследовать четыре узких места: Protocol
Overhead, Chattiness, Network Effect of Chattiness и
Effect of Latency.
Нажать на пункт Bottleneck, чтобы увидеть описание
diagnosis на нижней панели для каждого узкого места.
Закрыть окно AppDoctor Diagnosis.
Для того, чтобы нельзя было увидеть разделенные
группы на Data Exchange Chart, нужно выбрать пункт
View > Split Groups.
Моделирование обмена данными
Модуль AppDoctor`s Summary of Delays and Diagnosis
обнаруживает исходы как для сети, так и для обмена
данными между уровнями. Карта обмена данными может
провести дополнительные исследования. Следует изучить
начало транзакции (т.е. между 6.1 и 6.3 секундами
трафика) более внимательно.
Для изменения масштаба к пространству карты, которое
представляет период времени 6.1 – 6.3 секунды, нужно
выполнить следующие действия:
- щелкнуть правой кнопкой мыши по рабочему
пространству карты обмена данных;
- выбрать пункт Zoom to Rectangle из меню и
протащить курсор, чтобы образовать «коробку» вокруг
пространства цели.
Если изначальное изменение масштаба не подходит,
можно выбрать пункт Previous Zoom из меню и попытаться
повторить все действия вновь.
Замечание. После того, как настроен масштабный
уровень, можно использовать клавиши со стрелками для
перемещения во всех направлениях.
Как только будет введен масштаб в карту обмена данными,
группы сообщений превращаются в индивидуальные
сообщения приложения
Карта обмена данными с индивидуальными сообщениями
приложения
Теперь надо изучить индивидуальные приложен ия.
Стрелка указывает, в каком направлении поступает
сообщение, а само
приложение составлено из многих
маленьких сообщений ( они указаны оранжевым и желтым
цветами). Здесь каждое изменение направления называется
поворотом
приложения
–
приложение
изменяет
направление потока данных. Приложения с большим
количеством поворотов называются избыточными и
являются
чувствительными
к
задержкам
сети.
Чувствительность возникает, потому что каждое сообщение
должно быть принято на своем уровне до того, как
посылается соответствующее ответное сообщение. Таким
образом, время задержки сети влияет на каждое сообщение.
Можно заключить, что визуализация карты обмена
данными подтверждает анализ, предсказанный модулем
Summary of Delays and Diagnosis: приложение избыточно,
и избыточность означает, что задержка в сети значительно
замедляет приложение.
Модуль AppDoctor осуществляет также вычисление
суммарных статистик для транзакции приложения. Можно
просмотреть статистики для этого приложения.
Просмотр суммарных статистик
Две наиболее важные статистики – количество
поворотов приложения и максимальное число обмененных
данных при единственном повороте выбирают из меню
AppDoctor > Statistics.
Нетрудно заметить, что приложение имеет 2.157
поворотов приложения (циклов запрос/ответ), чт обы
обменять 182.056 байт данных.
Также максимальное количество данных, посланных в
одном повороте – 258 байт в одном направлении (А  B) и
455 байт в другом (AB). Избыточность является
превалирующей в базах данных и часто является основной
причиной плохого времени отклика.
Статистики AppDoctor
Здесь одна воспроизведенная задержка, усугубленная
2.157 поворотами, насчитывает около 6.97 секунд общего
времени отклика транзакции. Так время задержки сети
является
в
основном
результатом
географического
расстояния и скачков в сети, добавление полосы
пропускания привнесет минимальный эффект на время
отклика. Чтобы минимизировать эту компоненту, нужно
либо уменьшить время задержки в цепи, либо уменьшить
число поворотов приложения. Время задержки в цепи
является физически установленным, поэтому более
практичным является изменение поведения приложения.
Далее нужно закрыть окно AppDoctor Statistic
Прогноз выполнения приложения
Функция
AppDoctor`s
Quick
Predict
является
аналитико
имитационным
механизмом,
который
предоставляет возможность быстрой проверки выполнения
приложения при различных сетевых условиях. С помощью
Quick Predict можно проверить возможные расширения
сети, чтобы оценить то влияние, которое они могут
оказывать
на
выполнение
приложения.
Если
это
приложение установлено на ГВС, то можно посмотреть, как
задержка в сети повлияет на выполнение приложения. Для
этого нужно выполнить последовательность действий.
1. Выбрать из меню AppDoctor > Quick Predict.
2. Выбрать пункт Latency для X Axis и установить
значения Min Latency на 0ms и Max Latency на 20ms
3. Нажать на кнопку Update Graph.
Этот график показывает, что задержка прямо
пропорциональна полосе пропускания. То есть, если
приложение установлено на ГВС, то очень важно
переписать его, чтобы получить лучш ее время отклика.
Вывод:
1. Эта лабораторная работа показывает, как может быть
использован
модуль
АСЕ
для
визуализации
и
диагностирования проблем при оценке производительности
приложения. Изначально было известно только, что
приложение имеет время отклика в 12 секунд. Затем после
моделирования стало известно, что медленный отклик был
вызван
избыточностью
приложения,
усугубленной
запаздыванием в сети. Хотя запаздывание между клиентом
и сервером было только 3.2 мс, в результате многих
поворотов приложения оно стало очень значительным.
Анализ реального трафика приложения из снифера
позволил установить, что приложение отправляет много
маленьких пакетов от 1 до 100 байт (60%) и от 101 -500
байт(30%).
В этом случае лучшее решение – это переписать
приложение, чтобы передавать меньше, но «больших»
сообщений. Используя полученные графики, статистики и
декодирование протоколов, производимые АСЕ, вы должны
быть в состоянии убедить разработчиков баз данных
изменить их транзакцию, как это требуется.
2. Лабораторная работа раскрывает процедуру анализа
производительности клиент-серверного приложения Oracle.
Исследована методика поиска критических блоков и
решений,
влияющих
на
параметры
качества
и
производительности. Исследования проводятся по данным
реального перехвата трафика, что позволяет моделировать
реальные приложения. Все аспекты производительности
(количество пакетов, средний размер и интенсивность
трафика) учитываются при верификации модели. Также
представляется возможным оценить влияние расширения
(преобразования) сети на приложение. Моделирование
позволило определить причины неудовлетворительной
работы приложения в некоторых режимах и позволило
предложить методы улучшения качества работы.
После анализа конкретной единичной транзакции было
выявлено, что в ней приложение создает 2157 циклов
запрос/ответ, при этом поток данных составляет 180 кбайт.
Из-за большого количества запросов возникает задержка
почти
в
7
секунд.
Подобное
происходит
из -за
суммирования всех задержек на пути следования пакета.
Уменьшить
общую
задержку
можно
уменьшением
количества запросов/ответов либо модернизацией линий
связи. Так как уменьшение задержек в линии связи не
всегда возможно, и часто связано с увеличением
пропускной способности, соответственно с ощутимыми
финансовыми издержками, остается только модернизация
приложения.