Avemu parlatu di a metodulugia in articulu, in questu testemu HTTPS, ma in scenarii più realistichi. Per a prova, avemu ottenutu un certificatu Let's Encrypt è attivatu a compressione Brotli à 11.
Questa volta pruvaremu à ripruduce u scenariu di implementà un servitore in un VDS o cum'è una macchina virtuale in un host cù un processatore standard. Per questu scopu, un limite hè statu stabilitu à:
- 25% - Chì hè equivalente à una freccia di ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
U numeru di cunnessione una volta hè stata ridutta da 500 à 1, 3, 5, 7 è 9,
Risultati:
Ritardi:
TTFB hè statu specificamente inclusu cum'è una prova separata, perchè HTTPD Tools crea un novu utilizatore per ogni dumanda individuale. Sta prova hè sempre abbastanza staccata da a realità, perchè l'utilizatore hà sempre cliccà un paru di pagine, è in a realtà TTFP ghjucà u rolu principali.
U primu, in generale a prima dumanda dopu à u primu iniziu di a macchina virtuale IIS dura in media 120 ms.
Tutte e dumande successive mostranu un TTFP di 1.5 ms. Apache è Nginx sò in ritardu in questu sensu. In modu persunale, l'autore cunsidereghja sta prova u più revelatore è sceglie u vincitore solu basatu annantu à questu.
U risultatu ùn hè micca surprisante, postu chì IIS cache u cuntenutu staticu cumpressu digià è ùn cumpressa micca ogni volta chì hè accessu.
U tempu passatu per cliente
Per evaluà u rendiment, una prova cù 1 sola cunnessione hè abbastanza.
Per esempiu, IIS compie una prova di 5000 utilizatori in 40 seconde, chì hè 123 richieste per seconda.
I grafici sottu mostranu u tempu finu à chì u cuntenutu di u situ hè trasfirutu cumplettamente. Questa hè a proporzione di richieste cumpletate in un tempu determinatu. In u nostru casu, 80% di tutte e dumande sò stati processati in 8ms in IIS è in 4.5ms in Apache è Nginx, è u 8% di tutte e dumande nantu à Apache è Nginx sò stati cumpletati in un intervalu di finu à 98 millisecondi.
Tempu durante quale 5000 richieste sò state trattate:
Tempu durante quale 5000 richieste sò state trattate:
Se tenete una macchina virtuale cù un CPU 3.5GHz è 8 core, allora sceglite ciò chì vulete. Tutti i servitori web sò assai simili in questa prova. Parleremu di quale servitore web sceglite per ogni host quì sottu.
Quandu si tratta di una situazione un pocu più realistica, tutti i servitori web vanu in capu.
Trasmissione:
Graficu di ritardu versus u numeru di cunnessione simultanea. Smoother è più bassu hè megliu. L'ultimi 2% sò stati sguassati da i charts perchè li renderanu illegibili.
Avà cunsideremu l'opzione induve u servitore hè ospitatu in hosting virtuale. Pigliemu 4 core à 2.2 GHz è un core à 1.8 GHz.
Cumu scala
Sè vo avete mai vistu ciò chì e caratteristiche currenti-voltage di triodes vacuum, pentodes, è cusì, pare, sti gràfiche vi sarà familiar. Questu hè ciò chì pruvemu à catturà - a saturazione. U limitu hè quandu ùn importa quanti nuclei ti lanciate, l'aumentu di u rendiment ùn serà micca notu.
Nanzu, tutta a sfida era di processà u 98% di e dumande cù a latenza più bassa per tutte e dumande, mantenendu a curva quant'è piatta pussibule. Avà, custruendu una altra curva, truveremu u puntu di funziunamentu ottimali per ognunu di i servitori.
Per fà questu, pigliemu l'indicatore Requests per second (RPR). Orizzontale hè a frequenza, verticale hè u numeru di richieste processate per seconda, e linee sò u numeru di core.
Mostra una correlazione di quantu Nginx processa e richieste una dopu l'altru. 8 cores facenu megliu in questa prova.
Stu graficu mostra chjaramente quantu megliu (micca assai) Nginx travaglia nantu à un core unicu. Se tenete Nginx, duvete cunsiderà riduce u nùmeru di nuclei à unu si ospitu solu statichi.
IIS, ancu s'ellu hà u TTFB più bassu secondu DevTools in Chrome, riesce à perde à Nginx è Apache in una lotta seria cù a prova di stress da a Fundazione Apache.
Tutta a curvatura di i grafici hè ripruduciutu in ferru.
Qualchì tipu di cunclusione:
Iè, Apache funziona peghju nantu à 1 è 8 core, ma funziona un pocu megliu nantu à 4.
Iè, Nginx nantu à 8 core processa e dumande megliu unu dopu à l'altru, nantu à 1 è 4 core, è travaglia peghju quandu ci sò parechje cunnessione.
Iè, IIS preferisce 4 core per carichi di travagliu multi-threaded è preferisce 8 core per carichi di travagliu unicu. In ultimamente, IIS era ligeramente più veloce di tutti l'altri in core 8 sottu una carica alta, ancu s'ellu tutti i servitori eranu à par.
Questu ùn hè micca un errore di misurazione, l'errore quì ùn hè micca più di +-1ms. in ritardi è micca più di + - 2-3 richieste per seconda per RPR.
I risultati induve i nuclei 8 facenu peggiu ùn sò micca sorprendenti, assai nuclei è SMT / Hyperthreading degradanu assai u rendiment si avemu un marcu di tempu in quale avemu da compie u pipeline tutale.
Source: www.habr.com