Предисловие
В своей работе я столкнулся с необходимостью найти зависимость
объемов ресурсов требуемых для системы (например CPU Mhz) от нагрузки на
нее. Попробовав поискать информацию по этой проблеме в Сети, ничего
толкового на русском я не нашел. Но несколько статей на эту тематику
удалось таки обнаружить на небезызвестном MSDN (Microsoft Developer
Network) http://msdn.microsoft.com/. Пришлось некоторое время потратить
на анализ и объединение этих материалов, в результате чего и получилась
эта статья. В ней описывается конкретный опыт по решению задачи
планирования конфигурации системы. Специфика работы ориентирована прежде
всего на интернет системы: WEB сайты, WEB сервисы и прочие системы где
нагрузка создается по HTTP протоколу методами POST и GET. Однако я
думаю, что ни что не мешает адаптировать методику под любые программные
системы.
Описание задачи
Требуется найти зависимость объема ресурсов от нагрузки, для
конкретной программной системы.
Решение
Эту задачу можно разбить на подзадачи:
- Описание текущей конфигурации системы.
- Анализ предметной области и выявление требований к системе.
- Планирование размера ресурсов.
Текущая конфигурация системы
WEB Server
Processor |
x86 Family 6 Model 6 Stepping 0 GenuineIntel
~367 Mhz |
Total Physical Memory |
267,812 KB |
Available Physical Memory |
114,120 KB |
Желательно проводить тестирование на наиболее мощном из ваших
компьютеров.
OS Name |
Microsoft Windows 2000 Advanced Server |
Version |
5.0.2195 Service Pack 2 Build 2195 |
Требования
Основное требование для интернет системы - время ответа WEB сервера
на запрос пользователя. Время ответа складывается из времени выполнения
запроса на сервере, времени ожидания выполнения запроса и времени
передачи ответа по сети. Так как в нашем случае все тестирование
проводится в рамках интранет сети и объем выдаваемой WEB сервером
информации невелик, то временя передачи ответа по сети можно опустить.
Время ответа должно быть меньше или равно 5 секундам.
Кроме требований по предметной области существуют и технические
требования которые должны соблюдаться в процессе тестирования. Основным
техническим требованием является использование процессора не более чем
на 90%. Более подробно с техническими требованиями можно ознакомиться
здесь -
http://msdn.microsoft.com/library/en-us/dnduwon/html/d5collection.asp?frame=true
Планирование размера ресурсов
Задачу по планированию конфигурации для программных систем возможно
решать двумя основными путями. Первый - традиционный подход
(Conventional Approach), подразумевает использование нескольких
конфигураций для тестирования с последующим сравнением полученных на
каждой результатов тестов и выбора оптимальной конфигурации.
Другой метод планирования конфигурации - метод анализа стоимости
транзакции в системе (Transaction Cost Analysis), его задача определить
стоимость в ресурсах для каждой операции производимой в системе
пользователем.
Традиционный подход
Состоит из двух видов тестов:
Stress test - задача теста определить максимальную нагрузку на
систему при данной конфигурации и измерить используемые при этом ресурсы
системы: пропускную способность , загруженность процессора и т.п. Тест
проводится в несколько итераций с постепенным повышением нагрузки
например 1000 пользователей, 2000 пользователей, 3000 пользователей.
После каждой итерации проверяются показатели работы системы, если
показатели превышают указанные допустимые пределы (например CPU
Utilization> 90%) то нагрузка вызвавшая это считается критической для
данной конфигурации и дальнейшие итерации прекращаются.
Scalability test - задача теста подобрать необходимую
конфигурацию для системы. Тест состоит из нескольких итераций Stress
tests на разных конфигурациях. Если при критической нагрузке на
данной конфигурации не выполняются требования к некоторым параметрам
работы системы, то конфигурация считается неприемлимой и подбирается
новая, в которой наиболее деффицитный ресурс наращивается.
Анализ стоимости транзакций
Для решения задачи определения и прогнозирования конфигурации
наиболее оптимальным методом, на мой взгляд, является анализ стоимости
транзакции в системе (Transaction Cost Analysis). Этот метод подробно
описан в статьях:
http://www.microsoft.com/siteserver/ssrk/docs/rk_TCA.doc и
http://msdn.microsoft.com/library/en-us/dnmscms01/html/cmsperfoc.asp?frame=true
.
Задача метода определить сколько ресурсов будет стоить выполнение каждой
транзакции в системе. И на основе полученной информации спрогнозировать
зависимость необходимых ресурсов от нагрузки. Воспользуемся эим методом
для решения поставленной задачи.
План выполнения анализа
- Определить время работы в системе одного пользователя(время
сессии).
- Определить транзакции, которые выполняет пользователь в системе.
- Определить загрузку системы для каждой транзакции (стоимость
транзакции).
- Определить профили использования системы.
- Определить стоимость ресурсов для одного пользователя в системе.
- Определить количество пользователей в сутки.
- Определить максимальное количество одновременных пользователей.
- Прогнозирование необходимого количества ресурсов для указанного
количества пользователей.
Определение транзакций, которые выполняет пользователь в системе
Список этих транзакций определяется исходя из функциональности
системы. Операциями могут являться : поиск, запрос определенной страницы
на сайте и пр.
Таблица 1
Transaction |
Операция 1 |
Операция 2 |
Операция 3 |
Операция 4 |
Операция 5 |
Операция 6 |
Операция 7 |
Операция 8 |
Операция 9 |
Операция 10 |
Операция 11 |
Операция 12 |
Операция 13 |
Операция 14 |
Операция 15 |
Операция 16 |
Операция 17 |
Операция 18 |
Операция 19 |
Операция 20 |
Login |
Определение времени работы в системе одного пользователя(время
сессии).
Этот параметр определяется при анализе лог файлов системы. Так же
параметр можно определить, анализируя бизнес логику системы. Допустим,
что время сессии одного пользователя равно 20 мин.
t=20 min=1200 sec.
Определение загрузки системы для каждой транзакции (стоимость
транзакции).
На этом этапе для каждой транзакции необходимо определить стоимость в
ресурсах.
Для этого каждая транзакция из таблицы 2 выполняется в системе
отдельно какоето время, не менее 3 минут. Во время ее выполнения
фиксируются показатели системных датчиков:
Processor(_Total)\% Processor Time
Active Server Pages\Request Wait Time
Active Server Pages\Request Execution Time
Active Server Pages\ASP Requests Queued
Active Server Pages\ASP Requests/Sec
System\Processor Queue Length
Response time = Active Server Pages\Request Execution Time +
Active Server Pages\Request Wait Time
После чего анализируются средние показатели датчиков. Если они в
пределах установленных в требованиях ограничейний, то нагрузка
увеличивается и проводится еще один тест. Если ограничения превышены то
средние показания датчиков записываются таблицу 2
Таблица 2
|
Request Execution Time |
Request Waite Time |
ASP Requests/Sec |
Processor utilization% |
Response time |
Операция 1 |
4655 |
355 |
3 |
61 |
5000 |
Операция 2 |
1062 |
0 |
14 |
93 |
1062 |
Операция 3 |
43 |
5 |
20 |
94 |
48 |
Операция 4 |
54 |
3 |
17 |
94 |
57 |
Операция 5 |
49 |
2 |
20 |
94 |
51 |
Операция 6 |
33 |
9 |
23 |
92 |
42 |
Операция 7 |
51 |
1 |
18 |
90 |
52 |
Операция 8 |
46 |
2 |
20 |
90 |
48 |
Операция 9 |
80 |
4 |
11 |
94 |
84 |
Операция 10 |
70 |
5 |
12 |
92 |
75 |
Операция 11 |
80 |
5 |
11 |
90 |
85 |
Операция 12 |
82 |
2 |
17 |
88 |
82 |
Операция 13 |
156 |
3 |
6 |
88 |
159 |
Операция 14 |
52 |
2 |
17 |
93 |
54 |
Операция 15 |
56 |
1 |
16 |
85 |
57 |
Операция 16 |
303 |
3 |
7 |
88 |
306 |
Операция 17 |
192 |
25 |
9 |
83 |
217 |
Операция 18 |
192 |
25 |
9 |
83 |
217 |
Операция 19 |
3700 |
30 |
2 |
94 |
3730 |
Операция 20 |
2800 |
200 |
2 |
80 |
3000 |
Login |
3099 |
0 |
3 |
89 |
3099 |
После чего рассчитать стоимость транзакции в секунду по формуле:
(%Resource utilization *resource
capacity)/(transaction per second) = transaction resource cost
Пример. Начинаем выполнять транзакцию Оперцаия 1 с количества
одновременных пользователей в системе N = 10. Постепенно увеличиваем
количество пользователей до тех пор, пока ограничения в системе не будут
превышены: Response time <=5 sec, CPU Utilization<=90%. При превышении
этого значения записываем средние показатели использования ресурсов
системы и обсчитываемых по указанной формуле. Получаем
(61% * 365MHz) /3 =74 MHz стоимость выполнения одной транзакции с
именем "Оперцаия 1"
Аналогично рассчитывается стоимость любого ресурса.
Теперь необходимо рассчитать стоимость каждой транзакции из таблицы 1
с помощью указанной выше формулы.
Результатом этого этапа станет таблица 3.
Таблица 3
Transaction |
CPU Cost MHz |
Операция 1 |
74.62333 |
Операция 2 |
24.37929 |
Операция 3 |
17.249 |
Операция 4 |
20.29294 |
Операция 5 |
17.249 |
Операция 6 |
14.68 |
Операция 7 |
18.35 |
Операция 8 |
16.515 |
Операция 9 |
31.36182 |
Операция 10 |
28.13667 |
Операция 11 |
30.02727 |
Операция 12 |
18.99765 |
Операция 13 |
53.82667 |
Операция 14 |
20.07706 |
Операция 15 |
19.49688 |
Операция 16 |
46.13714 |
Операция 17 |
33.84556 |
Операция 18 |
33.84556 |
Операция 19 |
172.49 |
Операция 20 |
146.8 |
Login |
108.8767 |
График 1 иллюстрирует затраты ресурсов процессора на каждую из
транзакций.
График 1
Так как наша задача связана и определением нагрузки на WEB приложение
, то для генерации нагрузки на него можно воспользоваться готовым
решением "Web Application Stress Tool" (WAST). Это приложение имитирует
работу пользователей с указанным ресурсом.
В WAST необходимо создать по отдельному скрипту для каждой транзакции
в системе и выполнять эти скрипты по очереди с постепенным увеличением
количества пользователей. Также WAST позволяет отслеживать датчики
производительности, нагружаемой системы. В некоторых случаях WAST
некорректно отображает показания датчиков, поэтому для страховки
необходимо изпользовать performance monitor на тестируемой машине.
Подробнее о WAST можно прочитать тут:
http://msdn.microsoft.com/library/en-us/dnduwon/html/d5wast_2.asp?frame=true.
Определение профиля использования системы
Под профилем использования подразумевается совокупность операций
выполняемых пользователем за сессию в системе и их количество. Например,
система может использоваться в режиме активного поиска информации , или
в режиме просмотра определенных документов. Создадим профиль при котором
идет активное использование операции 1. Для этого предположим что
пользователь выполняет 90% транзакций по вызову операции 1 и 10 % тратит
на все остальные.
Таблица 4 описывает этот профиль
Таблица 4
Transaction |
nsession |
nsec* |
Операция 1 |
60 |
0.05 |
Операция 2 |
60 |
0.05 |
Операция 3 |
60 |
0.05 |
Операция 4 |
60 |
0.05 |
Операция 5 |
60 |
0.05 |
Операция 6 |
2 |
0.001667 |
Операция 7 |
2 |
0.001667 |
Операция 8 |
8 |
0.006667 |
Операция 9 |
2 |
0.001667 |
Операция 10 |
2 |
0.001667 |
Операция 11 |
2 |
0.001667 |
Операция 12 |
2 |
0.001667 |
Операция 13 |
2 |
0.001667 |
Операция 14 |
2 |
0.001667 |
Операция 16 |
2 |
0.001667 |
Операция 17 |
2 |
0.001667 |
Операция 18 |
2 |
0.001667 |
Операция 19 |
2 |
0.001667 |
Login |
1 |
0.000833 |
* nsec = nsession/t
t - время сессии
nsesion - транзакций за сессию
nsес - транзакций за секунду
Определение стоимости ресурсов для одного пользователя в системе
На основе профиля использования и стоимости каждой транзакции в
системе опеределим стоимость одного пользователя в системе.
Таблица 5
Transaction |
Cost per User Transaction
per sec. CPU MHz* |
Операция 1 |
3.731166667 |
Операция 2 |
1.218964286 |
Операция 3 |
0.86245 |
Операция 4 |
1.014647059 |
Операция 5 |
0.86245 |
Операция 6 |
0.024466667 |
Операция 7 |
0.030583333 |
Операция 8 |
0.1101 |
Операция 9 |
0.052269697 |
Операция 10 |
0.046894444 |
Операция 11 |
0.050045455 |
Операция 12 |
0.031662745 |
Операция 13 |
0.089711111 |
Операция 14 |
0.033461765 |
Операция 15 |
0.02 |
Операция 16 |
0.076895238 |
Операция 17 |
0.056409259 |
Операция 18 |
0.056409259 |
Операция 19 |
0.287483333 |
Операция 20 |
0.006 |
Login |
0.090730556 |
Total |
5.812580952 |
* Cost per User Transaction per sec. CPU MHz = CPU Cost
MHz * nsec
Стоимость пользователя в системе в секунду будет равняться сумме
стоимостей его операций за секунду.
Определение количества пользователей в сутки
Количество пользователей в сутки в нашем случае будет задано как одно
из требований к системе, также этот параметр можно определить анализируя
лог файлы системы.
Таблица 6
Users per day |
1000 |
10000 |
50000 |
100000 |
1000000 |
10000000 |
Определение максимального количества одновременных пользователей
Под одновременными пользователями подразумеваются пользователи,
которые в один и тот же промежуток времени выполняют транзакции в
системе. Количество таких пользователей определяется из лог файлов
системы, на основе требований к системе. Так же можно приблизительно
спрогнозировать этот параметр исходя из правила 80/20, что означает - 80
процентов пользователей могут выполнять транзакции в 20 процентов
времени. Определим среднее количество одновременных пользователей
системы. В результате выполнения этого пункта расширим Таблицу 8.
Таблица 7
Users per day (Users) |
Max Users per second (Nmax)* |
Avg Users per second (N)** |
CPU MHz max |
CPU MHz avg |
1000 |
0.046296296 |
0.011574 |
0.269101 |
0.067275 |
10000 |
0.462962963 |
0.115741 |
2.69101 |
0.067275 |
50000 |
2.314814815 |
0.578704 |
13.45505 |
3.363762 |
100000 |
4.62962963 |
1.157407 |
26.9101 |
6.727524 |
1000000 |
46.2962963 |
11.57407 |
269.101 |
67.27524 |
10000000 |
462.962963 |
115.7407 |
2691.01 |
672.7524 |
*Nmax=(0.8*users)/(24*60*60*0.2)
**N=users/(24*60*60)
Прогнозирование необходимого количества ресурсов для указанного
количества пользователей
Total_Cost_CPU_MHz_per_User_Transaction per sec - стоимость
ресурсов процессора на одного пользователя в секунду.
Требуемый CPU MHz для системы =
Total_Cost_CPU_MHz_per_User_Transaction_per_sec * Users.
То есть, если пропускная способность системы должа равняться 100
пользователям в секунду, то необходимый для этого CPU MHz будет
5.8*100=580 Мhz при заданном профиле.
Аналогично расчитываются и требования по остальным ресурсам.
В результате получим таблицу
Таблица 8
Users per day (Users) |
Max Users per second (Nmax) |
Avg Users per second (N) |
CPU MHz max |
CPU MHz avg |
1000 |
0.046296296 |
0.011574 |
0.269101 |
0.067275 |
10000 |
0.462962963 |
0.115741 |
2.69101 |
0.067275 |
50000 |
2.314814815 |
0.578704 |
13.45505 |
3.363762 |
100000 |
4.62962963 |
1.157407 |
26.9101 |
6.727524 |
1000000 |
46.2962963 |
11.57407 |
269.101 |
67.27524 |
10000000 |
462.962963 |
115.7407 |
2691.01 |
672.7524 |
Из таблицы 9 видно, что для обслуживания 10000000 пользователей в
день возможна требуемая пиковая пропускная способность FWS в 463
пользователя в секунду и для ее обспечения требуется мультипроцессорная
система которая будет давать суммарную производительность в 2700 MHz.
Резюме
Для того чтобы ответить на вопрос: "Сколько потребуется ресурсов для
системы при определенной нагрузке?", -необходиммо выполнить следующие
действия:
- Выбрать максимально мощную из доступных конфигурацию системных
ресурсов для системы.
- Определить время сессии, которое пользователь проводит в
системе.
- Определить транзакции(операции), которые выполняет пользователь
в системе.
- Определить загрузку системы для каждой транзакции (стоимость
транзакции). Для этого создать тестовую нагрузку на систему в виде
выполнения этой транзакции. И измерить загрузку ресурсов при этом.
После чего вычислить стоимость транзакции по фрмуле:
(%Resource utilization * resource
capacity)/(transaction per second) = transaction resource cost
- Определить профили использования системы.
- Определить стоимость ресурсов для одного пользователя в системе.
- Определить количество пользователей в сутки и требуемую
пропускную
- пособность системы при этом .
- Выразить зависимость необходимого количества ресурсов системы от
нагрузки по формуле:
resource capacity =
Total_Resource_Cost_per_User_Transaction_per_sec * Users.
Использованный материал
"Performance Optimization and Capacity Planning", Microsoft
Corporation, January 2002
http://msdn.microsoft.com/library/en-us/dnmscms01/html/cmsperfoc.asp?frame=true
"Capacity Planning", Microsoft Developer Network, February 2001
http://msdn.microsoft.com/library/en-us/dnduwon/html/d5cpctyplan.asp?frame=true
"Understanding Performance Testing", Microsoft Developer Network,
February 2001
http://msdn.microsoft.com/library/en-us/dnduwon/html/d5dplyover.asp?frame=true
"Performance Testing with the Web Application Stress Tool", Microsoft
Developer Network, January 2001
http://msdn.microsoft.com/library/en-us/dnduwon/html/d5wast_2.asp?frame=true
"Capacity Model for Internet Transactions", Microsoft Corporation,
April 1999
http://www.microsoft.com/siteserver/ssrk/docs/rk_TCA.doc
"Capacity Planning and Performance Testing", Microsoft Developer
Network, January 2002
http://msdn.microsoft.com/library/en-us/dncold/html/storcpctyplan.asp?frame=true
"Collecting Performance Data" , Microsoft Developer Network, February
2001
http://msdn.microsoft.com/library/en-us/dnduwon/html/d5collection.asp?frame=true