Në këtë artikull ne do të provojmë dorën tonë në inxhinierinë e kundërt, mund të thuhet. Ne do t'i fusim duart tona të pista nën kapuçin e secilit server në internet, duke i shfrytëzuar ato në mënyra që askush nuk do t'i shfrytëzonte kurrë.
Ky test është një matje e një kali sferik në një vakum, asgjë më shumë se të dhëna që janë marrë, dhe tani ne nuk dimë çfarë të bëjmë me të.
teknikë
Sistemi operativ për Nginx dhe Apache është Ubuntu 18.04 LTS, për IIS Windows Server Core 2019. Para testeve, të gjitha sistemet operative morën përditësimet më të fundit që nga 04.12.2019 dhjetori XNUMX.
Testet u kryen ekskluzivisht në HTTP. Secili ueb server drejtonte të njëjtën faqe, një shabllon falas Jekyll nga Codrops. . Çdo server në internet kishte kompresimin gzip të çaktivizuar.
Testi i xhiros është bërë me mjete Httpd me argumentet:
ab -n 50000 -c 500 http://192.168.76.204:80/Serverët ishin të kufizuar në 10, 5 dhe 1 përqind të bërthamës në 8, 4 dhe një bërthamë. Vendi i provës ishte një kompjuter me 9900K@5400MHz, që do të thotë se serveri që merr një kufi prej 10% merr rreth 540 MHz për bërthamë.
Testi TTFB u krye kur serveri fillimisht nisi dhe mati duke përdorur DevTools; pas marrjes së rezultatit, serveri u fiket dhe u kthye në pikën e mëparshme të kontrollit për të eliminuar shfaqjen e çdo lloji të memories.
Testuesi dhe serveri në internet ishin në të njëjtin host dhe në të njëjtin ndërprerës virtual.
Për të vlerësuar menjëherë nënsistemin e diskut, rezultatet e standardeve ATTO dhe CrystalDIskMark në mënyrë që të keni një ide për pengesat.
Të dhënat e marra nga makina virtuale:
Rezultatet:
TTFB:
TTFB mesatare për IIS është më e vogla, 0,5ms, kundrejt 1,4ms për Apache dhe 4ms për Nginx.
Xhiroja:
Së pari, le të shohim se sa mirë shkallëzohet secili server bazuar në numrin e bërthamave.
Grafiku tregon numrin e thirrjeve të testuesit në serverin e uebit dhe vonesën. Grafiku tregon se NGINX përpunoi 98% të të gjitha kërkesave, duke e dorëzuar faqen në 20 ms ose më pak. IIS, si Apache, përfundoi 5% të fundit të të gjitha thirrjeve në 76ms dhe 14ms, respektivisht.
Grafiku tregon kohën mesatare të përpunimit për një kërkesë gjatë një testi stresi.
Siç mund ta shihni nga grafikët, IIS shpërtheu si Apache ashtu edhe Nginx, duke u ngadalësuar ndjeshëm nën ngarkesë të lartë.
IIS preferoi qartë 4 bërthama mbi XNUMX, duke treguar vonesa më të ulëta në XNUMX, por gjithashtu nuk favorizonte fort një bërthamë.
NGINX shkallëzohet mirë në të 8 bërthamat, dhe për Apache, skenari me një bërthamë duket të jetë zgjidhja më e mirë.
Shkallëzueshmëria:
nginx:
Tani le të shohim shkallëzueshmërinë për sa i përket frekuencës dhe numrit të bërthamave.
Nginx nuk kaloi teste me një kufi prej 1% për 4 dhe 1 bërthama; kur tejkaloi 2000 kërkesa, ndërpreu lidhjen me testuesin.
Apache:
Apache, si Nginx, pasi kishte përpunuar 2500 kërkesa, hoqi dorë dhe mbylli lidhjen. Apache dështoi në testin në 8, 4 dhe 1 bërthama me një kufi prej 1%, por përveç kësaj dështoi edhe testin me një kufi prej 5% në një bërthamë, që është më keq se Nginx
IIS:
Gjatë testeve, IIS grumbulloi një radhë gjigante kërkesash, por përpunoi secilën prej tyre. Me sa duket, jashtë kutisë nuk ka afate të caktuara për përpunimin e kërkesave.
Grafiku tregon kohën e nevojshme për të përfunduar testin. Konfigurimet plotësisht absurde të testimit u hodhën poshtë. Diagrami tregon se sa kërkuese është IIS kur bëhet fjalë për harduerin dhe sa i mrekullueshëm është NGINX.
Shkallueshmëria nga disku:
nginx:
Tani le të shohim shkallëzueshmërinë për sa i përket frekuencës dhe numrit të bërthamave dhe shpejtësisë së diskut.
Këtë herë Nginx dështoi në 4 teste në vend të dy.
Apache:
Apache dështoi në të njëjtin numër testesh si herën e kaluar.
IIS:
IIS tregon një grafik pothuajse identik, sikur të mos kishte kufizime në disk. Në përgjithësi, grafika e të gjithë serverëve nuk ka ndryshuar shumë, që do të thotë se secili prej tyre ka ruajtur të dhënat statike në RAM dhe i ka shërbyer prej andej. Këtu shohim pengesën kryesore - vetë serverin në internet.
Është shumë herët për të nxjerrë përfundime bazuar në këtë testim; ne nuk kemi testuar ende HTTPS, kompresimin dhe HTTP/2 me një certifikatë të drejtpërdrejtë nga Let's Encrypt. Ne do të flasim për këtë në artikullin vijues.
Burimi: www.habr.com