ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 20
Abonament PDF

Cum să (nu) măsurăm latenţa

Attila-Mihaly Balazs
Software Panther @ Synapp.io



PROGRAMARE

Latenţa este definită ca "intervalul de timp între stimul şi răspuns" şi este o valoare care ne interesează în multe sisteme de calcul (financiare, jocuri, site-uri web, etc.). În calitate de ingineri ne interesează crearea unui model matematic din care să rezulte valorile minime/maxime/tipice care pot să apară în sistemul nostru (fie el un site web sau un sistem de tranzacţionare automată pe burse).

Cum putem construi un astfel de model? Pentru sisteme simple (embedded) putem să calculăm direct ciclurile de procesor necesare pentru executarea programului. Dar pentru programe tipice există prea mulţi factori ca să putem aplica metoda directă (sistemul de operare, alte procese care rulează concomitent, JIT-ul, GC-ul, etc.). Alternativa pe care o avem este să executăm teste empirice şi să construim modelul pe baza rezultatelor obţinute.

În cazul acesta trebuie să ţinem cont de câteva reguli ca să obţinem un rezultat corect:

Folosirea percentilelor

Să presupunem că testăm un site web care rulează în Tomcat. Folosind JMeter rulăm un test de încărcare (load test) şi obţinem valoarea medie a lanteţei şi dispersia (standard deviation). Având aceste valori concluzionăm că 99.73% dintre utilizatori vor observa o lanteţă care se încadrează în intervalul medie +-3*dispersie. Suntem încrezători în rezultat pentru că:

Şi totuşi rezultatul ar fi greşit (ceea ce poate să aibă consecinţe monetare grave dacă valorile respective se includ în contracte).

De unde provine problema? Să considerăm un exemplu concret: presupunem (pentru simplitate) că am executat 100 de teste şi valorile de latenţă măsurate au fost următoarele (valorile numerice pot fi accesate aici pentru verificarea calculelor):

Imediat putem observa că valorile se pot clasifica în trei categorii:

O astfel de distribuţie este tipică pentru sisteme medii spre mari din viaţa reală care sunt compuse din multe părţi (gen N-tier architecture) şi se numeşte distribuţie multimodală. Vedem imediat de ce este important acest lucru.

Folosind LibreOffice Calc (sau Excel, după gust) putem calcula rapid că media acestor valori este 40 şi conform regulii trei sigma, 99.73% din utilizatori ar trebui să observe latenţe mai mici de 137. Dacă studiem diagrama observăm că media se află spre partea stângă (nu în centru cum ne-am aştepta) şi percentila 99 este 148, nu 137 cum am calculat. Poate că diferenţa nu pare mare, dar dacă am scris un contract pe baza acestor valori, poate să însemne diferenţa între profit şi pierdere.

Unde am greşit? Să citim încă o dată atent regula trei sigma: "o variabilă normal repartizată ia valori semnificative numai în intervalul (μ-3σ, μ+3σ)".

Problema noastră este că nu avem o distribuţie normală (gaussiană) ci o distribuţie multimodală cum am văzut mai devreme. O metodă pentru evitarea acestor probleme este folosirea modelelor matematice care nu depind de natura distribuţiei.

Evitarea omisiunii coordonate

Omisiunea coordonată (coordinated omission) este o expresie inventată de Gil Tene de la Azul Systems (un JVM alternativ care nu necesită oprirea programelor în timpul GC-ului). Omisiunea coordonată apare dacă programul de test arată în felul următor:

start:
t = time()
do_request()
record_time(time() - t)
wait_until_next_second()
jump start

Cu acest program de test încercăm să trimitem o cerere la fiecare secundă şi să măsurăm latenţa (aceeaşi problemă apare cu orice interval fix de trimitere - de exemplu 100ms - folosim o secundă aici pentru simplitate). Multe programe de test au o astfel de implementare.

Să presupunem că rulăm testul şi (învăţând din greşelile anterioare) raportăm că 85% din cereri vor fi satisfăcute sub 0.5 secunde dacă există o cerere pe secundă. Şi modelul nostru tot greşit ar fi. Să analizăm graficul de mai jos, pentru a stabili cauza:

Pe prima linie avem cererile în timpul testului. Între secunda 3 şi 6 sistemul este blocat (de exemplu din cauza unei pauze de GC). Dacă calculăm percentila 85 din cererile de test vom obţine 0.5.

În schimb dacă avem 10 clienţi independenţi (situaţia pe care încercăm să o simulăm cu testul) valoarea 85% a latenţei va fi 1.5 secunde (de trei or mai mare decât ne-a estimat modelul!).

De unde apare discrepanţa? Problema este că programul de testare şi sistemul testat au colaborat (prin faptul că primul a aşteptat după al doilea cât timp acesta era blocat) ca să ascundă cererile potenţiale care puteau să apară în timp ce serverul era blocat. Așadar, după cum se poate vedea din exemplu, acest lucru duce la subestimarea latenţei.

Concluzie

Din problemele discutate anterior putem să distilăm câteva recomandări care să ne ajute în crearea modelelor robuste:

  1. Să ne asigurăm că nu ne limitează utilitarul de testare - să-l rulăm contra unui URL care nu face nimic de exemplu şi să verificăm că putem să generăm numărul de accesări pe secundă dorită;
  2. Să considerăm particularităţile sistemului - să folosim hardware identic cu cel de producţie, să lăsăm să se "încălzească" (warm up) dacă e vorba de un sistem JIT-ed (JVM, .NET, LuaJIT, etc.);
  3. Să folosim percentile. Când discutăm rezultatele să folosim fraze de genul "50% din vizitatori vor observa o latenţă sub…" sau "99.99% din vizitatori vor observa o latenţă sub…" sau chiar "latenţa maximă este…"
  4. Să nu calculăm media. Să nu folosim dispersia (standard deviation). Dacă vedem astfel de valori, să presupunem că cei care au generat raportul nu ştiu despre ce vorbesc sau vor să ne inducă în eroare în mod intenţionat;
  5. Să ne asigurăm că fiecare cerere a durat mai puţin decât intervalul de probare (sampling) sau să folosim o unealtă de testare care nu suferă de această problemă sau să folosim o librărie precum HdrHistogram de la Gil Tene care poate să corecteze ulterior rezultatele.

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Colors in projects