tag:blogger.com,1999:blog-5008754483824116042023-11-15T10:56:30.430-08:00Нагрузочное тестирование ПОUnknownnoreply@blogger.comBlogger16125tag:blogger.com,1999:blog-500875448382411604.post-5858393770422100002009-05-27T12:27:00.000-07:002009-05-30T01:33:48.119-07:00Мониторинг аппаратных серверовВремена выполнения операций в тесте желательно рассматривать вместе с анализом загрузки ресурсов аппаратных серверов, на которых развернуто и работает приложение. Если, например, операции выполняются медленно и при этом время отклика дискового массива, который использует СУБД намного хуже критериев, то с большой долей вероятности можно утверждать, что "узкое место" в системе создается низкопроизводительной работой дисковой стойки. Как правило избавившись от одной "узкости", тут же можно столкуться со следующей. Часто "узким местом" является само приложение, которое спроектировано и разработано так, что требует больших мощностей, для того чтобы обеспечивать удовлетворительную производительность. <br /><br />Итак, какие метрики являются самыми распространенными и какие значения они могут принимать.<br /><br />ЦПУ<br />1. Счетчики для загрузки ЦПУ<br />MS Performance : Processor\% Processor Time, Processor\% User Time, Processor\% Idle Time<br />Unix (Solaris) : sar -u : %usr, %sys, %wio, %idle<br />2. Значение очереди<br />MS Performance : System\Processor Queue Length<br />Unix (Solaris) : sar -q : размер средней очереди<br /><br />В качестве примеров используются утилиты мониторинга MS Performance для MS Windows и sar (system activity reporter), который есть во многих unix-ах. Для Microsoft %Processor Time является метрикой используемости ЦПУ в течение контролируемого интервала. В это значение, насколько я понимаю, входит вся активность и справедливо следующее утверждение : %Processor Time + %Idle Time = 100%. Счетчик %User Time включает в себя активность прикладных программ. Для sar полная активность по использованию ЦПУ определяется суммой %usr + %sys. При этом %usr это активность прикладных программ а %sys обслуживание различных системных вызовов. Счетчик %wio показывает сколько времени (в %) было потрачено на ожидания ввода вывода. Идеально это %wio не должно постоянно быть большим и вобщем-то стремиться к нулю. Замеренные значения загрузки ЦПУ целесообразно рассматривать совместно со значениями счетчиков очереди. Очередь показывает, какое количество задач (тредов) ожидает своего выполнения. Как правило очередь появляется при увеличении загрузки ЦПУ до значений 60 и более процентов. Желательно чтобы значение очереди не превышало количество процессоров на сервере, так как в этом случае задания будут ждать и не выполняться. При этом высокая загрузка до 90% и наличие очередей допустимо, если времена выполнения операций удовлетворяют примлемым для бизнеса критериям. Надо только понимать, что этом случае у системы практически нет запаса ресурса и повышение нагрузки может привести к ухуджению (причем даже к нелинейному) производительности системы.<br /><br />Память<br />1. Счетчики доступного объема памяти<br />MS Performance : Memory\Available Mbytes<br />Unix (Solaris) : sar -r<br /><br />Если количество доступной памяти (во время теста или при эксплуатации) снизилось до 10% процентов от общего объема, то это уже повод для нахождения причин приводящих к такой ситуации. Если доступной памяти остается меньше 5%, то скорее всего нехватка памяти уже приобретает статус "узкого места". Также тенденция уменьшения размера доступной памяти в пределах значения 10 Мб/час может указывать на "утечку памяти".<br /><br />Дисковые массивы.<br />MS Performance : Physical Disk\Avg. Disk sec/Write, Physical Disk\Avg. Disk sec/Read<br /><br />Показателями медленной работы дисковой подсистемы являются значения счетчиков Avg. Disk sec/Read, Avg. Disk sec/Write идеально эти значения должны быть в пределах 10ms (для журналов транзакций СУБД в идеале 0 мсек), превышения значений счетчиков > 25ms в течение длительного времени (более 5 минут) является указателем на медленную работу дисков. Ранее вторым критерием было наличие очереди на диски, считалось, что значение 2 на шпиндель уже является проблемой. Сейчас в современных дисковых массивах, в связи с виртуализацией дискового пространства, измерение этого параметра стало затруднительным (для примитивных дисковых хранилищ типа Direct attach storage - DAS и внутренних дисков сервера этот параметр по-прежнему может использоваться). При этом, чтобы понять насколько производительно используется дисковый массив под управлением той или иной операционной системы (Unix), желательно проконсультироваться со специалистами по данному типу дискового массива.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-500875448382411604.post-87730261017002473042009-05-27T12:19:00.000-07:002009-05-27T12:24:45.268-07:00ТестированиеИтак, сейчас добавим немного методологии по проведению самого нагрузочного тестирования. Допустим, что все предыдущие шаги успешно завершены, а это значит, что у нас есть:<br />1. Разработанная и согласованная модель нагрузки. Для модели отобраны критичные для данного вида тестирования операции, определены интенсивности их выполнения в тесте. Определены профили нагрузки, если Приложение имееет различные модели поведения. Рассчитаны нагрузочные точки.<br />2. Для моделируемых операций разработаны нагрузочные скрипты и созданы необходимые датапулы.<br />3. Разработаны сценарии, выполнения криптов, которые соответствуют профилям модели нагрузки.<br />4. Произведена проверка работы скриптов в сценариях. Необходимо исполнить каждый скрипт входящий в сценарий, используя хотя бы несколько виртуальных пользователей в группе, чтобы исключить ошибки взаимного влияния скриптов друг на друга. Тут же могут быть обнаружены скрипты с недостаточно хорошо сделанной корреляцией.<br /><br />Если ошибок нет, то тогда можно приступать к испытаниям. Необходимо заметить, что оборудование тестового стенда должно в идеале как можно ближе соответствовать промышленной конфигурации. Особенно в случае, когда на основе полученных в результате тестирования времен выполнения операций будут приниматься какие-то бизнес решения. В случае если речь идет просто об оптимизации Приложения, то соответствие конфигураций тестового стенда и промышленного уже не так актуально. Для мониторинга тестовых серверов необходимо иметь доступ на сервера с правами для использования таких утилит как MS Windows Performance для MS Windows или sar, iostat, vmstat для unix-образных OS. При сохранении журналов мониторинга на тестовых серверах необходимо убедиться в наличии дискового простанства для хранения соответствующих объемов информации.<br /><br />Первые запуски тестов являются пробными и позволяют понять поведение системы в целом, включая работу тестируемого Приложения и оборудования, на котором оно размещено. Начинать испытания надо с нагрузочных точек с меньшей нагрузкой, двигаясь по мере нарастания нагрузки от меньшей к большей. Может получиться так, что в процессе тестирования количество нагрузочных точек поменяется, а также изменятся количества виртуальных пользователей входящих в ту или иную нагрузочную точку. Хотелось бы так же заметить, что результаты испытаний в идеале должны быть логически согласованы. Это значит, что при увеличении нагрузки, результаты времен выполнения операций (и загрузки тестового оборудования) должны соответственно ухудшаться, а не наоборот. Если на нагрузочной точке с большей нагрузкой результаты лучше, то такой эксперимент надо перепровести, чтобы понять причины такого "выброса". Как вариант возможна ситуация, что нагрузочные точки были неправильно спроектированы и возможно нужно увеличть размер "шага", чтобы действительно почувствовать увеличение нагрузки. В заключение хочется добавить, что набор экспериментов (и как следствие результатов) должен быть достаточен для того, чтобы можно было провести анализ "узких" мест и сделать выводы о производительности и стабильности работы тестируемого Приложения.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-500875448382411604.post-64527373795043010972009-02-10T10:27:00.000-08:002009-02-10T10:34:39.789-08:00Доступ к объектам формыWeb Click&Script : HP Load Runner <br /><br />В отдельных случаях не остается ничего кроме как работать с объектами формы непосредственно с помощью javascript-а, используя их методы и свойства. Технология Web (Click and Script) предоставляет такую возможность. С точки зрения DOM (Document Object Model) любой объект на веб странице должен иметь свой уникальный идентификатор. Выяснив этот идентификатор любым путем, например, анализируя source code для той или иной страницы, впоследствии можно писать операторы вручную, взяв в качестве образца какой либо похожий по типу объект формы. При этом такие элементы DESCRIPTION как name или type уже становятся второстепенными. Выполнение этого оператора будет в основном зависеть от того что находится в ACTION.<br /><br />web_edit_field("1_1",<br /> "Snapshot=t21115.inf",<br /> DESCRIPTION, <br /> "Type=password", <br /> "name= PinCode ", <br /> "WindowType=Modal", <br /> ACTION, <br /> "EvalJavaScript=document.getElementById(\"CardNum\").value=\"1111222233334444\"",<br /> LAST);<br /> <br />web_edit_field("1_2", <br /> "Snapshot=t21116.inf",<br /> DESCRIPTION, <br /> "Type=password", <br /> "name= PinCode", <br /> "WindowType=Modal", <br /> ACTION, <br /> "EvalJavaScript=document.getElementById(\"CardOwner\").value=\"Shirobokov\"",<br /> LAST);<br /><br />Поскольку пример взят из практики работы с модальным окном, то и тип окна тоже соответственно модальный. Хотя, безусловно это техника не зависит от типа веб страницы.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-500875448382411604.post-23929691799361949262009-02-10T10:09:00.000-08:002009-02-10T10:32:39.580-08:00Работа с модальным окномWeb Click&Script : HP Load Runner <br /><br />При работе с модальными окнами в технологии Web Click and Script может не происходить запись трафика для операций, выполняемых в самом модальном окне. Напомним, что под модальным окном понимается всплывающее диалоговое окно, вызываемое методом ShowModalDialog в javascript-e. Технологией, по которой сделано Приложение, использующееся в качестве примера, является ASP.Net, это значит, что в данное модальное окно загружается динамически сформированная на сервере форма (технология Active Server Page). Фактически запись трафика прекращается после отработки оператора, вызывающего модальное окно. В нашем случае это:<br /><br />web_text_link("Запросить баланс из банка",<br /> "Snapshot=t91.inf",<br /> DESCRIPTION,<br /> "Text= Запросить баланс из банка ",<br /> ACTION,<br /> "UserAction=Click",<br /> LAST);<br /><br />Предлагаемое решение заключается в регистрации, так называемой call back функции, в которую и включаются Click and Script операторы обработки полей и кнопок формы, расположенной в модальном окне. Регистрация call back функции происходит с использованием оператора web_reg_dialog, применить который необходимо перед использованием оператора непосредственно вызывающего модальное окно. Вот так:<br /><br /><br />web_reg_dialog(<br /> DESCRIPTION,<br /> "Type=Modal",<br /> ACTION,<br /> "SetCallback=ModalDialog1",<br /> LAST);<br /><br /> web_text_link("Запросить баланс из банка",<br /> "Snapshot=t91.inf", <br /> DESCRIPTION, <br /> "Text= Запросить баланс из банка",<br /> ACTION,<br /> "UserAction=Click",<br /> LAST);<br /><br />А теперь пример обработки полей и кнопок внутри call back функции. Реализовано в виде добавленного в скрипт файла с именем МodalDialog1.c и одной функцией ModalDialog1(). Разумеется, что кусок кода в файл ModalDialog1 приходится добавлять вручную, зная идентификаторы или имена объектов находящихся на форме внутри модального окна.<br /><br />ModalDialog1()<br />{<br />...<br />web_edit_field("pin code", <br /> "Snapshot=t21117.inf",<br /> DESCRIPTION, <br /> "Type=password", <br /> "name=PinCode", <br /> "WindowType=Modal", <br /> ACTION, <br /> "SetValue=хххх", <br /> LAST);<br /><br />web_button("btnSubmitModalDialog", <br /> "Snapshot=t21118.inf",<br /> DESCRIPTION, <br /> "Type=submit", <br /> "WindowType=Modal", <br /> "name=btnSubmit", <br /> LAST);<br />...<br />Return 0;<br />}<br /><br />Кнопка с названием “btnSubmit” выполняет submit формы модального окна.<br /><br />Остается добавить, что в этом случае необходимо присутствие в скрипте (*.h) файла (modal_dialog_callbacks.h) с определениями.<br /><br />#ifndef _MODALDIALOGCALLBACKS_H<br />#define _MODALDIALOGCALLBACKS_H<br />#include "ModalDialog1.c"<br />#endif // _MODALDIALOGCALLBACKS_H<br /><br />Файл globals.h также должен учитывать внесенные в скрипт изменения.<br /><br />#ifndef _GLOBALS_H <br />#define _GLOBALS_H<br />//-----------------------------------------------------<br />// Include Files<br />#include "lrun.h"<br />#include "web_api.h"<br />#include "lrw_custom_body.h"<br />#include "modal_dialog_callbacks.h"<br />//-----------------------------------------------------<br />// Global Variables<br />#endif // _GLOBALS_H<br /><br />Еще раз замечу, что при использовании операторов, выполняющих операции в модальном окне необходимо указывать тип окна – модальное (“WindowType=Modal”).Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-500875448382411604.post-51237929160598268172009-02-10T10:04:00.000-08:002009-02-10T10:08:47.570-08:00Протокол Web (Click and Script) : HP Load RunnerНачиная с версии 8.1, в Load Runner-e появилась альтернатива использованию протокола web (http/html) при работе с Web приложениями. Такой технологией является протокол Web (Click and Script). При просмотре записанного трафика вначале довольно непривычно не видеть знакомых web_submit_form или web_url, соответствующих точной последовательности обменов данными между клиентом и сервером. Вместо них появляются web_link, web_button, web_browser и так далее. Протокол Web (Click and Script) помещает в файл скрипта операторы, соответствующие использованию объектов пользовательского интерфейса. Последовательность операторов в скрипте соответствует последовательности использования тех или иных объектов (GUI) пользовательского интерфейса. При работе с Web (Click and Script) отпадает необходимость в применении ряда корреляций особенно связанных с сессионными и другими специальными идентификаторами, передаваемыми от сервера к клиенту и обратно. Например, можно забыть о кошмаре корреляции огромных VIEWSTATE-ов при работе с ASP.NET или о корреляции разнообразных cookies и так далее. При работе с Web (Click and Script) Load Runner эмулирует собой Web browser и таким образом берет эти функции на себя. Разумеется, что корреляция, связанная с работой самого Приложения, если таковая необходима, не может быть выполнена Load Runner-ом автоматически. Так что совсем избежать изучения журналов выполнения скриптов может не получится, тем не менее применение технологии Web (Click and Script) во многих случаях позволяло экономить силы и время.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-500875448382411604.post-7267401285358326662008-12-09T12:33:00.000-08:002008-12-09T12:50:01.704-08:00Программирование динамического оператора<em> Описываемая техника применялась в работе с Web (http/html) протоколом в HP Load Runner. </em><br /><em><br /></em> Иногда может быть полезным не добавлять параметры в датапулы, увеличивая их количество и усложняя структуру, а генерировать данные внутри скрипта, меняя их от итерации к итерации. При этом необходимая часть оператора строится динамически в виде строки, в которую каждый раз вставляются обновленные данные. В примере, динамически меняющимися на каждой итерации данными, являются даты начала и конца периода (переменные day_start и day_stop меняются каждую итерацию), используемые для построения отчета. Пример приведен в качестве иллюстрации динамического конструирования операторов и перебирает дни в диапазоне только от 1 до 30.<br />Сконструированными частями оператора будут строковые переменные <strong>url</strong> и <strong>referer</strong>. Обе они включаются в состав оператора web_url.<br /><br />Action()<br />{<br /><br />static int dstart = 1, dstop = 1;<br />int i,j;<br />char tr_name[50],<br /> url[512],<br /> referer[512],<br /> param[512],<br /> host_name[128],<br /> day_start[4],day_stop[4]; <br />...<br /><br />strcpy(host_name,lr_eval_string("{host}"));<br />itoa(dstart,day_start,10);<br />itoa(dstop,day_stop,10);<br /><br />lr_message(host_name);<br />lr_message(" %s %s", day_start, day_stop);<br /><br />....<br /><br />strcpy(url,"URL=");<br />strcpy(referer,"Referer=");<br />strcpy(param,"https://");<br />strcat(param,host_name);<br />strcat(param,"/site/transactions/TransactionsReport?sortBy=0&sortName=fine&sortOrder=A");<br /><br />lr_output_message(param);<br /><br />strcat(param,"&dayFrom=");<br />strcat(param,day_start);<br />strcat(param,"&monthFrom=8&yearFrom=2005&dayTo=");<br />strcat(param,day_stop);<br />strcat(param,"&monthTo=1&yearTo=2006&dateType=delta&Status=S");<br /><br />lr_output_message(param);<br /><br />strcat(url,param);<br />strcat(referer,param);<br /><br />lr_message(url);<br />lr_message(referer);<br /><br />lr_start_transaction("Search transactions");<br /><br />web_url("TransactionsReport",<br /> <strong>url</strong>,<br /> "Resource=0",<br />"RecContentType=text/html",<br />"Referer=",<br />"Snapshot=t3.inf",<br />"Mode=HTML",<br />EXTRARES,<br />"Url=/site/images/big_s.gif", <strong>referer</strong>, ENDITEM,<br />"Url=/site/images/link_list_head.gif", <strong>referer</strong>, ENDITEM,<br />LAST);<br /><br />lr_end_transaction("Search transactions", LR_AUTO);<br /><br />dstart++;<br />dstop++;<br />if (dstart == 31)<br /> {<br /> dstart = 1;<br /> dstop = 1;<br /> }<br />....<br />return 0;<br />}Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-500875448382411604.post-57416976997997865342008-12-09T12:02:00.000-08:002008-12-09T12:31:48.744-08:00Практические аспекты нагрузочного тестированияНачиная с этой статьи, будут публиковаться материалы по практическим вопросам нагрузочного тестирования. В основном это интересные с моей точки зрения решения тех или иных проблем, встреченных при работе над проектами. Подготовка к тестированию - это, как правило, разработка тестовых скриптов и сценариев. Поэтому первые статьи будут посвящены разработке скриптов с помощью инструмента нагрузочного тестирования HP Load Runner. Возможно что то из моего опыта пригодится кому то еще. При этом не вижу большого смысла «перепечатывать» главы из документации или из книг выпущенных компаниями HP (Mercury), так как каждый может ознакомиться с ними самостоятельно. Также уверен, что большинство проблем можно решать на основе стандартной документации и решений предлагаемых HP (Mercury), что и сам почти всегда стараюсь делать. Пока буду включать в блог все статьи, посвященные практике подряд, по мере их появления. Возможно это приведет к некоторой потере логической стройности, которой я старался придерживаться до сих пор. Впрочем блог это не книга, так что надеюсь на понимание:).Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-500875448382411604.post-28958036029160925812008-06-21T10:52:00.000-07:002008-06-21T10:59:24.770-07:00Разработка модели нагрузки<strong>Base line нагрузочная точка</strong><br /><br /> Хочется заметить что такой расчет нагрузочной точки (описан в предыдущей статье), основанный на собранной для работающего приложения статистике (или на ожидаемом объеме работы для вновь разработанного приложения), является исходным для дальнейшего роста нагрузки. А сама расчитанная нагрузочная точка может считаться базовой или base-line точкой. Теперь можно увеличивать нагрузку, двигаясь с некоторым шагом, увеличивая при этом только количество виртуальных пользователей в группах, не изменяя интенсивности выполнения операций для одного виртуального пользователя.<br /><br /><strong><em>На мой взгляд полная модель нагрузки - это набор профилей нагрузки со всеми нагрузочными точками для каждого профиля.</em></strong> При разработке тестовых сценариев должны быть корректно реализованы все нагрузочные точки. Еще хотелось бы добавить, что нагрузочных точек для каждого профиля должно быть не меньше трех, чтобы можно было оценить зависимость времен отклика выполняемых операций от роста нагрузки. Очевидно, что чем линейнее такая зависимость тем лучше масштабируемость приложения и выше предсказуемость его поведения под нагрузкой.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-500875448382411604.post-68111400864944603752008-06-19T13:08:00.000-07:002008-06-23T23:59:24.554-07:00Разработка модели нагрузки<strong>Расчет нагрузочных точек<br /></strong><br />Поскольку в профиле нагрузки как правило присутствует несколько операций - это означает, что у нас будет несколько групп пользователей. Желательно моделировать каждую операцию отдельной группой виртуальных пользователей (хотя в жизни часто бывает наоборот, один бизнес пользователь может отвечать за выполнение нескольких операций). Тем не менее, если назначить одному виртуальному пользователю выполнение одной операции то так легче выдержать определенную интенсивность (и соответственно производительность) для этой операции в тесте чем в случае, когда виртуальному пользователю назначается последовательная цепочка операций. Зная интенсивность выполнения операции нужно определить количество виртуальных пользователей в группе, выполняющих эту операцию. Идеальный случай когда работа с приложением аналогична работе заводского конвейра и есть точные оценки сколько операций в день делает один пользователь. Чаще всего бывает не так и известно только общее количество операций выполняемое в течение дня. Так же может оказаться, что интенсивность выполнения операции каждым пользователем очень низкая, например, один пользователь выполняет операцию раз в день или раз в два дня.<br /><br />Моделирование работы с пересчетом интенсивностей в этом случае можно проиллюстрировать следующим примером<br /><br />ПРИМЕР: (для одной операции)<br /><br />Количество операций = 200 за 4 часа<br />Количество бизнес пользователей = 20<br />---------------------------------------<br /><br />1. Определяем количество операций для каждого пользователя<br /><br />200/20 = 10<br /><br />2. В час каждый пользователь выполняет 2.5 операции<br /><br />10/4 = 2.5<br /><br />3. Определяем период повторения операции (интенсивность) для каждого пользователя<br /><br />60/2.5 = 24 минуты<br /><br />4. Чтобы уменьшить время теста до часа, и при этом получить хоть какую то статистику по выполнению операций, а так же улучшить "перемешивание" операций во время теста, можно увеличить интенсивность в 4 раза, при этом уменьшив количество пользователей так же в 4 раза.<br /><br />24/4 = 6 мин. = 360 секунд<br /><br />Таким образом, 5 виртуальных пользователей, выполняя операцию с периодом 6 минут, обеспечат за 4 часа заданную производительность равную 200 операциям.<br /><br /><p>Что дает такой пересчет :<br /></p><p>Во-первых, есть возможность снизить время теста, не теряя статистики выполнения операций, а следовательно и достоверности результатов теста. Во-вторых, можно снизить количество моделируемых пользователей там где их число уходит за несколько тысяч и таким образом понизить требования к количеству ресурсов нагружающих компьютеров (1VU может требовать до 10Мб оперативной памятинагружающего компьютера ), а в некоторых случаях и выполнить условия лицензионного соглашения (стоимость лицензии для тестового инструментария зависит от количества виртуальных пользователей)<br /></p><p>Какие есть ограничения :</p><p>Для некоторых приложений, может быть критично количество одновременно открываемых соединений между клиентом и сервером. Встречались ситуации когда запросы к базе данных начинали работать значительно медленнее если при работе с приложением увеличивается количество именно разных пользователей (разные логины) а не интенсивность запросов. И наконец, увеличение интенсивности выполнения операций, не должно приводить к ситуации когда период повторения становится меньше чем время выполнения самой операции.</p><p>В любом случае, несмотря на некоторые ограничения, подобный расчет может допускать варьирование количеством виртуальных пользователей и интенсивностью выполнения ими операций. При этом производительность и соответственно нагрузка не должна изменяться и отличаться от заданной. Итак, нагрузочная точка включает в себя расчеты виртуальных пользователей и интенсивностей по всем операциям профиля нагрузки. </p><p>Дополняем терминологию :<br /></p><p>8. Нагрузочной точкой называется расчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями.</p><p><br /></p>Unknownnoreply@blogger.com10tag:blogger.com,1999:blog-500875448382411604.post-57078063316944180612008-06-19T12:52:00.000-07:002008-06-21T10:24:30.167-07:00Разработка модели нагрузки<strong>Определение профиля нагрузки</strong><br /><br />Итак ключевым моментом в модели нагрузки являются выбранные для тестирования операции. Желательно ввести здесь новый термин - профиль нагрузки. Профилем нагрузки называется набор операций с заданными интенсивностями выполнения. Естественно выполняться эти операции в тесте должны одновременно. Профилей нагрузки для приложения может быть несколько и это оправдано. Ведь бизнес пользователи могут выполнять разные наборы операций в разное время. Например, начало операционного дня и конец дня, начало месяца (квартала) и соответственно завершение могут отличаться. Таким образом получаем различные наборы операций приложения, выполняющиеся одновременно и соответственно создающие различную нагрузку. Кстати меняться могут не только сами операции но и и их интенсивности. В первом приближении моделью нагрузки является набор профилей нагрузки, где каждый профиль отличается от другого или набором операций или интенсивностями выполнения этих операций.<br /><br />Пример профиля нагрузки, в который входит 5 операций, значение n может быть различным для каждой операции.<br /><br /><Профиль нагрузки><br />1. Операция_1 - интенсивность выполнения n раз / ед. времени<br />2. Операция_2 - интенсивность выполнения n раз / ед. времени<br />3. Операция_3 - интенсивность выполнения n раз / ед. времени<br />4. Операция_4 - интенсивность выполнения n раз / ед. времени<br />5. Операция_5 - интенсивность выполнения n раз / ед. времени<br /><br />Дополняем терминологию (нумерацию я решил сделать сквозную) :<br /><br />7. Профилем нагрузки называется набор операций с заданными интенсивностями, полученными на основе статистики.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-500875448382411604.post-51240394410921236632008-06-01T09:30:00.000-07:002008-06-01T11:01:34.301-07:00Разработка модели нагрузки<p><strong>Изучение Приложения</strong></p><p>Будем называть тестируемое прикладное программное обеспечение "приложением". Собственно я так его уже и называю в предыдущих сообщениях. Чтобы выделить части приложения, а именно операции, которые будут тестироваться, необходимо провести работу связанную с изучением приложения. Очень большую пользу при этом должны оказать разработчики приложения, если речь идет о тестировании в процессе разработки, либо бизнес пользователи и системные администраторы, если приложение находится в процессе эксплуатации. В ходе этой работы разумно сделать такие шаги:</p><p><strong>-</strong>Описание компонентов приложения с составлением схемы взаимодействия между ними</p><p><strong>-</strong>Выделение критических с точки зрения предполагаемого тестирования операций, в качестве таковых могут быть выбраны:</p><ol><li><div align="left">Операции с "тяжелыми" запросами к базе данных, отчеты</div></li><li><div align="left">Операции, выполняемые большим количеством пользователей или с высокой интенсивностью</div></li><li><div align="left">Операции критичные с точки зрения бизнеса и к тому же удовлетворяющие условиям двух верхних пунктов </div></li></ol><p align="left"> Еще раз хочется заметить, что опрос бизнес пользователей или совместное исследование с разработчиками и администраторами системы может значительно облегчить задачу. Если приложение находится в эксплуатации то можно провести мониторинг загрузки компонентов аппаратных серверов (процессора, память, диски) и проанализировать системные журналы веб серверов, снять stats pack, если в качестве сервера базы данных, например, используется Oracle. Системные журналы могут показать пики высокой активности пользователей в течение дня и дать количественное оценки того сколько транзакций (хитов) выполняется в единицу времени. Есть "золотое правило" гласящее, что 20% операций приложения генерируют 80% нагрузки в системе. Нужно стараться выбрать для моделирования именно эти 20% операций.</p><p align="left"><span style="font-size:0;"></span></p>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-500875448382411604.post-11894429032763929912008-06-01T04:15:00.000-07:002008-06-01T10:57:23.274-07:00Разработка модели нагрузкиОпределившись с целями и сущностями, можно переходить к одной из основных задач в нагрузочном тестировании, к разработке модели нагрузки. В двух словах для этого нужно определить список тестируемых операций и установить с какой интенсивностью они выполняются. Изменяется ли интенсивность выполнения операций в течении времени или она носит равномерный характер. В список таких задач должны войти операции, которые критичны с точки зрения бизнеса и с технической точки зрения. Критичностью с точки зрения бизнеса (и это основной критерий) является реальное влияние ухудшения производительности таких операций на бизнес процессы. Например, увеличение длительности обслуживания клиентов в банке, невозможность выполнить необходимое количество операций в течение дня и так далее. С технической точки зрения - это операции максимально потребляющие ресурсы серверов. Как правило - это операции выполняемые большим количество бизнес пользователей одновременно или создание сложных отчетов, в которые входят так называемые "тяжелые" запросы к базе данных. Хочу еще раз подчеркнуть что степенью критичности является влияние на бизнес и таким образом, например, выполнение какого нибудь отчета полностью загружающего сервер базы данных, но в ночное время, не будет носить высокий приоритет для оптимизации.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-500875448382411604.post-84471705832527740902008-05-11T12:10:00.000-07:002008-05-11T12:16:10.468-07:00Цели нагрузочного тестирования1.Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию.<br /><br />2. Оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов.<br /><br />3. Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода.<br /><br />4. Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера.<br /><br /><br /> В рамках одной цели могут использоваться разные виды тестов, например, для первой, второй и третьей цели нужно производить как тестирование производительности так и тестирование стабильности.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-500875448382411604.post-4754407416012313782008-05-11T11:41:00.000-07:002008-06-20T01:17:43.050-07:00Виды нагрузочных тестовВ нагрузочное тестирование входят следующие тесты.<br /><br />1.Тестирование производительности<br />Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:<br />-измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.<br />-определение количества пользователей, одновременно работающих с приложением.<br />-определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций)<br />-исследование производительности на высоких, предельных, стрессовых нагрузках. <br /><br />2. Стрессовое тестирование<br />Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.<br /><br />3. Объемное тестирование<br />Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:<br />-измерение времени выполнения выбранных операций при определенных интенсивности выполнения этих операций.<br />-может производиться определение количества пользователей, одновременно работающих с приложением.<br /><br />4. Тестирование стабильности<br />Задачей тестирования стабильности является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие "утечек" памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-500875448382411604.post-51751123074872634902008-05-03T12:12:00.000-07:002008-12-01T13:08:16.424-08:00Терминология в нагрузочном тестированииЧтобы обсуждать подходы к нагрузочному тестированию и проблемы решаемые с его помощью, предлагаю начать с терминологии. Понимая под различными терминами одни и те же сущности можно говорить на "одном языке".<br /><br /><br />Итак. Нагрузочное тестирование - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком либо общем (разделяемом ими) ресурсе. В качестве примера можно привести работу сотрудников современного банка, в котором все работают с одними и теми же программными приложениями, установленными на банковских серверах. Или использование программного приложения веб магазин, в данном случае посетителями, нагружающими сервера, будут пользователи интернета.<br /><br /><br />Моделирование происходит с помощью специальных продуктов и техник. Что же, чем и как мы собираемся моделировать. Для того чтобы разобраться в этом и нужно определить терминологию:<br /><br /><br />1. Приложение - тестируемое прикладное программное обеспечение.<br />2. Виртуальный пользователь - программный процесс, циклически выполняющий моделируемые операции.<br />3. Итерация – это один повтор выполняемой в цикле операции.<br />4. Интенсивность выполнения операции - частота выполнения операции в единицу времени, в тестовом скрипте задается интервалом времени между итерациями.<br />5. Нагрузка - совокупное количество попыток выполнить операции на общем ресурсе. Создается или пользовательской (клиентской) активностью или нагрузочными скриптами.<br />6. Производительность - количество выполняемых приложением операций в единицу времени.<br />7. Масштабируемость приложения - пропорциональный рост производительности при увеличении нагрузки.<br />8. Профилем нагрузки называется набор операций с заданными интенсивностями, полученными на основе статистики.<br />9. Нагрузочной точкой называется расчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями.<br /><br /><br />Теперь порассуждаем как эти сущности связаны между собой. Выразив интенсивность через интервал времени между итерациями, видим что рост интенсивности моделируемых операций это сокращение интервала времени. Рост нагрузки пропорционален росту интенсивности. Естественно также, что при увеличении интенсивности растет производительность. При этом увеличивается степень использования (загруженности) ресурсов. С какого то момента рост производительности прекращается (а нагрузка может продолжать расти), происходит насыщение и затем деградация системы. В дополнение можно заметить что при тестировании изменение интенсивности операций может подчиняться какому либо закону (например, Пуассона) либо быть равномерным в течении всего теста.<br />(Раздел терминология может пополняться по мере наполнения блога материалами по теме)Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-500875448382411604.post-51830656350157242442008-05-01T01:25:00.000-07:002008-05-03T12:50:44.672-07:00ВступлениеВедение блога по нагрузочному тестированию - это желание поделиться своим мыслями и опытом в данной весьма интересной области. Первые сообщения будут посвящены соответственно первому этапу проведения нагрузочного тестирования а именно, разработке модели нагрузки тестируемого ПО, своеобразного ТЗ (техническое задание), которое будет являться в дальнейшем исходным документом для разработки тестовых скриптов и проведения самого тестирования.Unknownnoreply@blogger.com4