Планирование размера системных ресурсов для интернет-систем
В своей работе я столкнулся с необходимостью найти зависимость объемов ресурсов, требуемых для системы (например CPU Mhz), от нагрузки на нее. Попробовав поискать информацию по этой проблеме в Сети, ничего толкового на русском я не нашел. Но несколько статей на эту тематику удалось таки обнаружить на небезызвестном MSDN (Microsoft Developer Network, msdn.microsoft.com). Пришлось некоторое время потратить на анализ и объединение этих материалов, в результате чего и получилась эта статья. В ней описывается конкретный опыт по решению задачи планирования конфигурации системы. Специфика работы ориентирована прежде всего на интернет-системы: вебсайты, веб-сервисы и прочие системы, где нагрузка создается по HTTP-протоколу методами POST и GET. Однако я думаю, что ничто не мешает адаптировать методику под любые программные системы.
описание задачи
Требуется найти зависимость объема ресурсов от нагрузки для конкретной программной системы.
решение
Эту задачу можно разбить на подзадачи:
1.Описание текущей конфигурации системы.
2.Анализ предметной области и выявление требований к системе.
3.Планирование размера ресурсов.
текущая конфигурация системы
Web server
Processorx86 Family 6 Model 6 Stepping 0 GenuineIntel ~367 Mhz
Total Physical Memory267,812 KB
Available Physical Memory114,120 KB
Желательно проводить тестирование на наиболее мощном из ваших компьютеров.
OS NameMicrosoft Windows 2000 Advanced Server
Version5.0.2195 Service Pack 2 Build 2195
требования
Основное требование для интернет-системы — время ответа веб-сервера на запрос пользователя. Время ответа складывается из времени выполнения запроса на сервере, времени ожидания выполнения запроса и времени передачи ответа по сети. Так как в нашем случае все тестирование проводится в рамках интранет-сети и объем выдаваемой WEB сервером информации невелик, то временя передачи ответа по сети можно опустить.
Время ответа должно быть меньше или равно 5 секундам.
Кроме требований по предметной области существуют и технические требования, которые должны соблюдаться в процессе тестирования. Основным техническим требованием является использование процессора не более чем на 90%. Более подробно с техническими требованиями можно ознакомиться здесь — http://msdn.microsoft.com/library/en-us/dnduwon/html/d5collection.asp?frame=true
планирование размера ресурсов
Задачу по планированию конфигурации для программных систем возможно решать двумя основными путями. Первый — традиционный подход (Conventional Approach) — подразумевает использование нескольких конфигураций для тестирования с последующим сравнением полученных на каждой результатов тестов и выбора оптимальной конфигурации.
Другой метод планирования конфигурации — метод анализа стоимости транзакции в системе (Transaction Cost Analysis), его задача определить стоимость в ресурсах для каждой операции, производимой в системе пользователем.
традиционный подход
Состоит из двух видов тестов:
1. Stress test. Задача теста — определить максимальную нагрузку на систему при данной конфигурации и измерить используемые при этом ресурсы системы: пропускную способность , загруженность процессора и т.п. Тест проводится в несколько итераций с постепенным повышением нагрузки. Например: 1000 пользователей, 2000 пользователей, 3000 пользователей. После каждой итерации проверяются показатели работы системы, если показатели превышают указанные допустимые пределы (например CPU Utilization>90%) то нагрузка, вызвавшая это, считается критической для данной конфигурации и дальнейшие итерации прекращаются.
2. Scalability test. Задача теста — подобрать необходимую конфигурацию для системы. Тест состоит из нескольких итераций Stress test на разных конфигурациях. Если при критической нагрузке на данной конфигурации не выполняются требования к некоторым параметрам работы системы, то конфигурация считается неприемлимой и подбирается новая, в которой наиболее дефицитный ресурс наращивается.
анализ стоимости транзакций
Для решения задачи определения и прогнозирования конфигурации наиболее оптимальным методом, на мой взгляд, является анализ стоимости транзакции в системе (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.Определить время работы в системе одного пользователя(время сессии).
2.Определить транзакции, которые выполняет пользователь в системе.
3.Определить загрузку системы для каждой транзакции (стоимость транзакции).
4.Определить профили использования системы.
5.Определить стоимость ресурсов для одного пользователя в системе.
6.Определить количество пользователей в сутки.
7.Определить максимальное количество одновременных пользователей.
8.Прогнозирование необходимого количества ресурсов для указанного количества пользователей.
определение транзакций, которые выполняет пользователь в системе
Список этих транзакций определяется исходя из функциональности системы. Операциями могут являться : поиск, запрос определенной страницы на сайте и пр.
Таблица 1
| Transaction | |
| Операция 1 | |
| Операция 2 | |
| Операция 3 | |
| Операция 4 | |
| Операция 5 | |
| Операция 6 | |
| Операция 7 | |
| Операция 8 | |
| Операция 9 | |
| Операция 10 | |
| Операция 11 | |
| Операция 12 | |
| Операция 13 | |
| Операция 14 | |
| Операция 15 | |
| Операция 15 | |
| Операция 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 Wait 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 | 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 |
График 1 иллюстрирует затраты ресурсов процессора на каждую из транзакций.
График 1
Так как наша задача связана и определением нагрузки на веб-приложение, то для генерации нагрузки на него можно воспользоваться готовым решением "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 - время сессии
nsession- транзакций за сессию
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 |
* 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 процентов времени. Определим среднее количество одновременных пользователей системы.
Таблица 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 |
Итак, видно, что для обслуживания 10000000 пользователей в день возможна требуемая пиковая пропускная способность FWS в 463 пользователя в секунду и для ее обспечения требуется мультипроцессорная система которая будет давать суммарную производительность в 2700 MHz.
резюме
Для того чтобы ответить на вопрос: "Сколько потребуется ресурсов для системы при определенной нагрузке?", необходиммо выполнить следующие действия:
1.Выбрать максимально мощную из доступных конфигурацию системных ресурсов для системы.
2.Определить время сессии, которое пользователь проводит в системе.
3.Определить транзакции(операции), которые выполняет пользователь в системе.
4.Определить загрузку системы для каждой транзакции (стоимость транзакции). Для этого создать тестовую нагрузку на систему в виде выполнения этой транзакции. И измерить загрузку ресурсов при этом. После чего вычислить стоимость транзакции по фрмуле:
(%Resource utilization * resource capacity)/(transaction per second) = transaction resource cost
5.Определить профили использования системы.
6.Определить стоимость ресурсов для одного пользователя в системе.
7.Определить количество пользователей в сутки и требуемую пропускную способность системы при этом .
8.Выразить зависимость необходимого количества ресурсов системы от нагрузки по формуле:
resource capacity = Total_Resource_Cost_per_User_Transaction_per_sec * Users.
Шеломанов Роман
Сетевые решения. Статья была опубликована в номере 01 за 2003 год в рубрике sysadmin
