Eiti prie turinio 
"WordPress" dinamišką turinį atvaizduoja PHP kalba, todėl vieno procesoriaus branduolio php vieno gido našumas lemia apkrovos laiką ir serverio atsaką. Pirmenybę teikiu Aukšto dažnio laikrodis-CPU, nes jie apdoroja užklausas greičiau nei plačiai paskirstytas, bet lėtas daugelio branduolių laikrodis.
Centriniai taškai
Apibendrinsiu svarbiausius "WordPress" našumo svertus, kad galėtumėte drąsiai priimti techninius sprendimus. Stiprus Viengubo sriegio-veiksmingumas pastebimai pagreitina kiekvieną neišsaugotą užklausą. Daugiabranduoliai padeda lygiagrečiai jungtis, tačiau vienas branduolys lemia vienos užklausos laiką. Spartinančioji atmintinė yra labai veiksminga, tačiau suasmenintas turinys aplenkia talpyklą ir grįžta į PHP. Taip pat įsitikinkite, kad turite naujausias PHP versijas ir švarius įskiepius, kad nestabdytumėte greitojo branduolio.
- Aukšto dažnio laikrodis pranoksta daug branduolių su dinamiška PHP
- Spartinančioji atmintinė padeda, bet veikia ne visur
- PHP versija Didelė įtaka dizainui
- Įskiepiai ir duomenų bazės sulaikymo užklausos
- Priegloba verta naudoti greitą procesorių
Procesoriaus mikroarchitektūra ir aukštas taktinis dažnis
Dėmesį kreipiu ne tik į GHz, bet ir į jo mikroarchitektūrą. Šiuolaikiniai serverių procesoriai sujungia aukštą Turbo taktinis dažnis su stipriu IPC (instrukcijos per valandą). WordPress atveju greičiausias turimas P branduolys (našumo branduolys) dažnai yra svarbesnis už daugelį E branduolių. SMT / "Hyper-Threading gali pagerinti lygiagretumą, bet nepadidina vienos gijos greičio; labai apkrautose sistemose matuoju, ar atskirų gijų išjungimas sumažina atskirų PHP darbininkų vėlavimą. Taip pat Maitinimo būsenos ir Šiluminis droseliavimas žaisti kartu: Aš renkuosi prieglobą, kuris išlaiko pastovų turbo dažnį esant nuolatinei apkrovai, o ne trumpalaikes viršūnes, kurios po kelių sekundžių sutrinka.
Virtualizuotoje aplinkoje taip pat pastebiu. Triukšmingas kaimynas-poveikis. Jei kompiuteris yra tankiai užimtas, efektyvus vienos gijos našumas svyruoja. Dedikuoti branduoliai, procesoriaus prisegimas arba aukšto dažnio egzemplioriai sumažina šį svyravimą. Planuoju rezervus kritinėms parduotuvėms, kad "Turbo" išliktų stabilus net esant didžiausiam srautui.
Kaip PHP apdoroja "WordPress" užklausas?
Kiekviena užklausa į "WordPress" svetainę paleidžia vieną PHP darbininką, kuris visą seką apdoroja nuosekliai [2][4][7][8]. Serveris vienu metu gali priimti kelias užklausas, tačiau vienai užklausai pirmiausia naudingas greitas branduolys. Todėl pirmiausia atkreipiu dėmesį į Laikrodžio dažnis ir instrukcijas per taktą, o ne branduolių sumą. Interneto serveris ir duomenų bazė gali veikti lygiagrečiai, tačiau PHP dalis blokuoja atsakymą, kol jis bus baigtas. Būtent čia pasiteisina stiprus vienas siūlas, ypač temose su daugybe kabliukų, pasirinktinių laukų ir daug skaičiavimų reikalaujančių įskiepių.
"OpCache", JIT ir PHP derinimas
Prieš atnaujindamas aparatinę įrangą, sukuriu OpCache nuosekliai. Pakankamas opcache.memory_consumptiondidelis opcache.max_accelerated_files ir revalidate_freq sumažinti vienos užklausos kompiliavimo darbą, kad jis atitiktų diegimą. Išankstinis įkrovimas gali iš anksto pašildyti dažnai naudojamas klases - tai naudinga stabilioms kodo bazėms be nuolatinio diegimo. PHP 8JIT paprastai duoda mažiau naudos nei "OpCache" "WordPress", tačiau gali pagreitinti skaičiavimams imlias kilpas (pvz., vaizdų tvarkymą). Testuoju JIT pagal kiekvieną projektą ir stebiu atminties fragmentaciją, kad nauda nebūtų iššvaistyta dėl pridėtinių išlaidų.
Aš taip pat optimizuoti realpath_cache_sizekad failų sistemos paieškos būtų greitesnės ir kad automatinio kaupiklio sąranka būtų taupi. Dabartinė PHP mažesnioji versija dažnai suteikia nedidelių, bet išmatuojamų patobulinimų be jokių kodo pakeitimų [5] [1].
Vienos gijos ir daugiabranduoliai praktikoje
Daug branduolių padeda dirbti daugeliui vienu metu dirbančių vartotojų, tačiau jie nepagreitina vienos užklausos apdorojimo [4]. Jei egzempliorius perjungiamas nuo vieno prie dviejų branduolių, PHP užduočių vienos užklausos laikas dažnai išlieka beveik toks pat. Todėl pasikliauju dideliu GHz-reikšmes ir gerus vieno branduolio rezultatus prieš padidindamas branduolių skaičių. Jei norite išsamiai suprasti skirtumą, pažvelkite į Vienagrandis ir daugiagrandis ir tikrina ne tik bendrus rezultatus, bet ir kiekvieno branduolio lyginamuosius testus. Ypač "WooCommerce" naudoja vieną giją pirkinių krepšeliui, sesijų tvarkymui ir kabliukams - čia lemiamas veiksnys yra taktinis dažnis.
Spartinančioji atmintinė padeda - kol ji tampa dinamiška
Puslapio talpykla, objektų talpykla ir CDN dažnai tiesiogiai pateikia statinius atsakymus ir sutaupo PHP paleidimo laiką [6][1][2]. Vos tik naudotojas prisijungia, palygina prekes arba atidaro pirkinių krepšelį, talpykla naudojama mažiau arba visai nenaudojama. Dabar Viengubo sriegio-našumas, nes PHP turi iš naujo apskaičiuoti, filtruoti ir įkelti duomenis. Todėl kešavimo strategijas kuriu taip, kad kuo daugiau duomenų būtų įrašoma į spartinančiąją atmintinę, o neįrašytas kelias veiktų kuo greičiau. Be stipraus branduolio personalizuotuose puslapiuose pastebimai sumažėja TTFB ir interaktyvumas.
Objektų talpyklos strategijos ir pereinamieji procesai
Ein nuolatinė objektų talpykla (pvz., naudojant "Redis" arba "Memcached") greitai amortizuojasi, nes nebereikia nuolatinių kreipimųsi į duomenų bazę. Atkreipiu dėmesį į švarias raktų vardų erdves, TTL ir išvalau senus pereinamuosius laikotarpius. Dideli, niekada nepasibaigiantys pereinamieji arba išpūstos automatinio įkrovimo parinktys, pvz. wp_options gali paneigti pranašumą. Naudodamas "WooCommerce" nustatymus, taip pat mažinu brangių wp_postmeta-ieškoti, svarbiausius duomenis talpinant į spartųjį spartintuvą struktūrose, kurias galima greitai atkurti. Svarbu: objektų talpykla pagreitina PHP kelią, tačiau ir čia Greita šerdisnes kiekvienos užklausos deserializavimas ir apdorojimas yra greitesnis.
Kodėl aukštas taktinis dažnis įkrauna pastebimai greičiau
Greita šerdis sutrumpina kiekvieną kilpą, kiekvieną kabliukų pluoštą ir kiekvieną šablono operaciją [4] [8]. Naudinga ir prieiga prie duomenų bazės, nes PHP greičiau parengia užklausas ir apdoroja rezultatus. Pirmiausia optimizavau procesoriaus taktą ir IPCtada įvesties ir išvesties bei tinklo. Atliekant matavimus, atskirų neišsaugotų užklausų spartinimas yra labiau pastebimas nei papildomų branduolių poveikis. Ypač pastebima: administratoriaus veiksmai, tikrinimo veiksmai ir API galutiniai taškai reaguoja daug greičiau naudojant didelio taktinio dažnio procesorius.
"WooCommerce" specifiniai karštieji taškai
Kasoje susiduriama su keliais sąnaudas lemiančiais veiksniais: Mokėjimo vartai: sesijos tvarkymas, kupono patvirtinimas, mokesčių ir išsiuntimo apskaičiavimas, mokėjimo vartai. Sumažinu kabliukų kaskadas, išjungiu nenaudojamas kasos funkcijas ir patikrinu, kurie įskiepiai įkeliami kiekviename žingsnyje. AJAX galiniai taškai krepšeliui vargu ar galima pasinaudoti puslapio spartinančiąja atmintimi - čia veiksminga tik procesoriaus galia. Piko metu planuoju pakankamai PHP darbininkų, bet vis tiek išlaikysiu už užklausą-laikas su aukštu laikrodžio rodyklių skaičiumi, kad eilės apskritai nesusidarytų.
Tipinės "WordPress" projektų kliūtys
Didelės apkrovos be talpyklos ypač skaudžiai atsiliepia parduotuvėms ir narystės svetainėms, nes daugelis atsakymų yra asmeniniai [2][3][7]. Sunkiasvoriai įskiepiai apima daug kabliukų ir prailgina vykdymą. Taip pat pastebiu neefektyvių duomenų bazės užklausų su daugybe sujungimų, dėl kurių PHP yra užimta. Administratoriaus skydeliai ir analizės valdikliai su kiekvienu iškvietimu sukuria papildomą PHP apkrovą. Iš viso Pagrindinis pastebimą greitį, o ne turimų branduolių skaičių.
Duomenų bazės projektavimas ir "InnoDB" derinimas
Tikrinu Indeksai dažnai filtruojamuose stulpeliuose (pvz. meta_key su wp_postmeta) ir sumažinti LIKE paieškas, kuriose nenaudojami indeksai. Automatinio įkėlimo parinktys wp_options Juos laikau taupius, nes jie įkeliami kiekviename puslapyje. Duomenų bazės lygmeniu aš dimensijuoju InnoDB buferinis rezervuaras kad rinkiniai liktų operatyviojoje atmintyje; priešingu atveju lėta įvestis ir išvestis ištemptų PHP kelią. Ilgas query_time Juos atpažįstu lėtuose žurnaluose ir tobulinu planus naudodamas EXPLAIN. Tas pats galioja ir čia: greitas procesorius pagreitina kliento pusėje Apdorojimas PHP - švarios užklausos taip pat sutrumpina rezultatų laukimo laiką.
Konkrečios priemonės ir prieglobos pasirinkimas
Pasikliauju aukšto taktinio dažnio serveriais ir mažinu nereikalingą įskiepių apkrovą, kad greitasis branduolys nepatektų į pridėtines išlaidas. Atnaujinus iki naujausios PHP versijos pastebimai padidėja našumas, nors atskirų versijų našumas gali skirtis [5] [1]. Nuosekliai nustatau spartinančiąją atmintinę, tačiau dinaminį kelią palieku kuo taupesnį. Projektuose, kuriuose yra daug dinamikos, tikrinu WordPress priegloba su aukšto dažniooptimizuoti Vėlavimas kiekvienos neišsaugotos užklausos. Toliau pateiktoje apžvalgoje parodyta, kaip turėtų būti skirstomi greito vieno srauto našumo paslaugų teikėjai.
| Reitingas | Teikėjas | Įvertinimas (Viena gija) |
|---|---|---|
| 1. | webhoster.de | Labai gerai |
| 2. | Teikėjas B | Geras |
| 3. | Teikėjas C | Patenkinamai |
PHP versija kaip greičio tvarkyklė
Pereinant nuo PHP 7.4 prie 8.0 arba 8.2 galima gerokai sutaupyti laiko, tačiau ne kiekviena versija užtikrina tokį patį vidurkį [5] [1]. Todėl matuoju faktinį našumą kiekvienam projektui ir atkreipiu dėmesį į nesuderinamumą. Bibliotekos ir "OpCache" nustatymai taip pat turi įtakos vykdymui. Greitas branduolys atsiskleidžia su moderniu PHP-versija, nes interpretatorius veikia efektyviau. Sukurkite bandomąją aplinką, išmatuokite, tada pradėkite naudoti - taip užtikrinsiu atkuriamus patobulinimus.
PHP darbuotojai, FPM ir eilės
Per mažai PHP darbuotojų sukuria eiles, per daug darbuotojų išstumia talpyklą ir duomenų bazę į operatyviąją atmintį. Atsižvelgdamas į duomenų srauto profilį ir atsakymo laiką, subalansuoju pm.max_children, pm.start_servers ir pm.max_requests. Vienai užklausai vis tiek bus naudingas greičiausias branduolys, nesvarbu, kiek darbininkų veikia lygiagrečiai. Jei norite įsigilinti į PHP darbuotojų supratimas Noriu stebėti apkrovos pikus ir reguliuoti ribines vertes. Atlikdamas švarų derinimą, sumažinsiu laiko tarpą ir išlaikysiu TTFB stabilus, net ir esant bangų srautui [2].
Taip pat pasirenku tinkamą FPM režimas: užsakomasis taupo išteklius, kai srautas nedidelis, dinaminis greičiau reaguoja į apkrovos pikus. pm.max_requests kad atminties nutekėjimas būtų ribojamas periodiškai ją perdirbant ir nesukeltų nereikalingų šaltų paleidimų. Dideles svetaines atskiriu į atskirus FPM baseinus, kad būtų galima izoliuoti gedimus.
Tinklo serverio stekas ir tinklo užlaikymai
Nors PHP dominuoja TLS, HTTP/2/HTTP/3, išlaikyti gyvybingumą ir suspausti klientų patirtį. Aš aktyvuoju Duonos lazdelės tekstiniam turtui ir išlaikyti TLS rankų paspaudimus, kai sesija atnaujinama. Svarbu: geriausias TTFB yra sukurtas iš greitas procesorius plius trumpais atstumais. Todėl platinu statinį turinį per CDN, tačiau dinaminius galinius taškus laikau arti naudotojo ir užtikrinu, kad atvirkštiniai tarpiniai serveriai galėtų Spartinančiosios atmintinės apėjimas teisingai, kad HTML nebūtų netyčia įrašytas į spartinančiąją atmintį prisijungusiems naudotojams.
Stebėsena, lyginamieji testai ir darbo eigos derinimas
Pradedu nuo sintetinių lyginamųjų testų, skirtų vieno branduolio rezultatams nustatyti, o tada patvirtinu tikromis užklausomis. Paprasti rodikliai, tokie kaip TTFB, PHP FPM eilės ilgis ir užklausų laikas, greitai atskleidžia kliūtis. Tada bandymui pašalinu lėtus įskiepius ir vėl matuoju. Išskiriu kiekvieno žingsnio poveikį, kad Priežastis išlieka aišku. Tik tada investuoju į galingesnius procesorius, nes išmatuotos vertės parodo, ar taktinis dažnis, ar architektūra yra ribota.
Išsamiai analizei atlikti naudoju profiliavimo programas, kurios Karšti keliai kabliukų ir šablonų funkcijose. Serverio laiko nustatymas-atsakymo antraštės padeda atskirti PHP, DB ir aukštesnio lygmens laikus naršyklėje. Svarbu, kad procesą būtų galima atkartoti: Tik tada diegimas. Taip užtikrinama, kad optimizavimas išliktų patikimas.
Sąnaudų ir naudos santykis ir sprendimų priėmimo strategija
Atnaujinimas į greitesnį procesorių su aukštu taktiniu dažniu gali kainuoti 10-30 eurų daugiau per mėnesį, tačiau sutaupysite apčiuopiamo laiko vienai užklausai. Ypač parduotuvėse ši suma greitai amortizuojasi, nes dėl greitesnių puslapių parduodama daugiau pirkinių krepšelių. Be procesoriaus taktinio dažnio, taip pat atsižvelgiu į NVMe saugyklą, operatyviąją atmintį, skirtą spartinančiajai atminčiai, ir tinklo vėlavimą. . Prioritetas išlieka vienintele gija, nes ji dominuoja kiekviename dinaminiame atsakyme. Planuokite išėjimus pagal realios apkrovos profilius ir palikite vietos pikams.
Planuoju didinti mastą dviem etapais: Pirmasis Vertikalus (didesnis taktinis dažnis, stipresni branduoliai), tada horizontalus (daugiau PHP darbuotojų keliuose mazguose), kai lygiagretumas tampa kliūtimi. Duomenų bazę ir PHP atskyriau jau pačioje pradžioje, kad jas būtų galima nepriklausomai didinti ir derinti. Taip sistema išlieka ekonomiška ir greita.
Santrauka: kas iš tikrųjų svarbu
Pirmiausia dėmesį sutelksiu į stiprų vienos gijos našumą, nes jis tiesiogiai pagreitina kiekvieną dinaminį puslapį [2] [4]. Tada viską užbaigiu švaria spartinančiąja atmintimi, naujausia PHP versija ir tvarkingais įskiepiais [5][1]. Daugiabranduoliai padeda užtikrinti lygiagretumą, tačiau greitas branduolys labiau sutrumpina vienos užklausos laiką. Kad būtų pastebima sėkmė, derinu didelio taktinio dažnio procesorių, subalansuotus darbininkus ir išmatuojamą KPI. Jei taip elgsitės, "WordPress" bus žymiai spartesnis, ypač tais atvejais, kai spartinančioji atmintinė nieko negali padaryti [6][7][8].
