Производительность программных систем

Производительность
программных систем
ДЗЮБА ДМИТРИЙ ВЛАДИМИРОВИЧ, СТАРШИЙ
ПРЕПОДАВАТЕЛЬ КАФ. 806
DDZUBA@YANDEX.RU

Производительность
2
Производительность в
значительной степени
представляет собой функцию,
зависящую от частоты
межкомпонентных связей и их
природы, в дополнение к
тактико-техническим данным
самих компонентов, и
следовательно, может быть
прогнозирована при изучении
архитектуры системы.

3
Производительность.

Время отклика (response time)
показатели производительности [1/9]
Промежуток времени, который требуется системе, чтобы обработать запрос извне.
Основные факторы влияющие на время отклика
◦ Потребление ресурсов
◦ Время блокировки (Blocked time)
◦ Конкуренция за ресурсы(Contention for resources)
◦ Доступность ресурсов(Availability of resources)
◦ Зависимости от других вычислений
4

Быстрота реагирования (responsiveness)
Скорость подтверждения запроса (Не путать с временем отклика— скоростью обработки !)
Эта характеристика во многих случаях весьма важна, поскольку интерактивная система, пусть даже обладающая
нормальным временем отклика, но не отличающаяся высокой быстротой реагирования, всегда вызывает
справедливые нарекания пользователей
Основные факторы влияющие на быстроту реагирования:
◦ Если, прежде чем принять очередной запрос, система должна полностью завершить обработку текущего,
параметры времени отклика и быстроты реагирования, по сути, совпадают
◦ Если же система способна подтвердить получение запроса раньше, ее быстрота реагирования выше
◦ Например, применение динамического индикатора состояния процесса копирования повышает быстроту
реагирования экранного интерфейса, хотя никак не сказывается на значении времени отклика.
5

Первый Закон Распределения Объектов гласит: "Не распределяйте
объекты!"
Время задержки
Минимальный интервал времени до получения какого-‐либо отклика (даже если от системы более ничего не
требуется)
◦ В телекоммуникации -‐ время, требуемое пакету для перемещения от источника к приёмнику, сообщению -‐ от
одной точки сети к другой.
◦ Параметр приобретает особую важность в распределенных системах
Снизить время задержки разработчику прикладной программы не под силу
Фактор задержки — главная причина, побуждающая минимизировать количество удаленных вызовов
6

Пропускная способность
Количество данных (операций), передаваемых выполняемых) в единицу времени
Скорость обработки недостаточна, должен быть указан один или более интервалов наблюдения.
Пример: 120 сообщений в час, не гарантирует 2 сообщения в минуту.
В корпоративных приложениях обычной мерой производительности служит число транзакций в
секунду (transactions per second — tps)
◦ Транзакции различаются по степени сложности
◦ Для конкретной системы необходимо рассматривать смесь "типовых" транзакций
7

Рабочая нагрузка (Work load)
Значение, определяющее степень "давления" на систему
◦ Общее количество пользователей
◦ Количество одновременно активных пользователей
◦ Объемы данных
◦ Количество транзакций
Примеры:
◦ 100 пользователей работают одновременно в системе.
◦ 10 пользователей размещают заказы одновременно.
Параметр загрузки обычно служит контекстом для представления других функциональных характеристик. Так,
нередко можно слышать выражения наподобие следующего:
«время отклика на запрос составляет 0,5 секунды для 10 пользователей и 2 секунды для 20
пользователей»
8

Чувствительность к загрузке (load
sensitivity)
Выражение, задающее зависимость времени отклика от загрузки
Пример:
◦ Система А обладает временем отклика, равным 0,5 секунды для 10-‐20 пользователей
◦ Система В обладает временем отклика в 0,2 секунды для 10 пользователей и 2 секунды для 20
пользователей
◦ Это дает основание утверждать, что система А обладает меньшей чувствительностью к загрузке
9

Эффективность (efficiency)
Удельная производительность в
пересчете на одну единицу ресурса
Например, система с двумя
процессорами, способная выполнить 30
tps, более эффективна по сравнению с
системой, оснащенной четырьмя
аналогичными процессорами и
обладающей продуктивностью в 40 tps
10

Мощность (Capacity)
Наибольшее значение пропускной способности или загрузки
Это может быть как абсолютный максимум, так и некоторое число, при котором величина
производительности все еще превосходит заданный приемлемый порог.
11

Способность к масштабированию
(scalability)
Свойство, характеризующее поведение системы при добавлении ресурсов (обычно
аппаратных)
Масштабируемой принято считать систему, производительность которой возрастает
пропорционально объему приобщенных ресурсов (скажем, вдвое при удвоении
количества серверов)
◦ Вертикальное масштабирование (vertical scalability, scaling up) Увеличение мощности
отдельного сервера (например, за счет увеличения объема оперативной памяти)
◦ Горизонтальное масштабирование (horizontal scalability, scaling out) Наращивание
потенциала системы путем добавления новых серверов
12

Тактики управления
производительностью

Тактики: Управление потреблением
ресурсов [1/3]
Уменьшение запросов к ресурсам входе вычислений
◦ Увеличить эффективность вычислений (основной подход)
Пример: от сортировки пузырьком к сортировке Хоара
◦ Уменьшить накладные расходы при вычислениях
Уменьшаем число обращений к «медленным ресурсам».
14

Различные алгоритмы сортировок

16
Уменьшение числа обрабатываемых событий
◦ Управлению частотой событий. Если возможно уменьшить число точек обращения к
разделяемым ресурсам из параллельных потоков, то общая производительность может быть
увеличена.
Пример: при изменении данных можно сначала получать данные, а потом
перезаписывать новое значение. А можно изменять данные на дельту (без блокировки
ресурса).
◦ Управление скоростью генерации событий. В случае, если события генерируются
бесконтрольно, то система может не успеть обработать все. В данной тактике применяется
уменьшение числа генерируемых событий (на генерирующей стороне).
например, использование MOM взаимодействия позволяет контролировать скорость
обработки событий

Пример – уменьшаем число запросов
к медленным ресурсам
см. Cache
Client
Slow
Обработчик
Fast

18
Верхняя граница загруженности ресурса (лишние запросы не
выполняются, но остальные выполняются с требуемой скоростью)
◦ Ограничение время выполнения. Иногда имеет смысл установить
ограничение на время обработки запроса.
◦ Ограничение размера очереди. Заранее определяются
максимальные размеры очереди и число ресурсов требуемых для
обработки очереди..

19
Тактики: Управление ресурсом
1. Распараллеливание обработки.
Если запрос может идти параллельно, то общее потраченное время обработки может быть
уменьшено.
1. Минимизация количества разделяемых ресурсов.
Кэширование дает возможность уменьшить время на запрос/генерацию данных но приносит
проблемы с актуализацией кэша (хорошо для редко меняющихся данных).
2. Увеличение доступности ресурса. Более быстрые процессоры, дополнительные процессоры,
больше памяти, более быстрая сеть ....

Пример: LoadBalance
см. QueueExample
Client
Task

Пример:
Минимизация количества разделяемых ресурсов.
см. QueueShare
Client
Task
Resource
Resource
Resource
Вариант 1 Вариант 2

Тактики: Арбитраж ресурса [1/3]
Очередь.
Очередь подразумевает что все ресурсы
равноправные. По этому то что первый пришедший
запрос обрабатывается первым -‐ это нормально.
Позволяет ограничивать нагрузку на процессоры.
Позволяет балансировать нагрузку между
процессорами.
Может использоваться как одна очередь с
несколькими читателями, так и несколько очередей
(для каждого читателя своя).
22

Арбитраж ресурса [2/3]
работа с очередями
Фиксированный приоритет. Для всех источников событий устанавливается приоритет. Вначале должны быть
обработаны самые приоритетные. Однако не стоит забывать, что менее приоритетные тогда могут быть
забыты. Следующие стратегии управления приоритетами:
◦ Семантическая важность. Каждому потоку устанавливается приоритет в зависимости от семантической
важности задачи.
◦ Контролирование срока запроса. Больший приоритет устанавливается потоку с запросами у которых
deadline наступает раньше (на уровне типа запроса).
◦ По скорости обработки(основываясь на семантике). Запросу которые выполняются быстрее получают
больший приоритет. Таким образом число запросов уменьшается быстрее.
Обычно, что бы избежать ситуации когда не-‐приоритетные задачи совсем не обрабатываются делают систему
квантования. Например, 8 раз из 10 пытаемся обработать первые высокоприоритетные сообщения, а 2 раза –
остальные. «Пытаемся» означает, что если нет сообщений нужного типа то берем первые по очередности.
23

Арбитраж ресурса [3/3]
работа с очередями
Динамический приоритет
◦ Round robin.
Пусть имеется N объектов, способных выполнить заданное действие, и M задач, которые должны быть
выполнены этими объектами. Подразумевается, что объекты n равны по своим свойствам между собой,
задачи m имеют равный приоритет. Тогда первая задача (m = 1) назначается для выполнения первому
объекту (n = 1), вторая — второму и т. д., до достижения последнего объекта (m = N). Тогда следующая
задача (m = N+1) будет назначена снова первому объекту и т. п. Проще говоря, происходит перебор
выполняющих задания объектов по циклу, или по кругу (round), и по достижении последнего объекта
следующая задача будет также назначена первому объекту.
◦ Более ранний deadline. Из запроса считывается deadline и тому запросу у которого он раньше назначается
наивысший приоритет.
Статическое расписание.
В данной стратегии алгоритм выдачи приоритетов определяется offline базируясь на природе событий.
24

Паттерны
Паттерн - это описание успешного
инженерного решения
Паттерн предназначен для повторного
использования ранее найденных решений
Именование паттернов позволяет упростить
коммуникации в процессе принятия
проектных решений
Паттерн не должен быть использован
механически. Применение паттерна
зачастую – компромисс
25

Load Balancer
построение web-‐приложений
26
http://horicky.blogspot.ru/2010/10/scalable-system-design-patterns.html

Scatter and Gather
Применяется в поисковых машинах yahoo,
google …
27

Result Cache
в enterprise приложениях
28

Shared Space
javaspace, gigaspace
29

Pipe and Filter
enterprise приложения
30

Bulk Synchronous Parellel
Google's Pregel graph processing model
Apache Hama project.
32

Execution OrchestratorMicrosoft's Dryad project
33

Антипатерны
Имя
Класс ―бог (―god class)
Симптомы
◦ Единственный сложный контроллер
◦ Использует простые классы – контейнеры данных
◦ В свою очередь, классы контейнеры
◦ Содержат только методы доступа и модификаторы
(get, set)
◦ Не поддерживают поведения (или поддерживают
слабо)
Проблема
◦ Класс «Бог» становится причиной интенсивного
трафика сообщений
◦ В форме контроллера запрашивает и обновляет
данные у подконтрольных классов
◦ В форме контейнера данных – запрашивает и
обновляет данные в божественном классе
◦ Количество вызовов для выполнения операции
много больше чем при хорошем дизайне
Решение
◦ С помощью рефакторинга распределите поведение
по всем top-‐level классам приложения
◦ Переместите поведение ближе к данным
◦ Избегайте ситуаций, когда
◦ Объект запрашивает данные у других объектов и
затем обновляет их самостоятельно
◦ Группа объектов запрашивает и обновляет данные
одного общего объекта
◦ Используйте Принцип Локальности
◦ Алгоритм и данные необходимые для его
выполнения должны располагаться вместе
34

Имя
Чрезмерное динамическое выделение ресурсов
(excessive dynamic allocation)
Симптомы
◦ Динамическим выделением объекта называется
ситуация, когда объект
◦ Создается при первом вызове
◦ Уничтожается при отсутствии потребности
Проблема
◦ При создании объекта
◦ должна быть выделена память для его
размещения (и для объектов, которые он
содержит)
◦ должен быть выполнен код инициализации
объекта (и объектов, которые он содержит)
◦ Когда объект больше не нужен
◦ выполняются операции завершения
◦ выполняются операции дефрагментации памяти
◦ Влияние на производительность может быть
значительным при больших количество объектов,
которые часто создаются и затем уничтожаются
Решение
◦ Используйте пул (―pool) объектов, коллекцию
объектов, который
◦ Позволяет повторно использовать объекты вместо
того, чтобы создавать их вновь при каждой
необходимости
◦ Бывает очень полезен при наличии в системе
множества короткоживущих объектов
◦ Используйте разделенные (sharing) объекты вместо
того, чтобы создавать новые
35

Имя
Поэтапный поиск сокровищ (circuitous treasure hunt)
Симптомы
◦ Система запрашивает данные в одной таблице,
затем на основании этих данных осуществляет
запрос к другой таблице и далее в том же духе до
получения финального результата
Проблема
◦ В объектно-‐ориентированных системах операции
включают множество запросов
◦ Объект вызывает операции другого, тот в свою
очередь третьего, и так далее до получения
финального результата
◦ Каждая операция возвращает значения по
цепочке объекту, который был инициатором
вызовов
◦ Возникает существенное снижение
производительности. Особенно в распределенных
системах
Решение
◦ Измените структуру организации данных
◦ Разместите вместе совместно используемые данные
◦ Для решения проблемы множества вызовов
создавайте новые связи-‐ассоциации, которые ведут
непосредственно к финальному результату
36

Имя
Мост с односторонним движением (the one lane bridge)
Симптомы
◦ это решение, при котором
◦ передача возможно только в одну сторону в
каждый конкретный момент времени
◦ если передача ведется параллельно по
нескольким полосам, все потоки должны сойтись в
одной точке
Проблема
◦ Только один или небольшое количество процессов
могут работать одновременно
◦ все остальные процессы находятся в состоянии
ожидания
◦ Пример:
◦ Блокировка база данных позволяет только одному
процессу обновлять определенные данные в
конкретный момент времени
◦ Много процессов осуществляют синхронный
вызов другого не многопоточного процесса
◦ Первичный ключ в базе данных строится на
основании последовательности
Решение
◦ Обеспечивайте дополнительные маршруты в обход
однопоточного моста
◦ Решение базируется на Принципе распределения
ресурсов
◦ Реактивность увеличивается при снижении
времени обслуживания и времени ожидания
◦ Время ожидания в свою очередь уменьшается за
счет времени обслуживания и нахождения
обходных маршрутов
37

Имя
Пробка (traffic jam)
Симптомы
◦ Большая очередь работ ожидающих обслуживания
◦ Мост с односторонним движением приводит к
большим задержкам, после которых требуется
много времени для восстановления нормального
режима работы
◦ Большое количество работы запланировано на
сравнительно небольшой интервал времени
◦ Все пользователь нуждаются в отчетах в одно и то
же время
◦ На рынке происходит всплеск активностей
Проблема
Проблема в больших вариации времени отклика
Решение
◦ Если проблема вызвана Мостом с односторонним
движением, решите проблему с Мостом
◦ Если проблема связанна с периодически
возрастающими запросами, решайте проблему
распределением нагрузки или регулируйте поток
запросов
38

Имя
Несбалансированная обработка (unbalanced processing)
Симптомы
◦ Параллельная обработка должна приводить к
улучшению маштабируемости, однако этого не
происходит, если все параллельные потоки
вынуждены ожидать завершение другого процесса
Проблема
◦ Системы Параллельной обработки при наличии
множества процессоров не можем использовать
параллельную обработку, к примеру, потому что
используется single-‐threaded код
◦ Архитектура ―Pipe and Filter Пропускная
способность определена самым медленным
фильтром
◦ Интенсивная обработка Параллельные вычисления
не могут быть использованы эффективно, потому что
процессор загружен интенсивными вычислениями
Решение
◦ Конкурентная обработка
◦ Если мы имеем дело с single-‐threading процессом,
то мы можем либо переписать его с
использованием multi-‐threaded или использовать
множество копий
◦ Если процессор занят интенсивными
вычислениями, требуется тюнинг системы. В
частности перераспределение нагрузки между
процессорами
◦ Архитектура ―Pipe and Filter
◦ Моделируйте ситуацию для выявления узких мест
◦ При необходимости разбивайте большие
процессы на множество мелких (который
возможно распараллелить)
◦ При необходимости объединяйте процессы в один
большой (экономия за счет использования общего
контекста)
39

Имя
Ненужная обработка (unnecessary processing)
Симптомы
◦ Как и любая другая бесполезная работа работа по
этому шаблону отнимает время у важной задачи
Проблема
◦ Ненужная обработка может быть вообще
бессмысленной или ненужной в это время
◦ Например, система логирует исходящие и входящие
сообщения. Одна группа логов лишняя, так как
может быть восстановлена по второй
Решение
◦ Зачастую решение проблемы сводится к устранению
ненужного кода
◦ Возможна реорганизация шагов обработки,
позволяющая исключить из обработки неактуальные
устаревшие данные
◦ Третье решение -‐ перенос ненужных обработок в
фоновый процесс
40

Имя
Наклонная (the ramp)
Симптомы
◦ Системы показывают замечательную
производительность при старте, но с каждой
минутой их производительность падает
Проблема
◦ Причин возникновения такой ситуации может быть
множество
◦ В частности, в процессе работы накапливаются
данные, участвующие в принятии дальнейших
решений
◦ В процессе поиска выбираем значения группами
(например по 10), каждый новый поиск дает все те
же результаты и отсеивает ненужные
Решение
◦ Выбирайте алгоритмы поиска, пригодные как для
больших так и для малых объемов данных,
исключающие дополнительную работу по поиску в
найденном
◦ Возможно, стоит использовать
самонастраивающуюся (по размеру) стратегию
поиска
◦ Если данные увеличиваются постепенно,
необходимо иметь систему мониторинга,
переключающую стратегию работы при достижении
определенной контрольной точки
41

Имя
Дальше хуже (more is less)
Симптомы
◦ Чем больше мы производим работы, тем дальше от
конечного результата
Проблема
◦ Наиболее частая причина – нехватка памяти.
Множество задач интенсивно используют память,
мешая друг другу
◦ Слишком много соединений с базой данных
◦ Слишком много сетевых соединений
◦ Слишком много ресурсов взято из пулла
Решение
◦ Переход от многопотоковой системы к
однопотоковому варианту
◦ Поток поддерживает очередь Команд [Gof] с
предустановленными приоритетами
◦ Пересмотреть балансы системы или подсистем
◦ Например, снизить требование по количеству
одновременных соединений с базой данных с 200 до
100
42

Имя
Эффект домино (falling dominoes)
Симптомы
◦ Одна проблема тянет за собою другую, та – следующую и так далее
Проблема
◦ Падение одного узла приводит к увеличению нагрузки на другие, что приводит к их падению
◦ Увеличение времени отклика приводи к череде повторных запросов
Решение
◦ Изолируйте сбойный элемент
◦ Если нет доступа к базе данных, отключите сервис, исключив ―DOS‖ атаку повторных обращений
43

Имя
Порожняк (empty semi trucks)
Симптомы
◦ Сервис работает над выполнением простейших запросов
Проблема
◦ Для выполнения задачи требуется огромное количество запросов. Каждый из запросов довольно
мизерный
◦ Проблема возникает
◦ из-‐за неэффективного использования коммуникаций
◦ из-‐за плохо спроектированного интерфейса
Решение
◦ Если проблема в неэффективном использовании логического канала связи, используйте пакетирование
◦ Если проблема в плохо спроектированном интерфейсе, перепроектируйте его, с целью расположения
данных ближе к алгоритму обработки
44

Имя
Вавилонская башня (tower of Babel)
Симптомы
◦ Процессы в параллельной обработке имеют различный формат представления информации
Проблема
◦ Часть системы работает с одним форматом передачи данных, часть с другим. Накладные расходы
возникают при переводе из одного формата в другой
Решение
◦ Если проблема возникает на быстром пути обработки (Fast Path), можно перепроектировать
модули с целью расположения данных ближе к алгоритму обработки
45

Производительность программных систем

More Related Content

Viewers also liked (20)

Similar to Производительность программных систем (20)

More from Dima Dzuba (10)

Производительность программных систем