Napag-usapan namin ang tungkol sa pamamaraan sa artikulo, sa isang ito sinubukan namin ang HTTPS, ngunit sa mas makatotohanang mga sitwasyon. Para sa pagsubok, nakakuha kami ng sertipiko ng Let's Encrypt at pinagana ang Brotli compression sa 11.
Sa pagkakataong ito susubukan naming kopyahin ang senaryo ng pag-deploy ng server sa isang VDS o bilang isang virtual machine sa isang host na may karaniwang processor. Para sa layuning ito, itinakda ang limitasyon sa:
- 25% - Na katumbas ng dalas ng ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Ang bilang ng isang beses na koneksyon ay nabawasan mula 500 hanggang 1, 3, 5, 7 at 9,
Mga resulta:
Mga pagkaantala:
Partikular na isinama ang TTFB bilang isang hiwalay na pagsubok, dahil ang HTTPD Tools ay gumagawa ng bagong user para sa bawat indibidwal na kahilingan. Ang pagsubok na ito ay medyo hiwalay pa rin sa realidad, dahil magki-click pa rin ang user ng ilang pahina, at sa totoo lang, TTFP ang gaganap sa pangunahing papel.
Ang una, sa pangkalahatan, ang pinakaunang kahilingan pagkatapos ng unang pagsisimula ng IIS virtual machine ay tumatagal sa average na 120 ms.
Ang lahat ng kasunod na kahilingan ay nagpapakita ng TTFP na 1.5 ms. Ang Apache at Nginx ay nahuhuli sa bagay na ito. Sa personal, isinasaalang-alang ng may-akda ang pagsusulit na ito na pinaka-nagsisiwalat at pipiliin lamang ang mananalo batay dito.
Ang resulta ay hindi nakakagulat dahil ang IIS cache ay naka-compress na ng static na nilalaman at hindi ito na-compress sa tuwing ito ay na-access.
Oras na ginugol sa bawat kliyente
Upang suriin ang pagganap, isang pagsubok na may 1 solong koneksyon ay sapat.
Halimbawa, nakumpleto ng IIS ang pagsubok ng 5000 user sa loob ng 40 segundo, na 123 kahilingan kada segundo.
Ipinapakita ng mga graph sa ibaba ang oras hanggang sa ganap na mailipat ang nilalaman ng site. Ito ang proporsyon ng mga kahilingang nakumpleto sa isang partikular na oras. Sa aming kaso, 80% ng lahat ng mga kahilingan ay naproseso sa 8ms sa IIS at sa 4.5ms sa Apache at Nginx, at 8% ng lahat ng mga kahilingan sa Apache at Nginx ay nakumpleto sa loob ng pagitan ng hanggang 98 millisecond.
Oras kung kailan naproseso ang 5000 kahilingan:
Oras kung kailan naproseso ang 5000 kahilingan:
Kung mayroon kang virtual machine na may 3.5GHz CPU at 8 core, pagkatapos ay piliin kung ano ang gusto mo. Ang lahat ng mga web server ay halos magkapareho sa pagsubok na ito. Pag-uusapan natin kung aling web server ang pipiliin para sa bawat host sa ibaba.
Pagdating sa isang bahagyang mas makatotohanang sitwasyon, ang lahat ng mga web server ay magkakaharap.
Throughput:
Graph ng mga pagkaantala kumpara sa bilang ng mga sabay-sabay na koneksyon. Mas makinis at mas mababa. Ang huling 2% ay inalis sa mga chart dahil gagawin nilang hindi nababasa ang mga ito.
Ngayon isaalang-alang natin ang opsyon kung saan naka-host ang server sa virtual hosting. Kumuha tayo ng 4 na core sa 2.2 GHz at isang core sa 1.8 GHz.
Paano mag-scale
Kung nakita mo na kung ano ang hitsura ng kasalukuyang-boltahe na mga katangian ng vacuum triodes, pentodes, at iba pa, magiging pamilyar sa iyo ang mga graph na ito. Ito ang sinusubukan nating hulihin - saturation. Ang limitasyon ay kapag kahit gaano karaming mga core ang itapon mo, ang pagtaas ng pagganap ay hindi kapansin-pansin.
Dati, ang buong hamon ay iproseso ang 98% ng mga kahilingan na may pinakamababang latency para sa lahat ng kahilingan, na pinapanatili ang curve bilang flat hangga't maaari. Ngayon, sa pamamagitan ng pagbuo ng isa pang curve, makikita natin ang pinakamainam na operating point para sa bawat isa sa mga server.
Para magawa ito, kunin natin ang indicator ng Requests per second (RPR). Ang pahalang ay ang dalas, ang patayo ay ang bilang ng mga kahilingang naproseso bawat segundo, ang mga linya ay ang bilang ng mga core.
Nagpapakita ng ugnayan ng kung gaano kahusay ang pagpoproseso ng Nginx sa bawat isa. 8 core ang gumaganap nang mas mahusay sa pagsubok na ito.
Malinaw na ipinapakita ng graph na ito kung gaano kahusay (hindi gaanong) gumagana ang Nginx sa isang core. Kung mayroon kang Nginx, dapat mong isaalang-alang na bawasan ang bilang ng mga core sa isa kung nagho-host ka lamang ng mga static.
Ang IIS, bagama't mayroon itong pinakamababang TTFB ayon sa DevTools sa Chrome, ay nagtagumpay sa parehong Nginx at Apache sa isang seryosong laban sa stress test mula sa Apache Foundation.
Ang lahat ng kurbada ng mga graph ay ginawang bakal.
Ilang uri ng konklusyon:
Oo, mas malala ang paggana ng Apache sa 1 at 8 na mga core, ngunit gumagana nang kaunti sa 4.
Oo, ang Nginx sa 8 core ay nagpoproseso ng mas mahusay na sunod-sunod, sa 1 at 4 na mga core, at mas gumagana kapag maraming koneksyon.
Oo, mas gusto ng IIS ang 4 na core para sa mga multi-threaded na workload at mas gusto ang 8 core para sa single-threaded na workload. Sa huli, ang IIS ay bahagyang mas mabilis kaysa sa lahat sa 8 core sa ilalim ng mataas na pagkarga, kahit na ang lahat ng mga server ay pare-pareho.
Hindi ito isang error sa pagsukat, ang error dito ay hindi hihigit sa +-1ms. sa mga pagkaantala at hindi hihigit sa +- 2-3 kahilingan kada segundo para sa RPR.
Hindi nakakagulat ang mga resulta kung saan mas malala ang performance ng 8 core, maraming mga core at SMT/Hyperthreading ang lubhang nagpapababa sa performance kung mayroon tayong time frame kung saan kailangan nating kumpletuhin ang buong pipeline.
Pinagmulan: www.habr.com