Ni parolis pri la metodiko en artikolo, en ĉi tiu ni testas HTTPS, sed en pli realismaj scenaroj. Por testado, atestilo Let's Encrypt estis akirita, Brotli-kunpremado estis ebligita ĉe 11.
Ĉi-foje ni provos reprodukti la scenaron de deplojado de servilo sur VDS aŭ kiel virtuala maŝino sur gastiganto kun norma procesoro. Por tiu celo, limo estis fiksita je:
- 25% - Kio estas ekvivalenta al frekvenco de ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
La nombro da unufojaj konektoj estis reduktita de 500 al 1, 3, 5, 7 kaj 9,
Rezulto:
Prokrastoj:
TTFB estis specife inkluzivita kiel aparta testo, ĉar HTTPD-Iloj kreas novan uzanton por ĉiu individua peto. Ĉi tiu testo ankoraŭ estas sufiĉe malproksimigita de la realo, ĉar la uzanto ankoraŭ klakos kelkajn paĝojn, kaj fakte TTFP ludos la ĉefan rolon.
La unua, ĝenerale la plej unua peto post la unua ekfunkciigo de la virtuala maŝino de IIS daŭras averaĝe 120 ms.
Ĉiuj postaj petoj montras TTFP de 1.5 ms. Apache kaj Nginx postrestas ĉi-rilate. Persone, la aŭtoro konsideras ĉi tiun teston la plej malkaŝa kaj elektus la gajninton nur surbaze de ĝi.
La rezulto ne estas surpriza, ĉar IIS konservas jam kunpremitan statikan enhavon kaj ne kunpremas ĝin ĉiufoje kiam ĝi estas alirita.
Tempo pasigita por kliento
Por taksi rendimenton, testo kun 1 ununura konekto sufiĉas.
Ekzemple, IIS kompletigis teston de 5000 uzantoj en 40 sekundoj, kio estas 123 petoj je sekundo.
La malsupraj grafikaĵoj montras la tempon ĝis la retejo-enhavo estas tute translokigita. Ĉi tiu estas la proporcio de petoj plenumitaj en difinita tempo. En nia kazo, 80% de ĉiuj petoj estis procesitaj en 8ms sur IIS kaj en 4.5ms sur Apache kaj Nginx, kaj 8% de ĉiuj petoj sur Apache kaj Nginx estis kompletigitaj en intervalo de ĝis 98 milisekundoj.
Tempo dum kiu 5000 petoj estis procesitaj:
Tempo dum kiu 5000 petoj estis procesitaj:
Se vi havas virtualan maŝinon kun 3.5GHz CPU kaj 8 kernoj, tiam elektu tion, kion vi volas. Ĉiuj retserviloj estas tre similaj en ĉi tiu testado. Ni parolos pri kiu retservilo elekti por ĉiu gastiganto sube.
Kiam temas pri iom pli realisma situacio, ĉiuj retserviloj iras kapo al kapo.
Trairo:
Grafiko de prokrastoj kontraŭ la nombro da samtempaj konektoj. Pli glata kaj pli malalta estas pli bona. La lastaj 2% estis forigitaj de la furorlisto ĉar ili igus ilin nelegeblaj.
Nun ni konsideru la opcion kie la servilo estas gastigita sur virtuala gastigado. Ni prenu 4 kernojn je 2.2 GHz kaj unu kernon je 1.8 GHz.
Kiel grimpi
Se vi iam vidis kiel aspektas la nunaj tensiaj trajtoj de vakuaj triodoj, pentodoj kaj tiel plu, ĉi tiuj grafikaĵoj estos konataj al vi. Jen kion ni provas kapti - saturiĝon. La limo estas kiam kiom ajn kernoj vi ĵetas, la rendimento pliiĝo ne estos rimarkebla.
Antaŭe, la tuta defio estis prilabori 98% de petoj kun la plej malalta latenco por ĉiuj petoj, konservante la kurbon kiel eble plej ebena. Nun, konstruante alian kurbon, ni trovos la optimuman operacian punkton por ĉiu el la serviloj.
Por fari tion, ni prenu la indikilon de Petoj por sekundo (RPR). Horizontala estas la ofteco, vertikala estas la nombro da petoj procesitaj je sekundo, linioj estas la nombro da kernoj.
Montras korelacion pri kiom bone Nginx prilaboras petojn unu post alia. 8 kernoj funkcias pli bone en ĉi tiu testo.
Ĉi tiu grafikaĵo klare montras kiom pli bone (ne multe) Nginx funkcias sur ununura kerno. Se vi havas Nginx, vi devus konsideri redukti la nombron da kernoj al unu se vi gastigas nur statikajn.
IIS, kvankam ĝi havas la plej malaltan TTFB laŭ DevTools en Chrome, sukcesas perdi kontraŭ kaj Nginx kaj Apache en serioza batalo kun la strestesto de la Apache Foundation.
La tuta kurbeco de la grafikaĵoj estas reproduktita ferkovrita.
Ia konkludo:
Jes, Apache funkcias pli malbone ĉe 1 kaj 8 kernoj, sed funkcias iomete pli bone ĉe 4.
Jes, Nginx sur 8 kernoj prilaboras petojn pli bone unu post la alia, sur 1 kaj 4 kernoj, kaj funkcias pli malbone kiam estas multaj konektoj.
Jes, IIS preferas 4 kernojn por multfadenaj laborŝarĝoj kaj preferas 8 kernojn por unufadenaj laborŝarĝoj. Finfine, IIS estis iomete pli rapida ol ĉiuj aliaj sur 8 kernoj sub alta ŝarĝo, kvankam ĉiuj serviloj estis egale.
Ĉi tio ne estas mezuraro, la eraro ĉi tie ne estas pli ol +-1ms. en prokrastoj kaj ne pli ol +- 2-3 petoj sekundo por RPR.
La rezultoj, kie 8 kernoj funkcias pli malbone, tute ne estas surprizaj, multaj kernoj kaj SMT/Hyperthreading multe degradas rendimenton se ni havas tempokadron en kiu ni devas kompletigi la tutan dukton.
fonto: www.habr.com