Kako se direktive ponašaju i koje su uglavnom dostupne ovisi o učitanom MPM-u. MPM je skraćenica od MultiProcess modula i oni određuju osnovu za način na koji se Apache obraća višeprocesiranju. Obuhvatit ćemo sljedeće pododjeljke:
- Opća optimizacija
- Optimizacija događaja / radnika
- Optimizacija predforka
Svaki će se dio usredotočiti na to kako direktive utječu na izvedbu za njihov MPM i neka uobičajena razmatranja koja treba procijeniti prilikom optimizacije Apachea s tim specifičnim MPM-ima.
1. Općenita optimizacija
IfModule
Važna smjernica koju treba naučiti prilikom rada s Apache poslužiteljima je uvjetni izraz IfModule. Dva su dijela izjave IfModule. Početak koji također prihvaća naziv modula ili naziv izvorne datoteke modula, kao i završnu izjavu. Kada se ponuđeni modul učita u Apache, tada se sve direktive između početne naredbe IfModule i završne naredbe IfModule također čitaju u konfiguraciji Apachea koja se izvodi. Molim pogledajte dolje navedeni primjer za daljnje pojašnjenje:
<ifModule mpm_prefork_module>
MaxSpareServers 16
</ifModule>
Timeout 60
Gornji primjer definira direktivu MaxSpareServers samo kada je učitan mpm_prefork_module. Direktiva o vremenskom ograničenju Timeout primjenjuje se svaki put jer je izvan završne naredbe IfModule.
Izjave IfModule koriste se za održavanje kompatibilnosti unutar Apache konfiguracije između promjena modula. Održavanje kompatibilnosti vrši se grupiranjem direktiva u naredbe IfModule, tako da se koriste samo kada se učita potreban modul. Osiguravanje sintaksički ispravne konfiguracijske datoteke čak i prilikom zamjene modula.
Odgovarajuće umotavanje svega u izjavu IfModule standard je najbolje prakse za Apache i treba ga se pridržavati radi superiorne kompatibilnosti u konfiguracijskim datotekama.
Timeout
Numerička vrijednost sekundi koju Apache čeka na sve uobičajene I/O događaje. Apache će napustiti zahtjeve koji se ne izvrše prije navedene vrijednosti vremenskog ograničenja.
Određivanje pravog vremenskog ograničenja ovisi i o tipu prometa i o posluženim aplikacijama. U idealnom slučaju, vremensko ograničenje trebalo bi biti što je moguće kraće, a istovremeno dopustiti da velika većina redovnog prometa radi bez problema. Velika vremenska ograničenja, ona iznad 1 minute, otvaraju poslužitelj za DOS napade u stilu SlowLoris i potiču dugo čekanje u pregledniku kada dođe do problema problem. Niža vremenska ograničenja omogućuju Apacheu da se brzo oporavi od pogrešnih zaglavljenih veza. Stoga postaje neophodno uspostaviti ravnotežu između dviju krajnosti.
Izbjegavajte povećavanje globalnog vremenskog ograničenja kada rješavate probleme s jednom skriptom ili korisnikom koji zahtijevaju dugotrajno vremensko ograničenje. Problemi se obično mogu riješiti .htaccess datotekom ili uključiti datoteku za povećanje vremenskog ograničenja za tu određenu skriptu.
KeepAlive
Jednostavni prekidač za uključivanje/isključivanje omogućuje KeepAlive protokole s podržanim preglednicima. Značajka KeepAlive može pružiti čak 50% smanjenja kašnjenja, što značajno poboljšava performanse Apachea. KeepAlive to postiže ponovnom upotrebom istih početnih veza koje preglednik stvara prilikom povezivanja s Apacheom za sve daljnje zahtjeve koji se pojave u kratkom razdoblju.
KeepAlive je moćna značajka i općenito bi je trebalo omogućiti u većini situacija. Izvrsno funkcionira za smanjenje nekih troškova CPU-a i mreže s modernim internet mjestima teškim za elemente. Na primjer, jednostavan način vizualizacije KeepAlive je pomoću fraze “drži vrata”. Zamislite red ljudi koji ulaze u zgradu kroz jedna vrata. Svaka osoba mora otvoriti vrata, proći kroz njih, a zatim zatvoriti vrata prije nego što sljedeća osoba učini isti postupak. Uglavnom, tako Apache radi bez KeepAlivea. Kad su omogućena, vrata ostaju otvorena dok svi ljudi u redu ne prođu kroz vrata prije nego što se ponovno zatvore.
Dvije dodatne povezane smjernice također reguliraju KeepAlive. MaxKeepAliveRequests i KeepAliveTimeout. Kao što je raspravljeno u sljedećem odjeljku, svaki od njih igra vitalnu ulogu u preciznom podešavanju KeepAlive direktive.
MaxKeepAliveRequests
Postavlja ograničenje broja zahtjeva koje pojedinačna veza KeepAlive smije obraditi. Jednom dosegnut, Apache prisiljava vezu da se prekine i stvara novu za sve dodatne zahtjeve.
Određivanje idealne postavke ovdje je otvoreno za tumačenje. Općenito želite da ta vrijednost bude najmanje toliko velika koliko je najveći broj elemenata (HTML, Text, CSS, Images, itd.) Koji poslužuju stranice na kojima se najviše prometuje na poslužitelju.
Postavite MaxKeepAliveRequests na dvostruku vrijednost maksimalnog broja zahtijeva na uobičajenim stranicama. (Usluge poput webpagetest.org ili gtmetrix.com mogu brojati zahtijeve na stranici).
KeepAliveTimeout
Ova se direktiva mjeri u sekundama i ostat će u stanju mirovanja čekajući dodatne zahtjeve svog inicijatora. Budući da su ove vrste veza dostupne samo njihovom pokretaču, KeepAliveTimeout želimo zadržati na vrlo niskom nivou. Niska vrijednost sprečava previše veza KeepAlive da zaključaju nove posjetitelje zbog prioriteta veze.
Velika MaxKeepAliveRequests direktiva s vrlo niskim KeepAliveTimeout omogućuje aktivnim posjetiteljima ponovnu upotrebu veza, a istovremeno brzo oporavlja niti od neaktivnih posjetitelja. Zato postavite MaxKeepAliveRequests na 500+, a KeepAliveTimeout na 2 kada koristite MPM Event.
2. MPM Event/Worker optimizacija
Ovaj odjeljak detaljno opisuje upotrebu i izvedbu koja je ključna za pokretanje MPM-a zasnovanih na radniku, uključujući MPM Event i MPM Worker. Ti se MPM-ovi smatraju višenitnim rješenjima, a neke se direktive ponašaju različito na temelju učitanog MPM-a. Podaci navedeni u ovom odjeljku samo su dio o MPM-ova koji se temelje na radnicima.
U MPM-ovima koji se temelje na radnicima: ServerLimit, ThreadsPerChild i MaxRequestWorkers međusobno su povezani. Bitno je razumjeti ulogu svakog od njih i kako promjena jednog utječe na ostale. Sljedeće smjernice uređuju fino podešavanje mogućnosti rukovanja nitima Apache internet poslužitelja.
MPM Worker i MPM Event
Dva modula, MPM Event i MPM Worker za većinu namjera i svrha djeluju identično. Razlika je očita u načinu na koji svaki obrađuje zahtjeve KeepAlive. MPM Worker zaključava niti za vrijeme trajanja procesa KeepAlive i izravno utječe na broj dostupnih niti i mogućnosti obrađivati novih zahtjeva. MPM Event koristi nit slušatelja za svako dijete. Ove niti slušatelja obrađuju standardne zahtjeve, a KeepAlive zahtjevi neće smanjiti kapacitet poslužitelja zaključavanjem niti. Bez zaključavanja niti, MPM Event je vrhunski izbor, ali samo u Apacheu 2.4. Prije Apachea 2.4 MPM Event bio je nestabilan i sklon problemima.
ServerLimit
ServerLimit predstavlja gornju granicu djece Apache koja je dopuštena. Praktična upotreba ServerLimita stvara tvrdi strop u Apacheu kako bi se zaštitio od pogrešaka unosa s MaxRequestWorkers. Ova granica sprječava stvaranje znatno više djece nego što ih sustav može podnijeti, što rezultira zastojima, gubitkom prihoda, gubitkom ugleda ili čak gubitkom podataka.
ServerLimit se izravno veže uz točku razbijanja o kojoj smo raspravljali ranije u ovom članku. Točka razbijanja je maksimalan broj djece koju Apache može pokrenuti prije nego što korištenje memorije prevagne u korist swap spore trajne memorije. Potrebno je uskladiti ServerLimit s izračunatom vršnom točkom radi zaštite poslužitelja.
ThreadsPerChild
Koristi se za definiranje ograničenja niti kojima svako dijete Apachea može upravljati. Svaka pokrenuta nit može obraditi jedan zahtjev. Zadana vrijednost 25 dobro funkcionira u većini slučajeva i dobra je ravnoteža između djece i niti.
Postoji i gornja granica ove direktive, a ograničenje kontrolira ThreadLimit direktiva, koja prema zadanim postavkama iznosi 64 niti. Prilagodbe za povećanje ThreadsPerChild-a u prošlosti od 64 niti također treba izvršiti u ThreadLimit.
Povećavanje ove vrijednosti omogućuje svakom djetetu da obrađuje više zahtjeva, smanjujući potrošnju memorije, istovremeno dopuštajući veću direktivu MaxRequestWorkers. Ključna prednost izvođenja više niti unutar svakog djeteta je pristup predmemoriji dijeljene memorije. Niti jednog djeteta ne mogu pristupiti predmemorijama drugog djeteta. Povećavanje broja niti po djetetu istiskuje veće performanse zahvaljujući ovom dijeljenju podataka predmemorije. Glavni nedostatak povećanog konca po djetetu javlja se tijekom recikliranja djeteta. Kapacitet poslužitelja smanjuje se brojem niti konfiguriranih za svako dijete kada se taj podređeni postupak na kraju reciklira (graciozno ponovno pokretanje).
Suprotna se reakcija postiže spuštanjem ThreadsPerChild. Manje niti po djetetu zahtijeva da više djece pokreće jednaku količinu MaxRequestWorkersa. Budući da su djeca pune kopije Apachea, to povećava ukupni otisak memorije Apachea, ali smanjuje utjecaj prilikom recikliranja djece. Manje niti znači manje potencijalnih “zaglavljenih” niti tijekom postupka recikliranja, što zadržava veći kapacitet zahtjeva na raspolaganju cjelokupnoj djeci. Ako imate manje niti po djetetu, osigurava se veća izolacija dijeljene memorije. Na primjer, ispuštanje ThreadsPerChild na 1 daje istu izolaciju zahtjeva MPM Preforka, ali nasljeđuje i njegov ogroman porez na izvedbu, zahtijevajući jedno dijete po jednom zahtjevu.
Prilikom postavljanja ThreadsPerChild uvijek uzmite u obzir okruženje poslužitelja i hardver.
- Dijeljeni poslužitelj gladan memorije koji poslužuje brojne neovisne račune mogao bi se odlučiti za niži ThreadsPerChild, smanjujući potencijalni utjecaj jednog korisnika na ostale.
- Namjenski Apache poslužitelj u konfiguraciji uravnoteženoj s opterećenjem velikog kapaciteta može odabrati značajno veći ThreadsPerChild za bolje ukupne performanse svake niti.
ThreadLimit
Koristi se za postavljanje maksimalne vrijednosti ThreadsPerChild. Ova je direktiva čvrsti strop za ThreadsPerChild. Pomaže u zaštiti od tipografskih pogrešaka s ThreadsPerChild direktivom koja može brzo izbaciti poslužitelj izvan kontrole ako je dopušteno previše niti zbog pogreške u unosu. Ovu postavku treba prilagoditi na nekim vrhunskim poslužiteljima kada sustavu treba više od zadanih 64 niti po djetetu.
MaxRequestWorkers / MaxClients
Direktiva postavlja ograničenje za aktivne radničke niti za svu pokrenutu djecu i djeluje kao mekani strop, a ServerLimit preuzima kontrolu kao tvrdo ograničenje. Kad broj ukupnih pokrenutih niti dosegne ili premaši MaxRequestWorkers, Apache više ne stvara novu djecu.
Određivanje MaxRequestWorkers je kritični dio optimizacije poslužitelja. Optimalna postavka temelji se na nekoliko varijabli koje se mijenjaju. To znači da njegovu konfiguraciju treba s vremenom preispitivati i prilagođavati, mijenjajući promatranjem prometnih navika i korištenja resursa sustava. Pregled stanja Apachea učinkovit je alat za analizu performansi Apachea.
Tipično je za MPM sustave koji se temelje na Workeru da pokreću izolirani PHP-ov rukovatelj treće strane poput Mod_fcgid, PHP-FPM i mod_lsapi. Ovi su moduli odgovorni za obradu PHP koda izvan Apachea i oslobađaju Apache da obrađuje sve ostale zahtjeve koji nisu PHP, poput HTML-a, TEXT-a, CSS-a, slika itd. Ovi zahtjevi su daleko lakši i ne troše puno resursa poslužitelja što Apacheu omogućuje da obrađuju veće količine zahtjeva, poput onih koji prelaze 400 MaxRequestWorkers.
MinSpareThreads
Najmanji broj niti koje bi trebale ostati otvorene, čekajući nove zahtjeve. MinSpareThreads je višekratnik ThreadsPerChild i ne može premašiti MaxSpareThreads, iako mu može odgovarati.
Postavite MinSpareThreads na 50% od MaxRequestWorkers.
Rezervne niti su neaktivne radničke niti. Te niti samo čekaju nove dolazne zahtjeve i njima upravlja Apacheov dječji proces koji ih je stvorio. Ako je manje dostupnih niti od MinSpareThreads, roditelj Apache generirat će novo dijete s drugim nitima vrijednim ThreadsPerChild.
MaxSpareThreads
Ova direktiva regulira ukupan broj praznih niti dopuštenih na poslužitelju za svu djecu. Sve niti iznad ovog ograničenja usmjeravaju roditelja da se isključi kako bi se smanjila potrošnja memorije tijekom neaktivnih sati.
Ograničenje broja praznih otvorenih niti izvrsno je za manje poslužitelje s hardverskim ograničenjima. Međutim, uglavnom je nepotreban na današnjem modernom hardveru.
Konfiguriranje Apache-a po principu otvorenog gasa konfiguracija je visokih performansi za poslužitelje sa značajnom količinom RAM-a i više procesorskih jezgri. Pri pokretanju konfiguracije otvorenog gas, sve dostupne niti postaju dostupne u svakom trenutku. Korištenje Apacheove memorije cijelo će vrijeme biti na vrhuncu, nuspojava zbog preventivnog pokretanja sve konfigurirane djece u memoriju. Ova će konfiguracija proizvesti najbolja moguća vremena odgovora od Apachea održavanjem trajnih otvorenih veza spremnih za rad i uklanjanjem dodatnih troškova za mrežne procese kao odgovor na povećanje prometa. Uskladite i MinSpareThreads i MaxSpareThreads s MaxRequestWorkers i pobrinite se da poslužitelj ima dovoljno RAM-a za pokretanje svih MaxRequestWorkers odjednom.
StartServers
Ova direktiva regulira početni broj djece koju Apache Parent proces stvara kada se Apache pokrene. Obično se ostavlja nepromijenjeno jer Apache kontinuirano provjerava trenutno pokrenutu djecu zajedno s ThreadsPerChild i uspoređuje ga s MinSpareThreads kako bi utvrdio hoće li se više djece račvati. Taj se postupak ponavlja neprestano, s udvostručavanjem nove djece na svakoj iteraciji, sve dok MinSpareThreads ne bude zadovoljan.
Ručno izračunavanje StartServers vrši se dijeljenjem MaxRequestWorkers s ThreadsPerChild, zaokruživanjem na najbliži cijeli broj. Ovaj postupak prisiljava na stvaranje sve djece bez odgađanja prilikom pokretanja i odmah započinje s rješavanjem zahtjeva. Ovaj je aspekt posebno koristan u modernim Apache poslužiteljima koji zahtijevaju povremeno ponovno pokretanje radi učitavanja promjena direktiva.
MaxConnectionsPerChild / MaxRequestsPerChild
Broj zahtjeva koje jedan podređeni proces Apache može obraditi jednak je kumulativnom zbroju na podređenom poslužitelju u svim nitima koje kontrolira. Svaki zahtjev koji obrađuje nit računa se prema ovom ograničenju za svog roditelja. Jednom kada podređeni poslužitelj dosegne svoju granicu, dijete se potom reciklira.
Ova je smjernica zapor za slučajno curenje memorije. Neki kôd izveden kroz Apache niti može sadržavati curenje memorije. Procurila memorija dijelovi su memorije koje potproces nije uspio ispravno osloboditi, pa su nedostupni bilo kakvim vanjskim procesima. Što dulje program koji curi ostane pokrenut, više će memorije propuštati. Postavljanje ograničenja MaxConnectionsPerChild posebna je metoda kojom se osigurava da Apache povremeno reciklira programe kako bi smanjio utjecaj procurjele memorije na sustav. Kada koristite vanjske rukovatelje kodom poput Mod_fcgid, PHP-FPM ili mod_lsapi, postaje neophodno postaviti MaxConnectionsPerChild na 0 (neograničeno), čime se sprječavaju periodične stranice pogrešaka uzrokovane Apacheovim prevremenim završetkom niti.
Ako poslužitelj naiđe na curenje memorije, nikada ne postavljajte MaxConnectionsPerChild / MaxRequestsPerChild prenisko, umjesto toga počnite s 10 000 i postupno ga smanjujte.
3. MPM prefork optimizacija
Ovaj odjeljak MPM Prefork detaljno opisuje upotrebu i izvedbu različitih direktiva prilikom izvođenja ovog modula. Ovaj MPM je višeprocesor bez niti dizajniran za kompatibilnost. Sastoji se od jednog matičnog procesa Apachea, koji se koristi za upravljanje potpuno novim Apache procesima poznatim i kao djeca. Sljedeće smjernice pokazuju kako je Apache sposoban za podešavanje performansi kada koristi MPM Prefork. Za razliku od MPM-a zasnovanih na radnicima, optimizacija MPM Preforka uglavnom je jednostavna. Postoji omjer Apache procesa 1:1 i dolaznih zahtjeva. Međutim, MPM Prefork ne skalira se dobro s hardverom, a što više prometa nailazi, trebat će više hardvera da ide u korak s tempom. Treba imati na umu da se neke direktive ponašaju različito ovisno o učitanom MPM-u. Podaci navedeni u ovom odjeljku samo su dio o MPM Preforku.
MaxRequestWorkers / MaxClients
Koristi se za kontrolu gornje granice djece koju roditeljski poslužitelj Apache odjednom smije imati u memoriji. Ta djeca (koja se nazivaju i radnicima) rješavaju zahtjeve u omjeru 1:1. To znači da je to ujedno i maksimalan broj istodobnih zahtjeva koje poslužitelj može obraditi.
Ako je ova direktiva preniska, Apache premalo koristi raspoloživi hardver što u prijevodu znači rasipanje novca i velika kašnjenja u vremenu učitavanja stranice tijekom udarnih termina posjećenosti. Alternativno, ako je ova direktiva previsoka, Apache nadmašuje temeljni hardver i guši sustav što može dovesti do padova poslužitelja i potencijalnog gubitka podataka.
MinSpareServers
Ova direktiva definira minimalni broj rezervne djece koju roditeljski proces Apache može zadržati u svojoj memoriji. Dodatni poslužitelj je unaprijed pripremljeno neaktivno dijete Apachea koje je spremno odgovoriti na novi dolazni zahtjev. Neaktivna djeca koja čekaju nove zahtjeve ključna su za osiguravanje najbržeg vremena odziva poslužitelja. Kad se ukupna neaktivna djeca na poslužitelju spuste ispod ove vrijednosti, novo dijete stvara se brzinom od jedne u sekundi dok se ne ispuni ova direktiva. Pravilo “jedan u sekundi” postoji kako bi se spriječilo preopterećenje stvaranjem procesa koji preopterećuju poslužitelj, međutim, dolazi s visokom cijenom. Stopa pojavljivanja jedan u sekundi posebno je spora kada je riječ o rukovanju zahtjevima stranica. Stoga je vrlo korisno osigurati da je dovoljno djece unaprijed pripremljeno i spremno za obradu dolaznih zahtjeva.
Nikad ne postavljajte ovo na nulu. Postavljanje na 25% MaxRequestWorkers osigurava da je puno resursa spremno i čeka na zahtjeve.
MaxSpareServers
MasSpareServers kontrolira maksimalni broj neaktivnih Apache podređenih poslužitelja koji se istodobno izvode. Neaktivno dijete je ono koje trenutno ne obrađuje zahtjev, ali čeka novi zahtjev. Kad ima više od MaxSpareServers neaktivne djece, Apache ubija višak.
Ako je vrijednost MaxSpareServers manja od MinSpareServers, Apache će automatski prilagoditi MaxSpareServers na jednake MinSpareServers plus jedan.
Kao i kod MinSpareServers, i ovu vrijednost treba uvijek mijenjati imajući na umu dostupne resurse poslužitelja.
Osnovno pravilo je postaviti ovo na dvostruku vrijednost MinSpareServers.
Konfiguriranje Apache-a kao otvorenog gasa konfiguracija je visokih performansi za poslužitelje sa značajnim RAM-om i više procesorskih jezgri. Pri pokretanju konfiguracije otvorenog gas, sva dostupna djeca Apachea postaju dostupna u svakom trenutku. Kao nuspojava pokretanja otvorenog gas, upotreba Apache memorije ostat će blizu vrhunca cijelo vrijeme zbog preventivnog pokretanja sve konfigurirane djece u memoriju. Ova će konfiguracija proizvesti najbolje moguće vrijeme odziva održavanjem trajnih otvorenih veza. Nadalje, kao odgovor na nagli porast prometa, uklanja troškove koji proizlaze iz stvaranja novih procesa. Uskladite i MinSpareServers i MaxSpareServers s MaxRequestWorkers i pobrinite se da ima dovoljno RAM-a poslužitelja za pokretanje svih MaxRequestWorkers odjednom.
StartServers
Stvorene pri pokretanju početna su količina podređenih poslužitelja Apache.
Ova rijetko promijenjena smjernica utječe samo na pokretanje Apachea. Općenito se ne mijenja jer Apache koristi unutarnju logiku kako bi utvrdio koliko podređenih poslužitelja treba biti pokrenuto.
Mnogi moderni poslužitelji povremeno ponovno pokreću Apache radi rješavanja promjena u konfiguraciji, rotacije datoteka dnevnika ili drugih internih procesa. Ako se to dogodi tijekom naleta prometa s velikim opterećenjem, dolazi do zastoja koji ova diketiva umanjuje. Možete ručno postaviti StartServers direktivu da odražava onu na MinSpareServers kako bi skratili vrijeme pokretanja Apachea.
Direktiva StartServers trebala bi odražavati MinSpareServers.
ServerLimit
Direktiva ServerLimit predstavlja gornju granicu MaxRequestWorkers. Ova se postavka obično koristi kao zaštita ili gornja granica od ulaznih pogrešaka prilikom modificiranja MaxRequestWorkers.
Postaje potrebno prilagoditi ServerLimit kada se očekuje da poslužitelj istovremeno obrađuje više od zadanih 256 zahtjeva.
ServerLimit se izravno veže za točku razbijanja. Točka razbijanja je maksimalan broj djece koju Apache može pokrenuti prije nego što dođe do spremanja u trajnu sporu SWAP memoriju. Uskladite ServerLimit s izračunatom vršnom točkom radi zaštite poslužitelja.
Povećavanje ServerLimita se ne preporučuje s MPM Preforkom. Pokretanje više od 256 istodobnih zahtjeva hardverski je intenzivno kada se koristi modul MPM Prefork.
MaxConnectionsPerChild / MaxRequestsPerChild
Ova je direktiva jednaka broju zahtjeva koje jedan podređeni poslužitelj Apache može obraditi.
Ova je smjernica zapor za slučajno curenje memorije. Kôd izveden putem Apachea može sadržavati greške koje propuštaju memoriju. Ta se curenja vremenom zbrajaju i čine sve manje dijeljene memorije djeteta korisnom. Način oporavka od procurjele memorije je recikliranje zahvaćenog Apache podređenog postupka. Postavljanje ograničenja MaxConnectionsPerChild zaštitit će od ove vrste curenja memorije.
Osnovno pravilo nikad ne postaviti ovo prenisko. Ako poslužitelj naiđe na probleme s curenjem memorije, započnite s 10 000 i postupno smanjujte.