Bitka WEB serverov. Časť 2 – realistický scenár HTTPS:

O metodike sme hovorili v prvej časti článku, v tomto testujeme HTTPS, ale v realistickejších scenároch. Na testovanie bol získaný certifikát Let's Encrypt a zapnuto kompresiu Brotli na 11.

Tentoraz sa pokúsime reprodukovať scénar nasadenia servera na VDS alebo ako virtuálny stroj na hostingu s typickým procesorom. Na tento účel sme nastavili limit na:

• 25% — Čo v prepočte na frekvenciu ~ 1350 MHz
• 35% - 1890 MHz
• 41% — 2214 MHz
• 65% — 3510 MHz

Počet súčasných pripojení sa znížil zo 500 na 1, 3, 5, 7 a 9,

Výsledky:

Zdržanie:

TTFB bol osobitne vyčlenený ako samostatný test, pretože HTTPD Tools pre každý jednotlivý dotaz vytvára akoby nového používateľa. Tento test je stále dosť odtrhnutý od reality, pretože používateľ aj tak klikne na niekoľko stránok a v skutočnosti zohráva hlavnú úlohu TTFP.

Prvý, vlastne úplne prvý dotaz po prvom spustení virtuálneho stroja IIS sa spracúva v priemere za 120 ms.

Všetky ďalšie dotazy vykazujú TTFP 1,5 ms. Apache a Nginx zaostávajú. Osobne autor považuje tento test za najpuktívnejší a vyberal by víťaza len na jeho základe.
Výsledok nie je prekvapivý, pretože IIS cache-uje už komprimovaný statický obsah a nekomprimuje ho zakaždým, keď je naň odkazované.

Čas strávený na jedného klienta

Na hodnotenie výkonu stačí aj test s 1 súčasným pripojením.
Napríklad, IIS dokončil testovanie dlhého 5000 používateľov za 40 sekúnd, to je 123 dotazov za sekundu.

V grafoch nižšie je uvedený čas do úplného prenesenia obsahu stránky. Toto je podiel dotazov vykonaných v určitom čase. V našom prípade 80% všetkých dotazov bolo spracovaných za 8 ms na IIS a za 4,5 ms na Apache a Nginx, a interval do 8 milisekúnd bol splnený 98% všetkých dotazov na Apache a Nginx.

Čas, za ktorý bolo spracovaných 5000 dotazov:

Čas, za ktorý bolo spracovaných 5000 dotazov:

Ak máte virtuálny stroj s 3,5 GHz CPU a 8 jadrami, vyberte si to, čo chcete. Všetky webové servery sú veľmi podobné v tomto testovaní. O tom, aký webový server vybrať pre každý hosting budeme diskutovať nižšie.

Ak ide o trochu realistickejšiu situáciu, všetky webové servery idú nos do nosa.

Priepustnosť:

Graf zdržania v závislosti od počtu súčasných pripojení. Čím rovnejšie a nižšie – tým lepšie. Posledné 2% boli vyhodené z grafov, pretože by ich spravili nečitateľnými.

Teraz sa pozrieme na možnosť, kde je server umiestnený na virtuálnom hostingu. Berieme 4 jadrá po 2,2 GHz a jedno jadro na 1,8 GHz.

Ako sa škálujú

Ak ste niekedy videli, ako vyzerajú VAH elektrovakuové triody, pentódy a podobne, tieto grafy vám budú známe. Práve to sa snažíme vystihnúť – saturáciu. Hranicu, kedy akékoľvek množstvo jadier už nezaznamená žiadny rast výkonu.

Predtým bol celkový cieľ spracovať 98 % požiadaviek s minimálnou latenciou pre všetky požiadavky, pričom krivka by mala byť čo najvyrovnanejšia. Teraz s pomocou vytvorenia inej krivky nájdeme optimálny pracovný bod pre každý zo serverov.

Za týmto účelom vezmeme ukazovateľ Requests per second (RPR). Na vodorovnej osi je frekvencia, na zvislej osi – počet požiadaviek spracovaných za sekundu, čiary – počet jadier.

Zobrazuje sa korelácia, akým spôsobom Nginx spracováva požiadavky jednu po druhej. 8 jadier v takomto teste sa ukazuje lepšie.

Na tomto grafe je jasne vidieť, ako je Nginx na jednom jadre len trochu lepší. Ak používate Nginx, mali by ste zvážiť zníženie počtu jadier na jedno, ak hostíte len statiku.

IIS, hoci má najniší TTFB podľa DevTools v Chrome, sa v serióznej súťaži so stresovým testom od Apache Foundation ukazuje horšie než Nginx a Apache.

Celá krivosť grafov sa reprodukuje presne.

Dalo by sa povedať:

Áno, Apache jednoznačne pracuje horšie na 1 a 8 jadrách, na 4 však pracuje o niečo lepšie.

Áno, Nginx na 8 jadrách lepšie spracováva požiadavky jednu po druhej, na 1 a 4 jadrách a horšie funguje, ak je veľa pripojení.

Áno, IIS preferuje 4 jadrá pre viacvláknovú záťaž a preferuje 8 jadier pre jednovláknovú. Na konci sa ukázalo, že IIS bol trochu rýchlejší ako ostatné na 8 jadrách pri vysokej záťaži, hoci všetky servery boli na rovnakom leveli.

Toto nie je chyba merania, odchýlka tu nie je viac ako ±1 ms v latenciách a nie viac ako ±2-3 požiadavky za sekundu pre RPR.

Výsledky, keď sa 8 jadier prejavuje horšie, nie sú prekvapujúce, veľa jadier a SMT/Hyperthreading značne zhoršujú výkon, ak máme časové rámce, v ktorých musíme dokončiť celý pipeline.

Zdroj: habr.com