Në këtë artikull, do të përpiqemi të bëjmë inxhinieri të kundërt, si të thuash. Do të fusim duart tona në thelbin e secilit server web, duke i shfrytëzuar ato në mënyra që askush tjetër nuk do t'i shfrytëzonte kurrë.
Ky test është një matje e një kali sferik në vakum, asgjë më shumë se të dhënat që u morën, dhe tani nuk dimë çfarë të bëjmë me to.
teknikë
Sistemi operativ për Nginx dhe Apache është Ubuntu 18.04 LTS, për IIS Windows Server Core 2019. Të gjitha sistemet operative morën përditësimet më të fundit që nga 4 dhjetori 2019, para testimit.
Testet u kryen ekskluzivisht nĂ«pĂ«rmjet HTTP. Ădo server web ekzekutonte tĂ« njĂ«jtĂ«n faqe, njĂ« shabllon falas Jekyll nga Codrops. Kompresimi Gzip u çaktivizua nĂ« secilin prej serverave tĂ« internetit.
Testi i xhiros u krye me Httpd-tools me argumentet e mëposhtme:
ab -n 50000 -c 500 http://192.168.76.204:80/Serverat ishin të kufizuar në 10, 5 dhe 1 përqind të bërthamës në 8, 4 dhe 1 bërthamë. Tabela e testimit ishte një kompjuter me 9900K @ 5400 MHz, që do të thotë se një server me një limit prej 10% merr afërsisht 540 MHz për bërthamë.
Testi TTFB u krye gjatë nisjes së parë të serverit dhe u mat duke përdorur DevTools. Pas marrjes së rezultateve, serveri u mbyll dhe u rikthye në pikën e kontrollit të mëparshme për të eliminuar çdo memorje të përkohshme.
Testuesi dhe serveri web ishin të vendosur në të njëjtin host dhe në të njëjtin switch virtual.
Për të vlerësuar menjëherë nënsistemin e diskut, rezultatet e standardeve ATTO dhe CrystalDIskMark përdoren për të marrë një ide mbi pengesat.
TĂ« dhĂ«nat e marra nga makina virtuale:



Rezultatet:
TTFB:

IIS ka TTFB mesataren më të ulët, 0,5 ms, krahasuar me 1,4 ms për Apache dhe 4 ms për Nginx.
Xhiroja:
Së pari, le të shohim se sa mirë shkallëzohet secili server për sa i përket numrit të bërthamave.

Grafiku tregon numrin e kërkesave që testuesi i bëri serverit të internetit dhe vonesën. Ai tregon se NGINX trajtoi 98% të të gjitha kërkesave, duke e dorëzuar faqen në 20ms ose më pak. IIS dhe Apache trajtuan 5% të fundit të të gjitha kërkesave në 76ms dhe 14ms, përkatësisht.



Grafiku tregon kohën mesatare të përpunimit të një kërkese gjatë një testi stresi.
Siç mund ta shihni nga grafikët, IIS pati performancë më të mirë se Apache dhe Nginx, duke u ngadalësuar ndjeshëm nën ngarkesë të lartë.
IIS preferonte qartë 4 bërthama mbi 8, duke treguar vonesa më të ulëta në 4, por nuk favorizonte shumë as 1 bërthamë.
NGINX shkallëzohet mirë në të 8 bërthamat, ndërsa për Apache, skenari me një bërthamë të vetme duket të jetë zgjidhja më e mirë.
Shkallëzueshmëria:
nginx:
Tani le të shohim shkallëzueshmërinë sipas frekuencës dhe numrit të bërthamave.

Nginx dështoi në testet me një limit prej 1% në 4 dhe 1 bërthamë; kur tejkaloi 2000 kërkesa, ndërpreu lidhjen me testuesin.
Apache:

Apache, ashtu si Nginx, hoqi dorë dhe e ndërpreu lidhjen pasi përpunoi 2500 kërkesa. Apache dështoi në testet në 8, 4 dhe 1 bërthamë me një limit prej 1%, por dështoi gjithashtu në testin me një limit prej 5% në një bërthamë të vetme, 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, nuk ka asnjë afat kohor për përpunimin e kërkesave të caktuar që në fillim.

Diagrama tregon kohën që u desh për të përfunduar testin. Konfigurimet më absurde të testimit u hodhën poshtë. Diagrama tregon se sa i kërkuar është IIS në harduer dhe sa i mrekullueshëm është NGINX.
Shkallëzueshmëria e diskut:
nginx:
Tani le të shohim shkallëzueshmërinë në aspektin e frekuencës, 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 fundit.
IIS:

IIS tregon një grafik pothuajse identik, sikur të mos kishte kufizime në disk. Në përgjithësi, grafikët për të gjithë serverët nuk kanë ndryshuar shumë, që do të thotë se secili prej tyre ruante skedarët statikë në RAM dhe i shërbente prej andej. Këtu shohim pengesën kryesore - vetë serverin web.
ĂshtĂ« shumĂ« herĂ«t pĂ«r tĂ« nxjerrĂ« pĂ«rfundime nga ky testim; ne ende nuk e kemi testuar HTTPS-in, kompresimin dhe HTTP/2 me njĂ« certifikatĂ« aktive Let's Encrypt. Do ta trajtojmĂ« kĂ«tĂ« nĂ« artikullin tjetĂ«r.
Burimi: www.habr.com
