Hovorili sme o technike v V tomto článku testujeme HTTPS, ale v realistickejších scenároch. Na testovanie bol získaný certifikát Let’s Encrypt, kompresia Brotli bola povolená na 11.
Tentokrát sa pokúsime reprodukovať scenár nasadenia servera na VDS alebo ako virtuálny stroj na hostiteľovi so štandardným procesorom. Na tento účel bol stanovený limit:
- 25% - Čo zodpovedá frekvencii ~ 1350 MHz
- 35% -1890 MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Počet jednorazových spojení sa znížil z 500 na 1, 3, 5, 7 a 9,
výsledky:
Oneskorenia:
TTFB bol špecificky zahrnutý ako samostatný test, pretože HTTPD Tools vytvárajú nového používateľa pre každú jednotlivú požiadavku. Tento test je ešte dosť odtrhnutý od reality, pretože používateľ si aj tak preklikne pár stránok a v skutočnosti bude hrať hlavnú rolu TTFP.
Prvá, spravidla úplne prvá požiadavka po prvom spustení virtuálneho stroja IIS trvá v priemere 120 ms.
Všetky nasledujúce požiadavky ukazujú TTFP 1.5 ms. Apache a Nginx v tomto smere zaostávajú. Osobne považuje autor tento test za najvýraznejší a len na základe neho by vybral víťaza.
Výsledok nie je prekvapujúci, pretože IIS ukladá do vyrovnávacej pamäte už komprimovaný statický obsah a nekomprimuje ho pri každom prístupe.
Čas strávený na klienta
Na vyhodnotenie výkonu postačuje test s jedným pripojením.
Napríklad IIS dokončila test 5000 používateľov za 40 sekúnd, čo je 123 požiadaviek za sekundu.
Nižšie uvedené grafy zobrazujú čas do úplného prenesenia obsahu stránky. Toto je podiel žiadostí dokončených v danom čase. V našom prípade bolo 80 % všetkých požiadaviek spracovaných za 8 ms na IIS a za 4.5 ms na Apache a Nginx a 8 % všetkých požiadaviek na Apache a Nginx bolo dokončených v intervale do 98 milisekúnd.
Čas, počas ktorého bolo spracovaných 5000 žiadostí:
Čas, počas ktorého bolo spracovaných 5000 žiadostí:
Ak máte virtuálny stroj s 3.5 GHz CPU a 8 jadrami, vyberte si, čo chcete. Všetky webové servery sú v tomto testovaní veľmi podobné. O tom, ktorý webový server vybrať pre každého hostiteľa, si povieme nižšie.
Pokiaľ ide o trochu realistickejšiu situáciu, všetky webové servery si idú po krku.
priepustnosť:
Graf meškaní verzus počet súbežných spojov. Hladšie a nižšie je lepšie. Posledné 2 % boli z grafov odstránené, pretože by boli nečitateľné.
Teraz sa pozrime na možnosť, kde je server hosťovaný na virtuálnom hostingu. Zoberme si 4 jadrá na 2.2 GHz a jedno jadro na 1.8 GHz.
Ako škálovať
Ak ste niekedy videli, ako vyzerajú prúdovo-napäťové charakteristiky vákuových triód, pentód a podobne, tieto grafy vám budú známe. To sa snažíme zachytiť – saturáciu. Limit je, keď bez ohľadu na to, koľko jadier hodíte, zvýšenie výkonu nebude badateľné.
Predtým bolo hlavnou úlohou spracovať 98 % požiadaviek s najnižšou latenciou pre všetky požiadavky, pričom krivka bola čo najplochejšia. Teraz zostrojením ďalšej krivky nájdeme optimálny prevádzkový bod pre každý zo serverov.
Ak to chcete urobiť, vezmite si indikátor požiadaviek za sekundu (RPR). Horizontálne je frekvencia, vertikálne je počet spracovaných požiadaviek za sekundu, riadky sú počet jadier.
Ukazuje koreláciu toho, ako dobre Nginx spracováva požiadavky jeden po druhom. 8 jadier funguje v tomto teste lepšie.
Tento graf jasne ukazuje, o koľko lepšie (nie moc) funguje Nginx na jednom jadre. Ak máte Nginx, mali by ste zvážiť zníženie počtu jadier na jedno, ak hosťujete iba statické.
IIS, hoci má najnižšie TTFB podľa DevTools v Chrome, dokáže prehrať s Nginx aj Apache vo vážnom boji so záťažovým testom od Apache Foundation.
Všetky zakrivenia grafov sú reprodukované železom.
Nejaký záver:
Áno, Apache funguje horšie na 1 a 8 jadrách, ale funguje o niečo lepšie na 4.
Áno, Nginx na 8 jadrách spracováva požiadavky lepšie jednu po druhej, na 1 a 4 jadrách, a funguje horšie, keď je veľa pripojení.
Áno, IIS uprednostňuje 4 jadrá pre viacvláknové úlohy a uprednostňuje 8 jadier pre jednovláknové úlohy. V konečnom dôsledku bol IIS o niečo rýchlejší ako všetci ostatní na 8 jadrách pri vysokej záťaži, hoci všetky servery boli na rovnakej úrovni.
Toto nie je chyba merania, chyba tu nie je väčšia ako +-1 ms. v meškaniach a nie viac ako +- 2-3 požiadavky za sekundu pre RPR.
Výsledky, kde 8 jadier funguje horšie, nie sú vôbec prekvapujúce, veľa jadier a SMT/Hyperthreading výrazne zhoršuje výkon, ak máme časový rámec, v ktorom musíme dokončiť celý pipeline.
Zdroj: hab.com