5 nasvetov za povečanje učinkovitosti vašega spletnega strežnika Apache


Po nedavnem poročilu podjetja Netcraft (znanega internetnega podjetja, ki med drugim ponuja tudi statistiko uporabe spletnih brskalnikov) je Apache še vedno najpogosteje uporabljen spletni strežnik med spletnimi mesti in računalniki, obrnjenimi na internet.

Poleg tega Apache še naprej beleži največjo rast med najboljšimi spletnimi strežniki, sledita Nginx in IIS. Če ste torej skrbnik sistema, ki je odgovoren za upravljanje namestitev Apache, morate vedeti, kako zagotoviti, da vaš spletni strežnik deluje najbolje, kot ustreza svojim potrebam (ali potrebam vaše stranke).

V tem članku bomo obravnavali nekaj nasvetov, ki vam bodo pomagali zagotoviti, da bo Apache deloval nemoteno in bo lahko obravnaval število zahtev, ki jih pričakujete od oddaljenih odjemalcev.

Upoštevajte pa, da Apache ni bil zasnovan z namenom postavljanja referenčnih zapisov - vendar kljub temu še vedno lahko zagotavlja visoko zmogljivost v skoraj vseh primerih uporabe, ki si jih lahko omislite.

NAMIG # 1: Apache naj bo vedno posodobljen na najnovejšo različico

Samoumevno je, da je namestitev najnovejše različice Apache verjetno ena prvih stvari, ki jih morate upoštevati. Od 19. novembra 2015 je najnovejša različica Apacheja, ki je na voljo v skladiščih CentOS 7, 2.4.6, medtem ko je v Debianovih 2.4.10.

Vendar je morda prišlo do nedavnega izboljšanja ali odprave napak, ki je bila dodana na novo izdani stabilni različici, ki je nato na voljo za prenos in namestitev iz vira. Navodila za prevajanje in namestitev so prav tako na voljo tukaj - ne pozabite, da če izberete to metodo posodobitve, boste morda želeli varnostno kopirati trenutne konfiguracijske datoteke/spletna mesta/navidezne gostitelje.

V vsakem primeru lahko trenutno nameščeno različico preverite na naslednji način:

# httpd -v               [On RedHat/CentOS based systems]
# apache2 –v             [On Debian/Ubuntu based systems] 

Kot pravilo se držite metode posodabljanja, ki jo nudi upravitelj paketov izbrane distribucije ( yum update httpd ali aptitude safe-upgrade apache2 , za CentOS ali Debian, ), razen če ni druge poti. Najnovejše opombe ob izdaji si lahko preberete v razdelku Apache Dokumentacija na spletnem mestu Apache HTTP Server Project.

NASVET št. 2: Če uporabljate jedro, starejše od 2,4, nadgradite zdaj

Zakaj? V jedru različice 2.4 in novejših je sistemski klic jedra sendfile privzeto omogočen. To pa olajša visoko zmogljive prenose datotek v omrežju (kar je zaželeno v okviru komunikacije med spletnim strežnikom in odjemalcem) in omogoča Apacheu, da hitreje in z nižjo izkoriščenostjo CPU zagotavlja statične vsebine z izvajanjem hkratnih operacij branja in pošiljanja.

Trenutno nameščeno jedro si lahko ogledate z:

# uname -r

in ga primerjajte z najnovejšim stabilnim jedrom na www.kernel.org (4.3 v času pisanja tega dokumenta).

Čeprav gre za postopek, ki ni namenjen začetnikom, je nadgradnja jedra zanimiva vaja, če želite izvedeti več o notranjih delih Linuxa.

NASVET št. 3: Izberite večprocesorski modul (MPM), ki najbolje ustreza vašemu primeru

V praksi MPM-ji razširjajo modularno funkcionalnost Apacheja tako, da se lahko odločite, kako konfigurirati spletni strežnik tako, da se veže na omrežna vrata na računalniku, sprejema zahteve odjemalcev in za podrejanje takšnih zahtev uporablja podrejene procese (in niti).

Začenši z različico 2.4, Apache ponuja tri različne MPM-je na izbiro, odvisno od vaših potreb:

  1. prefork MPM uporablja več podrejenih procesov brez navojev. Vsak postopek obravnava eno povezavo naenkrat, ne da bi za vsako ustvaril ločene niti. Ne da bi se spuščali v preveč podrobnosti, lahko rečemo, da boste želeli ta MPM uporabljati samo pri odpravljanju napak aplikacije, ki uporablja ali če se mora vaša aplikacija ukvarjati z moduli, ki niso varni za nit, kot je mod_php.
  2. worker MPM uporablja več niti na podrejene procese, pri čemer vsaka nit obravnava eno povezavo hkrati. To je dobra izbira za strežnike z velikim prometom, saj omogoča več sočasnih povezav z manj RAM-a kot v prejšnjem primeru.
  3. Končno je event MPM privzeti MPM v večini namestitev Apache za različice 2.4 in novejše. Podoben je delovnemu MPM, saj ustvarja tudi več niti na podrejeni proces, vendar s prednostjo: povzroči, da KeepAlive ali nedejavne povezave (medtem ko ostanejo v tem stanju) obravnava ena nit, s čimer se sprosti pomnilnik, ki lahko se dodeli drugim nitim. Ta MPM ni primeren za uporabo z moduli, ki niso varni za nit, kot je mod_php, za katere je treba namesto tega uporabiti nadomestni PHP-FPM.

Če želite preveriti MPM, ki ga uporablja namestitev Apache, lahko:

# httpd -V

Spodnja slika prikazuje, da ta spletni strežnik uporablja predfork MPM.

Če želite to spremeniti, boste morali urediti:

# /etc/httpd/conf.modules.d/00-mpm.conf          [On RedHat/CentOS based systems]
# /etc/apache2/mods-available/<mpm>.load   [On Debian/Ubuntu based systems]

Kjer je lahko mpm_event, mpm_worker ali mpm_prefork.

in razkomentirajte vrstico, ki naloži želeni modul, tako:

LoadModule mpm_event_module modules/mod_mpm_event.so

Opomba: Če želite, da MPM dogodka deluje v Debianu, boste morda morali namestiti paket libapache2-mod-fastcgi iz neslobodnih skladišč.

Poleg tega boste za CentOS potrebovali php-fpm (skupaj s fcgi in mod_fcgid), medtem ko se v Debianu imenuje php5-fpm (skupaj z apache2-mpm-event).

Nenazadnje znova zaženite spletni strežnik in novo nameščeno storitev php-fpm (ali php5-fpm):

# systemctl restart httpd php-fpm && systemctl enable httpd php-fpm
# systemctl restart apache2 php5-fpm && systemctl enable apache2 php5-fpm

Čeprav lahko Apache nastavite tako, da uporablja določen MPM, lahko to konfiguracijo preglasite na osnovi vsakega navideznega gostitelja na enak način, kot je navedeno prej.

Preprosto spustite ustrezne oznake v konfiguracijsko datoteko za vsakega navideznega gostitelja in že ste pripravljeni - vendar se prepričajte, da uporabljate en in samo en MPM na vhost.

Na koncu upoštevajte, da se php-fpm ne glede na izbrano distribucijo zanaša na izvajanje FastCGI, zato sem prej priporočil namestitev dodatnih paketov.

Za več podrobnosti in primere o php-fpm in kako lahko skupaj z dogodkom MPM poveča zmogljivost Apacheja, se obrnite na uradno dokumentacijo.

To je tisto, kar vidim po spremembi privzetega MPM iz predforka v dogodek v istem polju, prikazanem na prejšnji sliki:

V CentOS 7 se morate prepričati, da so storitve http in https omogočene prek požarnega zidu in ali so omrežni vmesniki pravilno dodani v privzeto območje.

Na primer:

# firewall-cmd --zone=internal --add-interface=tun6to4 
# firewall-cmd --zone=internal --add-interface=tun6to4 --permanent 
# firewall-cmd --set-default-zone=internal 
# firewall-cmd --add-service=http 
# firewall-cmd --add-service=https 
# firewall-cmd --add-service=http --permanent 
# firewall-cmd --add-service=https --permanent 
# firewall-cmd --reload

Razlog za to je, ker sem pred kratkim naletel na težavo, ko so privzete nastavitve konfiguracije požarnega zidu v oblaku VPS preprečevale php-fpm in Apache obdelavo datotek php.

Kot osnovni test (prepričan sem, da si lahko omislite bolj zapletene ali stresne) bom ustvaril php datoteko, ki preveri obstoj druge datoteke z imenom test.php v istem imeniku dveh CentOS 7 strežnikov z enakimi značilnostmi strojne opreme in obremenitvijo, vendar z različnimi MPM. Eden od njih bo uporabil dogodek, drugi pa predfork:

To je php koda, ki sem jo shranil v datoteko z imenom checkiffileexists.php :

<?php
$filename = 'test.php';

if (file_exists($filename)) {
    echo "The file $filename exists";
} else {
    echo "The file $filename does not exist";
}
?>

Nato bomo zagnali orodje primerjalne analize Apache (ab) z 200 hkratnimi zahtevami, dokler ne bo dokončanih 2000 zahtev:

# ab -k -c 100 -n 2000 localhost/checkiffileexists.php

Zaženimo test in primerjamo rezultate. Bodite pozorni na statistiko uspešnosti:

Kot lahko vidite, je zmogljivost strežnika z dogodkom v vseh pogledih tega testa zelo boljša od predhodne.

NASVET # 4: Pametno dodelite RAM za Apache

Morda je najbolj kritična postavka strojne opreme, ki jo je treba upoštevati, količina RAM-a, dodeljena za vsak postopek Apache. Čeprav tega ne morete neposredno nadzorovati, lahko omejite število podrejenih procesov z direktivo MaxRequestWorkers (prej v Apache 2.2 imenovano MaxClients), ki bo omejila uporabo RAM-a s strani Apache. Tudi to vrednost lahko nastavite na gostitelja ali navideznega gostitelja.

Če želite to narediti, si zabeležite povprečno količino RAM-a, ki jo uporablja Apache, nato jo pomnožite s številom MaxRequestWorkers in to je količina pomnilnika, ki bo dodeljena za procese Apache. Ena stvar, ki je nikoli ne želite, da vaš spletni strežnik naredi, je začeti uporabljati swap, saj bo to znatno zmanjšalo njegovo zmogljivost. Zato morate vedno uporabljati RAM RAM v Apacheju v mejah, ki si jih lahko privoščite, in se nikoli ne zanašajte na zamenjavo zanj.

Naslednji blok bo na primer omejil število hkratnih odjemalcev na 30. Če več odjemalcev zadeva gostitelja, lahko pride do zamude ali trenutne okvare, ki jo je mogoče enostavno rešiti z osvežitvijo brskalnika. Čeprav je to morda nezaželeno, je bolj zdravo za strežnik in dolgoročno, najbolje tudi za vaše spletno mesto.

Ta blok lahko namestite v /etc/httpd/conf/httpd.conf ali /etc/apache2/apache2.conf , odvisno od tega, ali uporabljate CentOS ali Debian.

Upoštevajte, da enako načelo velja za vse MPM - tukaj uporabljam dogodek, da nadaljujem s konceptom, opisanim v prejšnjem nasvetu:

<IfModule mpm_event_module>
    StartServers 3
    MinSpareThreads          25
    MaxSpareThreads          75
    ThreadLimit                      64
    ThreadsPerChild          25
    MaxRequestWorkers    30
    MaxConnectionsPerChild    1000
</IfModule>

V vsakem primeru je zelo priporočljivo, da si ogledate dokumente Apache 2.4, da vidite, katere smernice so dovoljene za izbrani MPM.

NASVET # 5: Spoznajte svoje aplikacije

Kot pravilo ne smete nalagati modulov Apache, ki niso nujno potrebni za delovanje vaše aplikacije. To bo zahtevalo vsaj splošno znanje o aplikacijah, ki se izvajajo v vašem strežniku, še posebej, če ste skrbnik sistema in je za razvoj zadolžena druga skupina.

Trenutno naložene module lahko navedete z:

# httpd -M          [On RedHat/CentOS based systems]
# apache2ctl -M     [On Debian/Ubuntu based systems]

Za razkladanje/onemogočanje modulov v CentOS-u boste morali komentirati vrstico, ki se začne z LoadModule (bodisi v glavni konfiguracijski datoteki bodisi v pomožni v /etc/httpd/conf.modules.d.

Po drugi strani Debian ponuja orodje a2dismod za onemogočanje modulov in se uporablja na naslednji način:

# a2dismod module_name

Če ga želite znova omogočiti:

# a2enmod module_name

V obeh primerih ne pozabite znova zagnati Apache, da bodo spremembe začele veljati.

Povzetek

V tem članku smo pregledali 5 nasvetov, ki vam bodo pomagali prilagoditi spletni strežnik Apache in povečati njegovo zmogljivost. Poleg tega se morate zavedati, da sta optimizacija in delovanje brez varnosti nesmiselna, zato boste morda želeli prebrati tudi članek z nasveti za strjevanje Apacheja na linux-console.net.

Ker v tem članku ne moremo ustrezno zajeti vseh vidikov te teme, boste morda pomislili na druge ideje, ki bi jih radi delili s preostalo skupnostjo. V tem primeru nam to sporočite s pomočjo spodnjega obrazca za komentar.