Naghisgot kami bahin sa teknik sa nga artikulo, niining usa atong gisulayan ang HTTPS, apan sa mas realistiko nga mga senaryo. Alang sa pagsulay, nakuha ang usa ka sertipiko sa Let's Encrypt, gipaandar ang Brotli compression sa 11.
Niining higayona sulayan namon nga kopyahon ang senaryo sa pag-deploy sa usa ka server sa usa ka VDS o ingon usa ka virtual machine sa usa ka host nga adunay usa ka standard nga processor. Alang niini nga katuyoan, usa ka limitasyon ang gitakda sa:
- 25% - Nga katumbas sa frequency sa ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Ang gidaghanon sa usa ka higayon nga mga koneksyon gikunhoran gikan sa 500 ngadto sa 1, 3, 5, 7 ug 9,
Resulta:
Mga paglangan:
Ang TTFB espesipikong gilakip isip usa ka bulag nga pagsulay, tungod kay ang HTTPD Tools nagmugna og bag-ong user alang sa matag indibidwal nga hangyo. Kini nga pagsulay medyo nahilayo sa reyalidad, tungod kay ang tiggamit mag-klik gihapon sa usa ka magtiayon nga mga panid, ug sa tinuud ang TTFP ang magdula sa panguna nga papel.
Ang una, kasagaran ang labing una nga hangyo pagkahuman sa una nga pagsugod sa virtual nga makina sa IIS mokuha sa aberids nga 120 ms.
Ang tanan nga nagsunod nga mga hangyo nagpakita sa usa ka TTFP nga 1.5 ms. Ang Apache ug Nginx naulahi niining bahina. Sa personal, gikonsiderar sa tagsulat kini nga pagsulay nga labing gipadayag ug pilion ang mananaog base lamang niini.
Ang resulta dili ikatingala tungod kay ang IIS nga mga cache naka-compress na sa static nga sulod ug dili kini ma-compress sa matag higayon nga kini ma-access.
Panahon nga gigahin matag kliyente
Aron masusi ang pasundayag, igo na ang usa ka pagsulay nga adunay 1 ka koneksyon.
Pananglitan, nakompleto sa IIS ang usa ka pagsulay sa 5000 nga mga tiggamit sa 40 segundos, nga mao ang 123 nga mga hangyo matag segundo.
Ang mga graph sa ubos nagpakita sa oras hangtod ang sulud sa site hingpit nga mabalhin. Kini ang proporsyon sa mga hangyo nga nahuman sa usa ka gihatag nga oras. Sa among kaso, 80% sa tanan nga mga hangyo giproseso sa 8ms sa IIS ug sa 4.5ms sa Apache ug Nginx, ug 8% sa tanan nga mga hangyo sa Apache ug Nginx nahuman sulod sa usa ka interval nga hangtod sa 98 milliseconds.
Panahon diin ang 5000 nga mga hangyo giproseso:
Panahon diin ang 5000 nga mga hangyo giproseso:
Kung ikaw adunay usa ka virtual nga makina nga adunay 3.5GHz nga CPU ug 8 ka mga core, unya pilia kung unsa ang imong gusto. Ang tanan nga mga web server parehas kaayo sa kini nga pagsulay. Maghisgot kami kung unsang web server ang pilion alang sa matag host sa ubos.
Kung bahin sa usa ka gamay nga mas realistiko nga sitwasyon, ang tanan nga mga web server moadto sa ulo sa ulo.
Pinaagi sa:
Graph sa mga paglangan kumpara sa gidaghanon sa dungan nga mga koneksyon. Mas hapsay ug ubos ang mas maayo. Ang katapusan nga 2% gikuha gikan sa mga tsart tungod kay sila maghimo niini nga dili mabasa.
Karon atong tagdon ang kapilian diin ang server gi-host sa virtual hosting. Atong kuhaon ang 4 ka core sa 2.2 GHz ug usa ka core sa 1.8 GHz.
Unsaon pag-scale
Kung nakita nimo kung unsa ang hitsura sa karon nga boltahe nga mga kinaiya sa mga vacuum triodes, pentodes, ug uban pa, kini nga mga graph pamilyar kanimo. Mao kini ang atong gipaningkamutan nga makuha - saturation. Ang limitasyon mao kung bisan pila ka mga core ang imong ihulog, ang pagtaas sa pasundayag dili mamatikdan.
Kaniadto, ang tibuuk nga hagit mao ang pagproseso sa 98% sa mga hangyo nga adunay labing ubos nga latency alang sa tanan nga mga hangyo, nga gipadayon ang kurba nga patag kutob sa mahimo. Karon, pinaagi sa pagtukod og lain nga kurba, atong makit-an ang kamalaumon nga operating point alang sa matag usa sa mga server.
Sa pagbuhat niini, atong kuhaon ang Requests per second (RPR) indicator. Ang pinahigda mao ang frequency, ang bertikal mao ang gidaghanon sa mga hangyo nga giproseso kada segundo, ang mga linya mao ang gidaghanon sa mga cores.
Nagpakita usa ka correlation kung unsa ka maayo ang mga proseso sa Nginx nga gihangyo sa usag usa. Ang 8 ka mga core mas maayo nga nahimo sa kini nga pagsulay.
Kini nga graph tin-aw nga nagpakita kung unsa ka mas maayo (dili daghan) ang Nginx nga nagtrabaho sa usa ka core. Kung ikaw adunay Nginx, kinahanglan nimong hunahunaon ang pagkunhod sa gidaghanon sa mga cores sa usa kung nag-host ka lamang sa mga static.
Ang IIS, bisan kung kini adunay labing ubos nga TTFB sumala sa DevTools sa Chrome, nakahimo nga mapildi sa Nginx ug Apache sa usa ka seryoso nga away sa pagsulay sa stress gikan sa Apache Foundation.
Ang tanan nga curvature sa mga graph giprodyus sa puthaw nga panapton.
Usa ka matang sa konklusyon:
Oo, ang Apache nagtrabaho nga mas grabe sa 1 ug 8 nga mga cores, apan mas maayo ang pagtrabaho sa 4.
Oo, ang Nginx sa 8 nga mga core nagproseso nga mas maayo nga sunod-sunod, sa 1 ug 4 nga mga core, ug mas grabe kung adunay daghang mga koneksyon.
Oo, gipalabi sa IIS ang 4 nga mga cores alang sa multi-threaded workloads ug gipalabi ang 8 nga mga cores alang sa single-threaded nga mga workloads. Sa katapusan, ang IIS mas paspas kay sa tanan sa 8 ka mga core ubos sa taas nga load, bisan kung ang tanan nga mga server parehas.
Dili kini usa ka sayup sa pagsukod, ang sayup dinhi dili molapas sa +-1ms. sa mga paglangan ug dili mosobra sa +- 2-3 nga mga hangyo kada segundo para sa RPR.
Ang mga resulta diin ang 8 nga mga cores naghimo sa mas grabe nga dili kaayo katingad-an, daghang mga cores ug SMT/Hyperthreading ang nakadaot pag-ayo sa performance kung kita adunay time frame diin kinahanglan natong makompleto ang tibuok pipeline.
Source: www.habr.com