Съвети за JMeter

JMeter е популярен инструмент с отворен код за тестване на натоварване, с много полезни функции за моделиране като група нишки, таймер и елементи на HTTP семплер. Тази статия допълва ръководството за потребителя на JMeter и предоставя насоки за използване на някои от елементите за моделиране на JMeter за разработване на скрипт за тестване на качеството.

Тази статия разглежда и важен въпрос в по-широк контекст: определяне на точни изисквания за време за реакция и валидиране на резултатите от теста. По-конкретно се прилага строг статистически метод, анализ на доверителния интервал.

Моля, обърнете внимание, че предполагам, че читателите познават основите на JMeter. Примерите в тази статия се основават на JMeter 2.0.3.

Определете периода на нарастване на група нишки

Първата съставка във вашия JMeter скрипт е група от нишки, така че нека първо я прегледаме. Както е показано на фигура 1, елементът Thread Group съдържа следните параметри:

  • Брой нишки.
  • Периодът на нарастване.
  • Броят пъти за изпълнение на теста.
  • При стартиране, дали тестът се изпълнява незабавно или изчаква до планираното време. Ако това е последното, елементът Thread Group трябва също да включва началния и крайния час.

Всяка нишка изпълнява тестовия план независимо от другите нишки. Следователно група нишки се използва за моделиране на едновременни потребители. Ако клиентската машина, работеща с JMeter, няма достатъчно изчислителна мощност, за да моделира тежък товар, функцията за дистрибутивно тестване на JMeter ви позволява да контролирате множество отдалечени JMeter двигатели от една конзола на JMeter.

Периодът на нарастване казва на JMeter количеството време за създаване на общия брой нишки. Стойността по подразбиране е 0. Ако периодът на нарастване не е посочен, т.е. периодът на нарастване е нула, JMeter ще създаде всички нишки веднага. Ако периодът на нарастване е зададен на T секунди и общият брой нишки е N, JMeter ще създава нишка на всеки T / N секунди.

Повечето параметри на група нишки се обясняват, но периодът на нарастване е малко странен, тъй като подходящият брой не винаги е очевиден. Първо, периодът на нарастване не трябва да е нула, ако имате голям брой нишки. В началото на теста за натоварване, ако периодът на нарастване е нула, JMeter ще създаде всички нишки наведнъж и ще изпрати незабавно заявки, като по този начин потенциално ще насити сървъра и, което е по-важно, измамно ще увеличи товара. Тоест, сървърът може да се претовари не защото средната честота на посещения е висока, а защото изпращате едновременно всички заявки на всички нишки, причинявайки необичайна първоначална скорост на връх. Можете да видите този ефект с JMeter Aggregate Report listener.

Тъй като тази аномалия не е желателна, следователно основното правило за определяне на разумен период на нарастване е да се поддържа първоначалната скорост на удара близо до средната честота на удари. Разбира се, може да се наложи да стартирате тестовия план веднъж, преди да откриете разумен брой.

По същия начин големият период на нарастване също не е подходящ, тъй като върховото натоварване може да бъде подценено. Тоест, някои от нишките може дори да не са стартирали, докато някои първоначални нишки вече са прекратени.

И така, как да проверите дали периодът на нарастване не е нито твърде малък, нито твърде голям? Първо отгатнете средната честота на удари и след това изчислете началния период на нарастване, като разделите броя нишки на предположената честота на удари. Например, ако броят на нишките е 100, а прогнозната честота на ударите е 10 посещения в секунда, прогнозният идеален период на нарастване е 100/10 = 10 секунди. Как се изчислява прогнозната честота на посещенията? Няма лесен начин. Просто трябва първо да стартирате тестовия скрипт веднъж.

Второ, добавете слушател на обобщен отчет, показан на фигура 2, към плана за тестване; тя съдържа средната честота на посещенията на всяка отделна заявка (проби JMeter). Скоростта на посещаемост на първия дискретизатор (например HTTP заявка) е тясно свързана с периода на нарастване и броя нишки. Регулирайте периода на нарастване, така че честотата на ударите на първия пробовземач на плана за изпитване да е близка до средната честота на удари на всички останали проби.

Трето, проверете в регистрационния файл на JMeter (намиращ се в JMeter_Home_Directory / bin), че първата нишка, която завършва, наистина завършва след стартирането на последната нишка. Разликата във времето между двете трябва да бъде възможно най-далеч.

В обобщение, определянето на добро време за нарастване се урежда от следните две правила:

  • Честотата на ударите на първия пробовземач трябва да бъде близка до средната честота на ударения на други пробовземачи, като по този начин се предотвратява малък период на нарастване
  • Първата нишка, която завършва, наистина завършва след стартирането на последната нишка, за предпочитане възможно най-отдалечена, като по този начин предотвратява голям период на нарастване

Понякога двете правила си противоречат. Тоест, просто не можете да намерите подходящ период на нарастване, който да спазва и двете правила. Тривиален план за тестване обикновено причинява този проблем, тъй като в такъв план ви липсват достатъчно семплери за всяка нишка; по този начин планът на теста е твърде кратък и нишката бързо завършва работата си.

Потребителят мисли време, таймер и прокси сървър

Важен елемент, който трябва да се вземе предвид при тест за зареждане, е времето за обмисляне или паузата между последователните заявки. Различни обстоятелства причиняват закъснението: потребителят се нуждае от време, за да прочете съдържанието, или да попълни формуляр, или да потърси правилната връзка. Липсата на правилно съображение с времето за мислене често води до сериозно пристрастни резултати от теста. Например, очакваната мащабируемост, т.е. максималното натоварване (едновременни потребители), което системата може да поддържа, ще изглежда ниска.

JMeter предоставя набор от таймерни елементи за моделиране на времето за мислене, но все още остава въпрос: как да определите подходящо време за мислене? За щастие JMeter предлага добър отговор: елементът JMeter HTTP Proxy Server.

Прокси сървърът записва вашите действия, докато сърфирате в уеб приложение с нормален браузър (като FireFox или Internet Explorer). В допълнение, JMeter създава план за тестване, когато записва вашите действия. Тази функция е изключително удобна за няколко цели:

  • Не е необходимо ръчно да създавате HTTP заявка, особено тези досадни параметри на формата. (Обаче параметрите, които не са на английски език, може да не работят правилно.) JMeter ще запише всичко в автоматично генерираните заявки, включително скритите полета.
  • В генерирания тестов план JMeter включва всички генерирани от браузъра HTTP заглавки за вас, като User-Agent (например Mozilla / 4.0) или AcceptLanguage (напр. Zh-tw, en-us; q = 0.7, zh- cn; q = 0,3).
  • JMeter може да създаде таймери по ваш избор, където времето за забавяне се задава според действителното забавяне по време на периода на запис.

Нека да видим как да конфигурираме JMeter с функцията за запис. В конзолата на JMeter щракнете с десния бутон върху елемента WorkBench и добавете елемента HTTP Proxy Server. Обърнете внимание, че щракнете с десния бутон върху елемента WorkBench, а не върху елемента Test Plan, тъй като конфигурацията тук е за запис, а не за изпълним план за тестване. Целта на елемента HTTP Proxy Server е да конфигурирате прокси сървъра на браузъра, така че всички заявки да преминават през JMeter.

Както е илюстрирано на фигура 3, няколко елемента трябва да бъдат конфигурирани за елемента HTTP прокси сървър:

  • Порт: Портът за слушане, използван от прокси сървъра.
  • Целеви контролер: Контролерът, където проксито съхранява генерираните проби. По подразбиране JMeter ще търси контролер за запис в текущия план за тестване и ще съхранява пробите там. Като алтернатива можете да изберете всеки елемент на контролера, изброен в менюто. Обикновено по подразбиране е добре.
  • Групиране: Как искате да групирате генерираните елементи в тестовия план. Налични са няколко опции и най-разумната е може би „Съхраняване на 1-ви семплер от всяка група“, в противен случай URL адресите, вградени в страница, като тези за изображения и JavaScripts, също ще бъдат записани. Въпреки това, може да искате да изпробвате опцията по подразбиране "Не групирай проби", за да разберете какво точно JMeter създава за вас в плана за тестване.
  • Модели за включване и Модели за изключване: Помага ви да филтрирате някои нежелани заявки.

Когато щракнете върху бутона Старт, прокси сървърът стартира и започва да записва получените HTTP заявки. Разбира се, преди да щракнете върху Старт, трябва да конфигурирате настройката за прокси сървър на браузъра си.

Можете да добавите таймер като дъщерен елемент на HTTP прокси сървъра, който ще инструктира JMeter да добави автоматично таймер като дъщерна част на HTTP заявката, която генерира. JMeter автоматично съхранява действителното закъснение към JMeter променлива, наречена T, така че ако добавите гауссов случаен таймер към елемента HTTP Proxy Server, трябва да въведете $ {T} в полето Constant Delay, както е показано на фигура 4. Това е друга удобна функция, която ви спестява много време.

Имайте предвид, че таймерът води до забавяне на засегнатите семплери. Тоест, засегнатите заявки за вземане на проби не се изпращат преди да изтече определеното време за забавяне от последния получен отговор. Следователно трябва да премахнете ръчно генерирания таймер на първия семплер, тъй като първият семплер обикновено не се нуждае от такъв.

Преди да стартирате HTTP прокси сървъра, трябва да добавите група нишки към тестовия план и след това към групата нишки да добавите контролер за запис, където генерираните елементи ще се съхраняват. В противен случай тези елементи ще бъдат добавени директно към WorkBench. Освен това е важно да добавите елемент за настройка по подразбиране на HTTP (елемент за конфигуриране) към контролера за запис, така че JMeter да остави празни тези полета, посочени по подразбиране на HTTP заявката.

След записа спрете HTTP прокси сървъра; щракнете с десния бутон на мишката върху елемента Контролер на запис, за да запишете записаните елементи в отделен файл, за да можете да ги извлечете по-късно. Не забравяйте да възобновите настройките за прокси сървър на браузъра си.

Посочете изискванията за време за реакция и потвърдете резултатите от теста

Въпреки че не е пряко свързано с JMeter, посочването на изискванията за време за реакция и валидирането на резултатите от теста са две критични задачи за тестване на натоварването, като JMeter е мостът, който ги свързва.

В контекста на уеб приложенията времето за реакция се отнася до времето, изминало между подаването на заявка и получаването на получения HTML. Технически, времето за реакция трябва да включва време, за да може браузърът да изобрази HTML страницата, но браузърът обикновено показва страницата парче по парче, което прави възприеманото време за реакция по-малко. В допълнение, обикновено инструмент за тестване на натоварване изчислява времето за реакция, без да се взема предвид времето за изобразяване. Следователно, за практически цели на тестването на ефективността, ние приемаме определението, описано по-горе. Ако се съмнявате, добавете константа към измереното време за реакция, да речем 0,5 секунди.

Има набор от добре познати правила за определяне на критериите за време за реакция:

  • Потребителите не забелязват забавяне по-малко от 0,1 секунди
  • Закъснение по-малко от 1 секунда не прекъсва мисловния поток на потребителя, но се забелязва известно забавяне
  • Потребителите все още ще чакат отговора, ако той се забави с по-малко от 10 секунди
  • След 10 секунди потребителите губят фокус и започват да правят нещо друго

Тези прагове са добре известни и няма да се променят, тъй като те са пряко свързани с когнитивните характеристики на хората. Въпреки че трябва да зададете вашите изисквания за време за реакция в съответствие с тези правила, вие също трябва да ги коригирате за вашето конкретно приложение. Например началната страница на Amazon.com спазва горните правила, но тъй като предпочита по-стилистичен външен вид, тя жертва малко време за реакция.

На пръв поглед изглежда, че има два различни начина за определяне на изискванията за време за реакция:

  • Средно време за реакция
  • Абсолютно време за реакция; т.е. времето за реакция на всички отговори трябва да бъде под прага

Посочването на средните изисквания за време за реакция е лесно, но фактът, че това изискване не отчита вариацията на данните, е обезпокоителен. Ами ако времето за реакция на 20 процента от пробите е повече от три пъти средното? Имайте предвид, че JMeter изчислява средното време за реакция, както и стандартното отклонение за вас в слушателя Graph Results.

От друга страна, изискването за абсолютно време за реакция е доста строго и статистически не е практично. Ами ако само 0,5 процента от пробите не са успели да преминат тестовете? Отново, това е свързано с вариацията на извадката. За щастие, строгият статистически метод разглежда вариацията на извадката: анализ на доверителния интервал.

Нека да разгледаме основните статистически данни, преди да продължим по-нататък.

Теорема за централната граница

Теоремата за централната граница гласи, че ако разпределението на популацията има средно μ и стандартно отклонение σ, тогава при достатъчно голямо n (> 30) разпределението на пробите на средното за вземане на проби е приблизително нормално, със средно μ средно = μ и стандартно отклонение σ средно = σ / √n.

Обърнете внимание, че разпределението на средната стойност за вземане на проби е нормално. Разпределението на самата проба не е непременно нормално. Тоест, ако стартирате тестовия си скрипт много пъти, разпределението на полученото средно време за реакция ще бъде нормално.

Фигури 5 и 6 по-долу показват две нормални разпределения. В нашия контекст хоризонталната ос е средното за вземане на проби от времето за реакция, изместено, така че средното за популацията е в началото. Фигура 5 показва, че 90 процента от времето средствата за вземане на проби са в интервала ± Zσ, където Z = 1.645 и σ е стандартното отклонение. Фигура 6 показва 99-процентния случай, където Z = 2,576. За дадена вероятност, да речем 90 процента, можем да търсим съответната стойност Z с нормална крива и обратно.