Veebilehe populaarsus pole mitte ainult kasu, vaid ka täiendav peavalu süsteemiadministraatorile. Kuna külastajate voog suureneb, siis tekitab see suurema koormuse serverile, mis aja jooksul enam oma kohustustega toime ei tule. Siinkohal kerkib küsimus riistvara ostmisest, mille võib aga edasi lükata parematesse aegadesse. Sellest artiklist saate teada, kuidas panna server laadima ka siis, kui see keeldub seda tegemast.
Veebilehe populaarsus pole mitte ainult kasu, vaid ka täiendav peavalu süsteemiadministraatorile. Kuna külastajate voog suureneb, tekitab see järjest suurema koormuse serverile, mis aja jooksul lihtsalt lakkab oma kohustustega toime tulema. Siinkohal kerkib küsimus riistvara soetamisest, mille võib aga edasi lükata paremate aegadeni. Sellest artiklist saate teada, kuidas panna server laadima ka siis, kui see keeldub seda tegemast.
Oletame, et teie käsutuses on veebiserver, millel töötab enam-vähem külastatav dünaamiline veebisait, mis on loodud ühe PHP CMS-i alusel. Üldiselt on olukord kaasaegse RuNeti jaoks kõige tüüpilisem. Sait areneb, kasvab, külastajaid on üha rohkem ja hakkate märkama järk-järgult suurenevaid viivitusi sisu edastamise kiiruses. Lihtsamad mõõtmised näitavad, et server ei saa enam talle pandud ülesannetega hakkama ning pähe hakkavad pugema tigedad mõtted riistvara ostmisest (võimsama virtuaalserveri rentimine). Kuid enamikul juhtudel pole vaja kiirustada, olukorda on lihtne enda kasuks pöörata.
See artikkel räägib teile, kuidas oma serverit optimeerida ja kliendi osa veebisait suure koormuse all. Arutelu käigus käsitleme järgmisi teemasid:
- Apache optimeerimine;
- PHP optimeerimine;
- eAcceleratori paigaldamine;
- Nginxi installimine esiotsaks;
- Installige Memcached;
- Kliendi optimeerimine.
Apache optimeerimine
Enamiku kaasaegsete veebisaitide juurkomponent on loomulikult Apache. See on ennast tõestanud kui kõige funktsionaalsem, stabiilsem ja hõlpsamini kasutatav HTTP-server, mida saab kasutada nii kodulehe teenindamiseks kui ka suure koormusega ettevõtte internetiprojektide jaoks. Üks probleem: Apache on väga raske rakendus, mis vajab serveriressursse.
Ja seda tuleks selle seadistamisel arvestada. Siin on nimekiri soovitustest, mida HTTP-serveri tööks ettevalmistamisel kõige paremini järgida:
- Lõviosa Apache funktsionaalsusest sisalduvad laaditavates moodulites, mida saab aktiveerida või keelata konfiguratsioonifaili redigeerides (LoadModule direktiiv). Hea tava on kõik kasutamata moodulid täielikult keelata, mis parandab serveri jõudlust ja säästab RAM-i.
- Apache töötleb iga uut päringut oma lõimes ja võimaldab teil selle toimingu tegemiseks kasutada erinevaid lähenemisviise. Kui ehitasite Apache2 lähtekoodist, võisite märgata, et ehitussuvandites on võimalus valida nn MPM. See on mitmiktöötlusmoodul, mida kasutatakse HTTP-serveri paralleelseks muutmiseks.
Kokku on neid kolm:
- prefork on klassikaline MPM, mis rakendab Apache 1.3-s kasutatavat multitöötlusmudelit. Iga lõime töödeldakse eraldi protsessis. Mitte kõige produktiivsem variant, kuid kõige stabiilsem. Vaikimisi kasutatakse.
- töötaja – lõimepõhine MPM. Server loob mitu protsessi, millest igaühel on mitu lõime. Üks taotlus – üks lõng. Prefork on produktiivsem, kuid vähem stabiilne.
- sündmus - sündmus MPM. Lõimede asemel töödeldakse päringuid sündmusepõhise mudeli abil, mis sarnaneb nginxis kasutatava mudeliga. Kõige produktiivsem MPM, kuid ka kõige vähem stabiilne (on eksperimentaalses arendusetapis).
Paljud distributsioonid võimaldavad teil installida Apache erinevaid variante, mis erinevad kasutatava MPM-i poolest, neid saab hoidlast hõlpsasti leida, otsides "apache2-mpm".
- Apache võimaldab teil kontrollida maksimaalne summa lõid lõime, kasutades valikut MaxClients. Vastasel juhul ärge seadke selle väärtust liiga kõrgeks teatud hetk server ammendab kogu RAM-i, hakkab vahetama ja palju rohkem kliente jääb teenindamata, kui see oleks range limiidi korral. Optimaalne väärtus võrdub Apache'i käsutuses oleva mälumahuga, mis on jagatud tekitatud lõime maksimaalse suurusega (kontrollitakse ps-i või top abil).
- Nagu paljud teised HTTP-serverid, võimaldab Apache juhtida elushoidmise ühenduste kestust, mida kasutatakse ühe ühenduse jooksul mitme päringu/vastuse saatmiseks. Keep-alive võimaldab säästa serveri ressursse, ilma et oleks sunnitud looma iga pildi, CSS-i ja muude leheelementide jaoks eraldi lõime. Sellist ühendust ei tohiks aga liiga kaua lahti hoida, sest ka see võtab ressursse. Hea väärtus KeepAliveTimeout valiku puhul oleks 5-10 sekundit ja kui kõik lehe sõltuvad komponendid saadetakse kliendile eraldi serverite kaudu ja praegust serverit kasutatakse ainult HTML/PHP teenindamiseks, pole vaja toetada keep-alive üldse ja parem on seada KeepAlive suvandi väärtuseks Off.
- Apache'ile ei meeldi tihendamine. Kui otsustate tihendamise abil lehe edastamise kiirust suurendada, siis pidage meeles, et suure tõenäosusega tekitab see serverile veelgi suurema koormuse. Kui tihendamine on tõesti vajalik (näiteks mobiiliportaal, mille peamine klientide voog kasutab GPRS-kanalit), siis määrake tihendusaste minimaalseks, see toob kaasa vaid mõningase saadud andmete mahu suurenemise, kuid säästab oluliselt serveriressursse.
PHP optimeerimine
Sageli kõige raskem koormus Seda ei loo üldse HTTP-server, vaid dünaamilise veebisaidi sisu loomiseks kasutatava programmeerimiskeele tõlk. Tänapäeval on serveripoolse veebiskriptimise kõige populaarsem keel PHP, seega keskendume oma artiklis sellele. Avage fail /etc/php5/apache2/php.ini (Ubuntu tee, võib teistes distributsioonides erineda) ja redigeerige järgmisi ridu:
- memory_limit – veebilehe loomisel tarbitava mälu piirang. Enne selle parameetri muutmist on soovitatav läbi viia asjakohased mõõtmised ja põhineda väärtus nende tulemustel.
- display_errors = Väljas, error_log = /var/log/php – suunab veateated ümber logifaili. Luba see suvand, kui kõik skriptid on täielikult silutud.
- upload_max_filesize ja post_max_size – üleslaaditud failide ja POST-i päringute maksimaalne suurus. Jällegi tuleks väärtus valida teie veebirakenduse vajaduste põhjal.
Nüüd saate faili sulgeda ja käivitada sügav optimeerimine PHP kiirendi kasutamine.
Kiirendi installimine
PHP on tõlgitav keel. See tähendab, et iga kord, kui selles keeles skripti kutsutakse, käivitatakse PHP-tõlk, mis viib läbi täieliku analüüsi lähtekood. Veelgi enam, kui sekund hiljem sama skript uuesti käivitatakse, korratakse kogu protseduuri uuesti. See on ressursside raiskamine, seega kasutame tööriista nimega eAccelerator, mis kompileerib PHP lähtekoodi binaarseks vormiks, optimeerib selle ja salvestab selle hoolikalt muutmälu rohkemate jaoks kiire juurdepääs. Ainuüksi tänu sellele tõuseb PHP skriptide töötlemise kiirus kümnekordseks (seda kinnitavad testid).
Pakett eAccelerator pole populaarsete distributsioonide hoidlates saadaval, seega peate selle ise looma. Esmalt installige kokkupanekuks vajalikud kommunaalteenused:
$ sudo apt-get install php5-dev build-essential
$ cd /tmp/
$ wget http://bart.eaccelerator.net/source/0.9.6.1/
kiirendi-0.9.6.1.tar.bz2
$tar xvjf kiirendi-0.9.6.1.tar.bz2
$cd kiirendi-0.9.6.1
$ phpize
$ ./configure --enable-eaccelerator=shared
$ teha
$ sudo make install
Looge vahemälu salvestamiseks kataloog:
$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator
Ja lõpuks ühendage eAccelerator PHP-ga (lisage faili algusesse):
# vi /etc/php5/apache2/php.ini
; Pikenduse ühendamine
laiend = "kiirendaja.so"
eaccelerator.enable = "1"
; Maksimaalne suurus ketta vahemälu(MB)
eaccelerator.shm_size = "64"
; Vahemälu salvestuskataloog
eaccelerator.cache_dir = "/var/cache/eaccelerator"
; Luba koodi optimeerija
eaccelerator.optimizer = "1"
; Kompileerige muudetud skriptid uuesti
eaccelerator.check_mtime = "1"
; Keela silumisrežiim
eaccelerator.debug = "0"
; Vahemällu kõik failid (tühi filter)
eaccelerator.filter = ""
; Piiramatu suurus vahemälu mällu
eaccelerator.shm_max = "0"
; Kui vahemälus pole ruumi, kustutage objektid, mis on vanemad kui
1 tund (3600 sekundit)
eaccelerator.shm_ttl = "3600"
eaccelerator.shm_prune_period = "0"
; Vahemällu andmed nii mällu kui ka kettale
eaccelerator.shm_only = "0"
; Tihendage vahemällu salvestatud andmed maksimaalse tihendustasemega
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
Nginxi installimine
Olles populaarne, võib suur dünaamiline veebisait tekitada serverile sellise koormuse, et Apache hakkab lämbuma ja sülitama.
Ja asi pole siin isegi selles, et riistvara seda ei võimalda, vaid HTTP-serveri enda raskus. Apache sobib suurepäraselt dünaamilise sisu teenindamiseks, kuid enamik kaasaegseid veebilehti on ühel või teisel viisil staatilised ning nende teenindamiseks võimsa, keeruka ja väga raske HTTP-serveri kasutamine oleks sama rumal kui maastikusõidukiga sõitmine Eesti teedel. Šveits. Kasutame kerget Nginxi HTTP-serverit Apache'i mahalaadimiseks ja vabastame selle tänamatust staatilise sisu teenindamise ülesandest. Erinevalt Apache'ist kasutab Nginx sündmustepõhist päringute töötlemise mudelit, mis nõuab suvalise arvu klientide jaoks ainult ühte HTTP-serveri protsessi.
See vähendab oluliselt riistvara koormust, kuid tekitab teatud probleeme dünaamilise sisu töötlemisel (sellepärast ei kasutata seda peamise HTTP-serverina). Tavaliselt installitakse Nginx spetsiaalsesse masinasse, mis on näoga välisvõrk ja toimib esimese kontrollpunktina päringu tee ääres, kuid üks võimalus füüsiline server, kui Apache ja Nginx töötavad samas masinas. Peatume sellel. Avage fail /etc/apache2/ports.conf ja muutke kahte valikut:
NameVirtualHost *:81
Kuulake 81
Järgmisena installige Nginx:
$ sudo apt-get install nginx
Avage konfiguratsioonifail ja kirjutage sinna järgmine tekst:
# vi /etc/nginx/nginx.conf
# Nginxi kasutaja
kasutaja www-andmed;
# Määrake Nginxi protsesside arv võrdseks arvuga
protsessori tuumad
töötaja_protsessid 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
sündmused (
töötaja_ühendused 1024;
}
http (
# Standardseaded
sisaldab /etc/nginx/mime.types;
default_type application/octett-stream;
server_names_hash_bucket_size 64;
access_log /var/log/nginx/access.log;
saatmisfail sees;
#tcp_nopush sees;
#keepalive_timeout 0;
Keepalive_timeout 65;
tcp_nodelay sees;
# Luba tihendamine
gzip sees;
gzip_proxyed any;
gzip_min_length 1100;
gzip_http_versioon 1.0;
gzip_buffers 4 8k;
gzip_comp_level 9;
gzip_types text/plain text/css application/
x-javascripti tekst/xml-rakendus/xml
rakendus/xml+rss tekst/javascript;
sisaldab /etc/nginx/conf.d/*.conf;
sisaldab /etc/nginx/sites-enabled/*;
}
Loome oma hosti konfiguratsiooni:
# vi /etc/nginx/sites-enabled/host.com
server (
kuula 80;
serveri_nimi host.com;
access_log /var/log/nginx.access_log;
# Nginx pakub kogu staatika iseseisvalt
asukoht ~* \.(jpg|jpeg|gif|png|css|js|zip|
tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bm
p|rtf|swf|ico|flv|txt|xml|docx|xlsx)$ (
juur /var/www/host.com/;
indeks indeks.html index.php;
access_log off;
aegub 30 p;
}
# Juurdepääs failidele nagu .htaccess on keelatud
asukoht ~ /\.ht (
keelata kõik;
}
# Kõik muu sisu taotlused edastatakse Apache'ile
asukoht/(
proxy_pass http://127.0.0.1:81/;
puhverserveri_komplekti_päis X-Real-IP $kaug-addr;
proxy_set_header X-Forwarded-for $ Remote_
adr;
proxy_set_header Host $host;
proxy_connect_timeout 60;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_redirect off;
proxy_set_header Ühenduse sulgemine;
proxy_pass_header Content-Type;
proxy_pass_header Content-Disposition;
proxy_pass_header Content-Length;
}
}
See on kõik, taaskäivitage Apache ja Nginx:
$ sudo teenuse apache2 taaskäivitamine
$ sudo teenus nginx taaskäivitage
Memcachedi installimine
Memcached on mälusisene andmete vahemällu salvestamise süsteem, mida saab kasutada hajutatud salvestuseks ja mis tahes tüüpi andmetele juurdepääsu kiirendamiseks.
See on üks populaarsemaid lahendusi veebisaidi täieliku optimeerimise valdkonnas suure koormuse jaoks, mis ei nõua seadistamist ega ulatuslikku API õppimist. Tavaliselt kasutavad memcachedi nii-öelda kaks osapoolt, kellest üks paneb andmed vahemällu ja teine hangib need alla. Veebikeskkonnas täidab esimese osapoole rolli tavaliselt väike PHP-skript, mis kirjutab olulised (üleslaadimiskiiruse seisukohalt) andmed memcachedisse, teiseks osapooleks on aga tavaliselt kerge esiserver (tavaliselt nginx), mis kasutab spetsiaalne moodul memcached andmete lugemiseks ja tagastamiseks. Memcachedi kasutatakse sageli veebisaidi tervete lehtede vahemällu salvestamiseks, suurendades seeläbi nendele lehtedele juurdepääsu kiirust mitme suurusjärgu võrra. Lihtsamal juhul näeb see konfiguratsioon välja järgmine:
1. Installige memcached:
$ sudo apt-get install memcached
2. Nginxi konfiguratsioonifaili serveri jaotisesse lisatakse järgmine teave:
# vi /etc/nginx/nginx.conf
asukoht/(
# Määrake vahemällu salvestatud võti võrdseks soovitud võtmega
URI
määra $memcached_key $uri;
# Vahemällu salvestatud deemoni aadress ja port
memcached_pass 127.0.0.1:11211;
# Vaikepealkiri
vaikimisi_tüüp text/html;
# Kui andmeid vahemälust ei leita, küsime neid taustaprogrammist
error_page 404 = /varu;
}
asukoht /varu (
proxy_pass taustaprogramm;
}
3. PHP jaoks on installitud memcache laiendus (klient memcached jaoks):
$ sudo pecl installige memcache
4. Lehtedele on manustatud järgmine kood:
$ vi smaple.php
# Vahemällu salvestatud lähtestamine on välja jäetud
ob_start();
$html = ob_get_clean();
$memcache->set($_SERVER["REQUEST_URI"], $html);
kaja $html;
See kõik töötab suurepäraselt, kuid ainult väga lihtsate, peaaegu staatiliste veebisaitide puhul. Asi on selles, et leht ei pea alati olema kõikide külastajate jaoks ühesugune. Mis siis, kui külastaja saidile sisenedes salvestatakse avaleht vahemällu ja pärast seda tuleb registreerunud osaleja saidile ja palutakse uuesti registreeruda.
Häire. Sellest olukorrast on aga üsna lihtne väljapääs. Probleemi saab lahendada sambla ja ämblikuvõrkudega kaetud tehnoloogiaga, mida nimetatakse SSI-ks (Server Side Includes). SSI võimaldab jagada veebilehe mitmeks plokiks, mille kliendi päringu töötlemise ajal esiots kokku paneb. Näiteks SSI-d kasutades jagate veebisaidi avalehe kaheks osaks:
# vi /var/www/index.php
See on täpselt sama leht, mille autentimiskood on paigutatud faili auth.php ja ülejäänud leht on body.php-s. Keeruline on see, et asetate ülaltoodud neljandas etapis antud vahemällu salvestatud koodi ainult teise faili. Selle tulemusena tekib järgmine pilt:
- Inimene tuleb saidile esimest korda. Veebisaidi avaleht palutakse nginxile.
- Nginxi server pärib taustaprogrammist (Apache) faili index.php, kohtab selle sees SSI-direktiive ja teeb *2* lisapäringut taustaprogrammile (auth.php ja body.php).
- Taotluste saamisel käivitab Apache PHP tõlgi, et töödelda nõutud faile, mille tulemuseks on (muu hulgas) sisu raske fail body.php satub vahemällu salvestatud vahemällu.
- Vastuse tagastab nginx, mis ühendab failid üheks indeksiks. php ja annab need kliendile.
- Pärast seda saabub saidile registreerunud osaleja, tagaosast pärineb index.php (kuigi tõenäoliselt võetakse see nginxi enda vahemälust), kuid ainult lihtne ja lihtne autentimine. php päring läheb Apache'i, body.php aga võetakse vahemällu salvestatud vahemälust.
On ütlematagi selge, et SSI peab olema nginxi konfiguratsioonifailis lubatud, kasutades jaotisesse „Location /” asetatud suvandit „ssi on”. Tasub teada, et auth.php plokki saab ka vahemällu salvestada, kuid selleks peate määrama kõigile registreeritud kasutajatele identifikaatori, salvestama selle küpsistesse ja kasutama seda unikaalse memcached võtme genereerimiseks.
Kliendi optimeerimine
See artikkel on pühendatud veebisaitide serveripoolsele optimeerimisele, kuid oleks jumalateotus mitte rääkida selle protsessi kliendipoolsest osast. Seetõttu vaatame lühidalt läbi soovituste loendi, mille eesmärk on minimeerida edastatavate andmete koguhulk:
- Kasutage lehtede ja andmete tihendamiseks gzipi või tühjendamist. Selleks saate kasutada HTTP-serveri mooduleid: ngx_http_gzip_module nginxi jaoks, mod_compress lighttpd jaoks ja mod_deflate Apache jaoks.
- Optimeerimiseks ja eemaldamiseks kasutage pakkijaid liigne prügi HTML-ist ja JavaScriptist (tavaliselt eemaldavad need kõik kommentaarid ja tühikud, asendavad nimed lühematega jne, näiteks web-optimizator, code.google.com/p/web-optimizator).
- Pane CSS ja JavaScript kood eraldi failidesse, siis saab brauser need vahemällu salvestada ja teistele lehtedele rakendada (saab ka panna eraldi serverisse, et need paralleelselt laadiksid).
- Lehe sujuvamaks ja korrektsemaks laadimiseks brauseri poolt asetage CSS-i laadimine lehe alguses ja JavaScripti lõpus.
- Ärge unustage installida Aegub päised ja vahemälu juhtimine, et brauser saaks CSS-i ja JavaScripti vahemällu salvestada.
- Ärge kasutage JPG-d ja PNG-d, kui saate kasutada GIF-i (nt väikeste ikoonide jaoks).
Tasakaalustamine
Round robin DNS on üks lihtsamaid koormuse tasakaalustamise tüüpe. Selle rakendamiseks piisab kahe või enama serveri IP-aadresside määramisest ühele domeeninimele. Siiski on ka oluline miinus: kui mõni serveritest ebaõnnestub, saadetakse mõni klient ikkagi sellele.
puhverdatud
Kui on piisavalt suured mahud mälu, hea tava on käivitada memcached deemon lipuga '-L'. Selle tulemusena valmistab deemon kogu talle eraldatud mälu eelnevalt kasutamiseks ette. See parandab veidi memcachedi üldist jõudlust, välistades vajaduse töötamise ajal pidevalt mälu eraldada.
Kuidas suurendada serveri jõudlust CentOS OS-is. Kolmas osa: veebiserveri sätete kiire optimeerimine.
Selles artiklis räägime teile, kuidas suurendada serveri (pühendatud või virtuaalse) jõudlust, kasutades näitena CentOS OS-i, optimeerides kiiresti Nginxi ja Apache (httpd) veebiserveri sätteid.
Materjal on suunatud väheste administreerimisalaste teadmistega kasutajatele, vaatleme lihtsamaid ja samal ajal tõhusaid viise serveri jõudluse suurendamiseks. Selles artiklis me ei räägi selle eesmärgist ja kirjeldame kõiki selle seadeid, puudutame ainult kõige vajalikumaid punkte. Artikkel on asjakohane mis tahes juhtpaneeli jaoks, seega ei jaga me paneelideks.
Serveriga on optimaalne töötada SSH kaudu, kuid kui teil on raskusi SSH-ga töötades, saate faile avada juhtpaneeli failihalduri kaudu. (SSH-ga töötamise juhised selle artikli esimeses osas)
Apache veebiserveri sätete optimeerimine (httpd).
Apache veebiserveri konfiguratsioonifail asub järgmisel teel:
/etc/httpd/conf/httpd.conf
Selles failis peate konfigureerima piirangud samaaegselt töötavate veebiserveri protsesside arvule. Selleks leidke sellest rida MaxClients, plokk peaks välja nägema umbes selline:
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 256
MaxRequestsPer Child 0
Makskliendid tuleb arvutada teie serverisse installitud RAM-i hulga põhjal. Samuti peaksite arvestama ühe veebiserveri protsessi kasutatava mälumahuga. Ühe veebiserveri protsessi kulutatud mälumahu saate teada meie teadmistebaasi parima utiliidi, kasutusjuhiste abil.
Järgmisena loendage 2/3 oma serveri RAM-i kogumahust ja jagage ühe veebiserveri protsessi kulutatud mälumahuga. Saadud arv on MaxClientsi optimaalne väärtus.
Näiteks on meil server 8 GB muutmäluga. 2\3 8-st on 5,3 GB. Üks veebiserveri protsess kulutab tavaliselt umbes 40 MB mälu. Arvutame 5300MB \ 40MB, saame 132. Parem on ümardada allapoole. Jätame väärtuseks 130, mille tulemusena peaks konfiguratsioonifaili plokk välja nägema järgmine:
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 130
MaxRequestsPer Child 0
Lubage ka KeepAlive, selleks leidke konfiguratsioonifailist rida:
Hoidke elus väljas
Muutke Väljas olekuks Sees:
Hoidke elus edasi
Pärast muudatuste tegemist taaskäivitage veebiserver käsuga:
/etc/init.d/httpd taaskäivitage
Teeninduse httpd taaskäivitamine
Nginxi veebiserveri seadete optimeerimine.
Nginxi veebiserveri konfiguratsioonifail asub järgmisel teel:
/etc/nginx/nginx.conf
Selles peate konfigureerima Nginxi protsesside arvu. Tavaliselt sõltub see säte teie serverile saadaolevate protsessorituumade arvust. Direktiiv worker_processes vastutab selle eest konfiguratsioonifailis:
Kasutaja apache;
pid /var/run/nginx.pid;
töötaja_protsessid 4;
Nagu näete, on Nginxi protsesside arv konfigureeritud 4 protsessori tuuma jaoks. Kui teie server töötleb palju ühendusi, saate seda väärtust poole võrra suurendada, kui määrate suurema väärtuse, see maksab jõudlust.
Worker_rlimit_nofile 65536;
sündmused (
kasutada epolli;
töötaja_ühendused 65536;
}
See suurendab Nginxi piiranguid töödeldavate failide arvule ja parandab selle jõudlust. Kui worker_rlimit_nofile või worker_connections on teie konfiguratsioonifailis juba määratud, kustutage need ja jätke ainult plokk nagu näites.
Selle tulemusena peaks conf-faili algus välja nägema järgmine:
Kasutaja apache;
error_log /var/log/nginx/error.log hoiatus;
pid /var/run/nginx.pid;
töötaja_protsessid 4;
töötaja_rlimit_nofile 80000;
sündmused (
kasutada epolli;
töötaja_ühendused 65536;
}
http (
default_type application/octett-stream;
log_format main "$remote_addr - $remote_user [$time_local] "$request" "
"$status $body_bytes_sent "$http_referer" "
""$http_user_agent" "$http_x_forwarded_for"";
access_log /var/log/nginx/access.log põhi;
Access_log off;
(Saate vaadata ketta laadimist ülemise utiliidi abil)
Samuti saate Nginxis lubada Gzipi tihendamise. See võib teie saidi kiiremini laadida ja on kasulik ka SEO reklaamimine soovitame aga pärast Gzipi lubamist kontrollida allalaadimiskiirust, sest Paljude päringute arvuga saitidel võib sellel olla negatiivne mõju. To lubage Nginxis Gzip-tihendamine, peate selle lisama jaotisesse http (see kood:
Gzip sees;
gzip_comp_level 5;
gzip_min_length 10240;
gzip_disable "msie6";
Lisage see kood järgmisele reale pärast http ( Et see näeks välja järgmine:
Kasutage epolli;
töötaja_ühendused 65536;
}
http (
gzip sees;
gzip_comp_level 5;
gzip_min_length 10240;
gzip_proxyed aegunud no-cache no-store privaatne autentimine;
gzip_types text/plain text/css-rakendus/json-rakendus/x-javascripti tekst/xml-rakendus/xml-rakendus/xml+rss-tekst/javascripti rakendus/javascript;
gzip_disable "msie6";
sisaldab /etc/nginx/mime.types;
default_type application/octett-stream;
Kui allolevas koodis on Gzipi seaded, eemaldage need.
Pärast seadistamise lõpetamist taaskäivitage Nginx käsuga:
/etc/init.d/nginx taaskäivitage
Teenuse nginx taaskäivitamine
Varasemaid materjale serveri sätete optimeerimise kohta leiate järgmiste linkide kaudu:
Kui teil on serveri seadistamisel ja haldamisel raskusi, võite alati pöörduda meie tehnilise toe poole.
Mis aeglustab Apache'i ja kuidas PHP-st maksimumi võtta
Sisu seeria:
Linux, Apache, MySQL ja PHP (või Perl) loovad aluse veebirakenduste LAMP-arhitektuurile. Paljud paketid koos avatud lähtekoodiga, mis põhinevad LAMP-komponentidel, on saadaval paljude probleemide lahendamiseks. Rakenduste koormuse suurenedes muutuvad põhiinfrastruktuuri kitsaskohad selgemaks, mille tulemuseks on aeglasem reageerimisaeg kasutajate päringutele. See näitab Linuxi süsteemi seadistamist ning hõlmab LAMP-i ja jõudluse mõõtmise põhitõdesid. See artikkel keskendub veebiserveri komponentidele, nii Apache'ile kui ka PHP-le.
Apache seadistamine
Apache - osa tarkvara, lihtne kohandada. Sellel on palju funktsioone, kuid igaüks neist on väärtuslik. Osa Apache häälestusest seisneb ressursside õiges eraldamises ja hõlmab mittevajalike sätete keelamist.
Mitmeprotsessori moodulite konfigureerimine
Apache'i rakendus on selles mõttes modulaarne, et saate sellesse lihtsalt elemente lisada ja eemaldada. See modulaarne funktsioon Apache'i tuumas - haldus võrguühendused ja päringute saatmine – pakkuda multitöötlusmooduleid (Multi-Processing Modules, MPM). Moodulid võimaldavad teil kasutada lõime või isegi teisaldada Apache'i teise operatsioonisüsteemi.
Korraga saab aktiivne olla ainult üks mitme protsessori moodul ja see tuleb staatiliselt kompileerida kasutades --with-mpm= (tööline|eeltöö|sündmus) .
Traditsioonilist ühe protsessi päringu mudelit nimetatakse prefork. Uuem, niidipõhine mudel nimega töötaja, kasutab rohkema saamiseks mitut protsessi, millest igaühel on mitu lõime suur jõudlus madalamate üldkuludega. Lõpuks sündmus-- eksperimentaalne moodul, mis sisaldab erirühmad lõime" s erinevate ülesannete jaoks. Praegu kasutatava mitme protsessori mooduli määramiseks käivitage httpd -l .
Mitmeprotsessori mooduli valik sõltub paljudest teguritest. Sündmusmooduli keelamine, kui see on katseolekus, on valik lõimede ja lõimede puudumise vahel. Pealtnäha tundub, et lõime kasutamine on parem kui kahvli kasutamine, kui kõik põhimoodulid on lõimekindlad, sealhulgas kõik kasutatud. PHP raamatukogud. Prefork - rohkem turvaline valik; kui valite töötaja, peaksite tegema põhjalikud testid. Jõudluse kasv sõltub ka distributsioonis sisalduvatest raamatukogudest ja teie riistvarast.
Sõltumata sellest, millise mitme protsessori mooduli valite, peate selle vastavalt konfigureerima. Üldiselt hõlmab mooduli seadistamine selle kindlaksmääramist, kuidas Apache juhib töötavate töötajate arvu, olgu need lõimed või protsessid. Loendis 1 on näidatud preforki mooduli olulised konfiguratsioonivõimalused.
Loetelu 1. Preforki mitmeprotsessori mooduli konfigureerimine
Algserverid 50 MinSpareServerit 15 MaxSpareServerit 30 MaxClients 225 Max RequestsPer Child 4000Preforki moodulis uus protsess loodud päringu abil. Ooterežiimi protsessid on sissetulevate päringutega suhtlemiseks jõude, mis vähendab käivitamise ooteaega. Eelmine konfiguratsioon käivitab 50 protsessi kohe, kui veebiserver käivitub, ja püüab hoida 10 kuni 20 protsessi jõude töötavad serverid. Kõva protsessi limiit määratakse MaxClientsi abil. Isegi kui protsess suudab suhelda paljude järjestikuste päringutega, tapab Apache protsessid pärast 4000 ühendust, vähendades seeläbi mälulekke ohtu.
Mitmeprotsessori moodulite konfigureerimine lõime toega toimub sarnaselt, välja arvatud see, et peate määrama, kui palju lõime ja protsesse tuleks kasutada. Apache dokumentatsioon selgitab kõiki parameetreid ja vajalikke arvutusi.
Kasutatavate väärtuste valimine hõlmab katse-eksitusi. Kõige olulisem väärtus on MaxClients. Eesmärk on lubada piisavalt töötajaid või lõime, et server ei vahetaks lihtsalt vahetust. Kui taotlusi tuleb rohkem, kui on võimalik töödelda vähemalt saabunuid töödeldakse; teised on blokeeritud.
Kui MaxClients on liiga kõrge, ei saa kõik kliendid piisavalt kõrge tase teenus, kuna veebiserver üritab ühe protsessi välja lülitada, et lubada teisel käivitada. Liiga madala väärtuse määramine võib põhjustada teenuse osutamisest keeldumise. Suurenenud koormuse ajal töötavate protsesside arvu kontrollimine ja kõigi Apache protsesside kasutatava mälumahu analüüsimine annab teile selle väärtuse määramise kohta hea ülevaate. Kui määrate MaxClientsi väärtuse üle 256, peate määrama ServerLimit samale väärtusele; Lugege oma mitmeprotsessoriliste moodulite dokumentatsiooni hoolikalt kõigi kohaldatavate hoiatuste osas.
Käivitavate serverite arvu ja varuosade saadavuse määramine sõltub serveri rollist. Kui serveris töötab ainult Apache, võite kasutada madalat väärtust, nagu näidatud , kuna saate masinat täiel määral kasutada. Kui süsteemi kasutab ka andmebaas või muu server, peaksite piirama töötavate varuserverite arvu.
Tõhus valikute ja ülekirjutuste kasutamine
Iga taotlus, mida Apache töötleb, läbib keeruka reeglistiku, mis määrab mis tahes piirangud või erijuhised, mida veebiserver peab järgima. Juurdepääsu kaustale saab piirata konkreetse kausta IP-aadressiga või konfigureerida kasutajanime ja parooli. Need suvandid võimaldavad ka konkreetsete failide töötlemist, näiteks kui kataloogiloend on ette nähtud, määravad need ära, kuidas teatud tüübid failid või kas väljund tuleks tihendada.
Need konfiguratsioonid on näiteks httpd.conf konteinerite kujul,
Nimekiri 2. Juurkataloogile rakendatud kataloogi konteiner
Loendis 2 kehtib kataloogi ja /kataloogi siltidega piiratud konfiguratsioon antud kataloogile ja selle sisule – antud juhul juurkataloogile. Siin määrab märgend AllowOverride, et kasutajatel ei ole lubatud ühtegi valikut alistada (sellest lähemalt hiljem). Lubatud on suvand FollowSymLinks, mis võimaldab Apache'il näha päringu teenindamiseks varasemaid sümboolseid linke, isegi kui fail pole veebifaile sisaldavas kataloogis. See tähendab, et kui teie veebikataloogis olev fail on sümboolne link aadressile /etc/passwd, teenindab veebiserver faili edukalt, kui päring tuleb. Funktsiooni -FollowSymLinks kasutamine keelab selle funktsiooni ja sama päring põhjustab kliendile vea tagastamise.
Viimane stsenaarium tekitab muret kahel rindel. Esimene on jõudluse probleem. Kui FollowSymLinks on keelatud, peab Apache kontrollima iga failinime komponenti (katalooge ja faili ennast), et veenduda, et need pole sümboolsed lingid. See toob kaasa täiendavaid üldkulusid ketta laadimise näol. Kaasnev valik FollowSymLinksIfOwnerMatch järgib sümboolset linki, kui faili omanik on sama, mis lingi omanik. Sellel on toimivusele sama mõju kui sümboolse lingi jälgimise keelamisel. Parima jõudluse saavutamiseks kasutage valikuid alates .
Turvalisuse pärast mures olevad lugejad peaksid juba muretsema. Turvalisus on alati kompromiss funktsionaalsuse ja riski vahel. Sel juhul on funktsionaalsus kiirus ja risk hõlmab volitamata juurdepääsu süsteemifailidele. Leevendav tegur on see, et LAMP-rakendusserverid on tavaliselt pühendatud konkreetsele funktsioonile ja kasutajad ei saa luua potentsiaalselt ohtlikke sümboolseid linke. Kui on ülioluline lubada sümboolsete linkide kontrollimist, saate selle lubada ainult failisüsteemi kindlas piirkonnas, nagu on näidatud loendis 3.
Loetelu 3. FollowSymLinksi piirang kasutajakataloogi jaoks
3. loendis on kasutaja kodukataloogis olevas avalikus_html kataloogis suvand FollowSymLinks selle ja kõigi alamkataloogide jaoks keelatud.
Nagu olete näinud, saab suvandeid konfigureerida üksusepõhiselt hostserveri konfiguratsiooni kaudu. Kasutajad saavad iseseisvalt alistada serveri konfiguratsiooni (kui administraator lubab AllowOverrides), jättes kataloogist välja .htaccess-faili. See fail sisaldab täiendavaid serveridirektiive, mis laaditakse ja rakendatakse igale .htaccess-faili sisaldava kataloogi päringule. Vaatamata varasemale jutule, et süsteemis pole kasutajaid, kasutavad paljud LAMP-i rakendused seda funktsiooni juurdepääsu juhtimiseks ja URL-i ümberkirjutamiseks, seega on see kasulik selle toimimise mõistmiseks.
Kuigi avaldus AllowOverrides takistab kasutajatel teha asju, mida soovite, peab Apache siiski vaatama faili .htaccess, et näha, kas midagi on vaja teha. Ülemkataloog saab määratleda käskkirjad, mida tuleb alamkataloogi päringuga töödelda, mis tähendab, et Apache peab uurima ka iga kataloogipuu komponenti, mis viib soovitud failini. See on arusaadavalt suure kettaaktiivsuse põhjus päringu kohta.
Lihtsaim lahendus on mitte lubada ühtegi alistamist, mis tühistab vajaduse Apache kontrollib.htaccess-fail. Kõik erikonfiguratsioonid paigutatakse seejärel otse saidi httpd.conf. Loendis 4 on näidatud, mida tuleb failile httpd.conf lisada, et võimaldada kasutaja projektikataloogi paroolikontrolli, selle asemel, et panna teave .htaccess-faili ja tugineda AllowOverrides'ile.
Nimekiri 4. Htaccessi konfiguratsiooni teisaldamine saidile httpd.conf
Kui konfiguratsioon asetatakse saidile httpd.conf ja AllowOverrides on keelatud, võib kettakasutus väheneda. Kasutaja projektikataloog ei pruugi palju tabamust meelitada, kuid kaaluge selle meetodi võimsust raskeveokite jaoks.
Mõnikord ei ole võimalik .htaccess-failide kasutamist välistada. Näiteks loendis 5, kus valik on piiratud failisüsteemi teatud osaga, võib tagasivõtmise võimalus olla samuti piiratud.
Loetelu 5. Htaccessi kontrolli piiramine
Pärast loendis 5 loetletud toimingute täitmist otsib Apache endiselt .htaccess-faile ülemkataloogist, kuid lõpetab otsimise kataloogist public_html, kuna ülejäänud failisüsteem ei tööta enam. Näiteks kui taotletakse faili /home/user/public_html/project/notes.html, renderdatakse see edukalt ainult siis, kui leitakse avalik_html ja projektikataloog.
Üks viimane märkus kataloogispetsiifiliste konfiguratsioonide kohta on korras. Mis tahes dokument selle kohta Apache seadistamine käsib teil keelata DNS-otsingud käsu HostnameLookups off direktiivi kaudu, kuna kõigi IP-aadresside ja serveriga ühenduste ümberpööramine on ressursside raiskamine. Kuid kõik hostinimepõhised piirangud sunnivad veebiserverit tegema kliendi IP-aadressi pöördotsingut ja nime autentimise tulemusel põhinevat edasiotsingut. Seetõttu on mõistlik vältida hostinimepõhiste juurdepääsukontrollide kasutamist ja vajadusel kontrollida neid kirjeldatud viisil.
Püsivad ühendused
Kui klient loob ühenduse veebiserveriga, on lubatud sama TCP-ühenduse kaudu teha mitu päringut, mis vähendab mitme ühendusega seotud latentsust. See on kasulik, kui veebileht sisaldab mitut pilti: klient saab ühe ühenduse ajal taotleda lehte ja seejärel kõiki pilte. tagakülg seisneb selles, et serveri tööprotsess peab ootama, kuni klient seansi sulgeb, enne kui saab järgmise päringu juurde liikuda.
Apache võimaldab teil määratleda, kuidas püsivaid ühendusi nimetatakse elus hoidma. KeepAlive 5 globaalsel httpd.conf tasemel võimaldab serveril töödelda 5 ühenduse taotlust enne ühenduse sunniviisilist katkestamist. Kui määrate selle numbri väärtuseks 0, keelatakse püsivate ühenduste kasutamine. KeepAliveTimeout , ka globaalsel tasemel, määrab, kui kaua Apache ootab uut päringut enne seansi sulgemist.
Püsivate ühenduste käsitlemine ei ole kõigile sobiv konfiguratsioon. Mõned veebisaidid toimivad paremini, kui Keepalives on keelatud (KeepAlive 0) ja mõnel juhul võib nende lubamine olla palju kasu. Ainus lahendus on proovida mõlemat võimalust ja uurida ise. Siiski on mõistlik kasutada KeepAliveTimeout 2 abil madalat ajalõpu, näiteks 2 sekundit, kui teil on Keepalives lubatud. See tagab, et igal kliendil, kes soovib esitada uut päringut, on piisavalt aega ja töötajaid ei jäeta jõude ootama uut päringut, mis ei pruugi kunagi saabuda.
Kokkusurumine
Veebiserver võib väljundi tihendada enne, kui see kliendile tagastab. See vähendab Interneti kaudu saadetavate lehtede hulka veebiserveri protsessori tsüklite arvelt. Nende serverite jaoks, mis saavad endale lubada suurt protsessorikoormust, on see suurepärane võimalus kiiresti laaditavate lehtede loomiseks – lehe suurust saab pärast tihendamist vähendada kolm korda.
Tavaliselt on pildid juba tihendatud, seega tuleb tihendada ainult tekstiväljund. Apache pakub tihendamist mod_deflate abil. Ehkki funktsiooni mod_deflate saab lihtsalt keelata, sisaldab see palju keerukust, mida juhend püüab selgitada. See artikkel ei käsitle tihendamise konfigureerimise teemat, välja arvatud lingi lisamine asjakohasele dokumentatsioonile (vt jaotist).
PHP seadistamine
PHP on mootor, mis käivitab rakenduse koodi. Peaksite installima ainult need moodulid, mida kavatsete kasutada, ja seadistage oma veebiserver kasutama PHP-d ainult skriptifailide jaoks (tavaliselt need failid, mis lõppevad .php-ga), mitte kõigi staatilised failid.
Opkoodi vahemälu
Kui küsitakse PHP-skripti, loeb PHP skripti ja koostab selle millekski nn Zend opkood, käivitatava koodi binaarne esitus. Seejärel käivitab PHP mootor selle opkoodi ja see läheb kaotsi. Opkoodi vahemälu salvestab selle ja kasutab seda järgmisel korral, kui lehte taotletakse. See säästab palju aega. Mõned opkoodi vahemälud on saadaval; Olen eAcceleratorit edukalt kasutanud.
eAcceleratori installimiseks on vaja arvutis teeke PHP arendus. Kuna erinevad Linuxi distributsioonid paigutavad failid erinevatesse asukohtadesse, hankige installijuhised otse eAcceleratori veebisaidilt (vt linki jaotises Samuti on võimalik, et teie distributsioon on opkoodi vahemälu juba pakkinud ja peaksite lihtsalt installima sobiva paketi).
Olenemata sellest, kuidas eAcceleratori oma süsteemi installisite, on mitu konfiguratsioonivalikut. Konfiguratsioonifail on tavaliselt /etc/php.d/eaccelerator.ini. eaccelerator.shm_size määrab jagatud mälu vahemälu suuruse, kuhu salvestatakse kompileeritud skriptid. Väärtust mõõdetakse megabaitides. Sobiva suuruse määramine sõltub rakendusest. eAccelerator pakub skripti vahemälu oleku kuvamiseks, mis hõlmab ka mälukasutust; 64 megabaiti on hea lähtepunkt (eaccelerator.shm_size="64"). Samuti saate reguleerida jagatud mälu maksimaalset suurust, kui teie valitud väärtust ei aktsepteeritud. Seadete jõustumiseks lisage kernel.shmmax=67108864 faili /etc/sysctl.conf ja käivitage sysctl -p. Kernel.shmmax väärtust mõõdetakse baitides.
Kui eraldatud ühismälu maht on ületatud, peab eAccelerator vanad skriptid mälust eemaldama. See on vaikimisi keelatud; eaccelerator.shm_ttl = "60" määrab, et kui eAcceleratori ühismälu saab otsa, tuleb kustutada kõik skriptid, millele 60 sekundi jooksul juurde ei pääse.
Teine populaarne eAcceleratori alternatiiv on alternatiivne PHP vahemälu (APC). Zendi loojatel on ka kaubanduslik opkoodi vahemälu, mis sisaldab optimeerijat tõhususe edasiseks parandamiseks.
php.ini
PHP seadistate saidis php.ini. Neli olulised parameetrid sätted määravad, kui palju süsteemiressursse PHP võib tarbida, nagu on näidatud tabelis 1.
Tabel 1. Ressursiga seotud php.ini sätted
Nende väärtuste suurus sõltub tavaliselt rakendusest. Kui nõustute kasutajatelt suured failid, max_input_time saab suurendada kas failis php.ini või selle koodis alistades. Sarnasel viisil, tarbivate programmide jaoks suur hulk CPU või mälu võib vajada suuremaid väärtusi. Eesmärk on vähendada energiat näljase programmi mõju, seega pole nende seadete globaalne keelamine soovitatav. Veel üks märkus max_execution_time kohta: see viitab protsessile kulutatud protsessori ajale, mitte absoluutsele ajale. Seega võib programmi, mis teeb palju I/O-d ja vähe arvutusi, täitmine võtta palju kauem aega kui parameetri max_execution_time . max_input_time võib olla ka suurem kui max_execution_time .
Kirjete arv, mida PHP saab teha, on konfigureeritav. Tootmiskasutusel säästavad nad kettaruumi, visates ära kõik peale kõige kriitilisemate logide. Kui logisid on probleemide diagnoosimiseks vaja, saate vajalikud logid tagastada. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR võimaldab piisavat logimist probleemide tuvastamiseks, kuid eemaldab skriptidest mittevajaliku teabe.
Järeldus
See artikkel keskendub nii Apache kui ka PHP veebiserveri seadistamisele. Apache'i põhiidee on välistada tarbetud kontrollid, mida veebiserver peab tegema, näiteks .htaccess-faili töötlemine. Samuti peaksite konfigureerima mitme protsessori mooduli (MPM), mis tasakaalustab kasutatud süsteemi ressursse ja jõudeolevad töötajad sissetulevate päringute jaoks. Parim asi, mida saate PHP jaoks teha, on mõne ressursisätte jälgimine tagab, et skriptid ei võta ressursse üle ega aeglusta süsteemi.
Selle sarja järgmine ja viimane artikkel käsitleb andmebaasi loomist MySQL-i andmed. Ära kaota oma vaimu!
|Apache on väga võimas veebiserver. Esialgse seadistamise hõlbustamiseks pakub see suurt hulka eelseadeid paigaldatud moodulid. See muudab Apache suurepäraseks uute projektide juurutamiseks, võimaldades teil kiiresti luua tugeva tootmiskeskkonna. Kuid kui teie sait (ja seega ka liiklus) kasvab, võib teil tekkida probleeme.
See juhend aitab teil parandada Apache jõudlust teie virtuaalserveris.
1: keelake mittevajalikud moodulid
Ubuntu ja Debiani sarnastes süsteemides on kataloogid etc/apache2/mods-enabled ja /etc/apache2/mods-available/. Viimane salvestab nimekirja kõigist sellesse serverisse installitud moodulitest. Ja modifikatsioonidega kataloogis on moodulid, mis on praegu lubatud.
Vaikeolukord võib iga serveri puhul olla erinev. Oletame, et serveris on vaikimisi lubatud 17 moodulit. Tavaliselt on see keskmise rakenduse jaoks liiga palju. Lisaks on üsna raske kohe tuvastada mittevajalikke mooduleid, mida saab keelata, kuna üksikud moodulid on teiste sõltuvused.
Alustuseks on soovitatav salvestada vaikimisi aktiivsete moodulite loend, et edaspidi saaks seda kasutada vaikeseadete taastamiseks. Seejärel saate lihtsalt keelata kõik mittevajalikud moodulid ükshaaval, taaskäivitades Apache pärast iga mooduli keelamist, et tagada, et süsteemis ei esineks vigu.
Ubuntu ja Debiani puhul keelatakse moodulid selle käsuga:
sudo a2dismod autoindex
Üksikud moodulid kulutavad palju ressursse; Kui te ei kasuta järgmisi mooduleid, siis lihtsalt keelake need.
- Uuesti kirjutama
- Python
- Rack/Ruby/Passenger
Kõik need moodulid ei ole vaikimisi lubatud, kuid olukord on iga serveri puhul individuaalne.
Märkus. Apache sisaldab tavaliselt vaikimisi ümberkirjutamise moodulit, kuigi selle saab asendada pseudonüümi mooduliga. Kui alias teie rakendusele sobib, keelake ümberkirjutamine – see on üks raskemaid mooduleid. Ümberkirjutamise asemel pseudonüümile üleminekuks vaadake mooduli dokumentatsiooni. Isegi kui te ei saa ümberkirjutamist täielikult keelata, saate optimeerida üksikute moodulite reegleid.
Pärast mooduli keelamist taaskäivitage Apache ja seejärel kontrollige vealogi, et veenduda, et mooduli keelamine ei kahjustanud veebiserverit.
Näiteks võite saada sellise veateate:
Süntaksiviga /etc/apache2/sites-enabled/site1 real 6:
Vigane käsk "DAVLockDB", võib-olla valesti kirjutatud või määratud serveri konfiguratsioonis mittekuuluva mooduli poolt
Toiming "configtest" ebaõnnestus.
See tähendab, et veebiserveri korrektseks toimimiseks on vaja keelatud moodulit. Lülita sisse.
sudo a2enmod dav_fs
2: teisaldage kood
PHP-saidid kasutavad sageli populaarset mod_php moodulit ja rubiini saidid kasutavad sageli Passenger Phusionit (mod_rails või mod_rack mooduleid).
Probleem on selles, et keeletõlgi C-kood on Apache'is pesastatud, mis nõuab iga lehe vaatamiseks rohkem mälu. Kui teie saidi populaarne leht saab 30 HTTP-päringut, on üks neist mõeldud jaoks dünaamiline leht, ja ülejäänud 29 on staatiliste ressursside jaoks (pildid, css ja javascript). Apache'i jõudluse parandamiseks saate kõrvaldada 29 päringut, mis ei paku dünaamilist sisu.
Mooduli mod_php lubamine võib põhjustada ühe Apache'i alamprotsessi, mis nõuab 100 MB RAM-i. Mida rohkem Apache protsesse serveris töötab, seda keerulisem on neid töödelda.
Selle probleemi lahendamiseks võite kasutada järgmisi tööriistu.
- PHP jaoks saate installida php-fpm, mis on eraldi protsess põhineb fastcgi protokollil.
- Pythonis kasutage uWSGI-d või gnunicorni
- Rööbaste jaoks kasutage Unicorni.
See käivitab esmalt protsessi PHP, Pythoni või Ruby jaoks ja seejärel suunab Apache dünaamilise sisu kõned sellesse protsessi, selle asemel, et proovida seda pesastatud koodiga käsitleda.
Pärast mod_php mooduli eemaldamist võib Apache protsesside suurus muutuda 90–120 MB-lt kõigest 10 MB-ni. Kogu dünaamilist sisu teenindavad taustaprogrammis vaid kaks protsessi.
3. Piirake Apache protsesside arvu
Paljud operatsioonisüsteemid kasutavad vaikekonfiguratsioone, mis väikestele serveritele eriti ei sobi – 25 alamprotsessi. Kui iga Apache'i alamprotsess nõuab 120 MB RAM-i, kulutab server ainult Apache'ile 3 GB.
Ühe kasutaja veebilehitseja saab korraga taotleda 4 saidielementi, mis tähendab, et serverit võib üle koormata vaid 7-8 inimest. Veebilehed hanguvad või laaditakse väga aeglaselt.
Server hoiab sageli neid surnud Apache protsesse elus, püüdes soovitud sisu teenindada, mis vähendab kasutajate teenindamiseks saadaolevate protsesside arvu ja vähendab mälumahtu. Tulemuseks on kehv kasutuskogemus.
Määrake, kui palju RAM-i teie rakendus vajab ja kui palju mälu on alles, seejärel eraldage suurem osa ülejäänud mälust Apache'ile.
Näiteks on teil dünaamilise sisu töötlemiseks kolm php-fpm protsessi, kus iga protsess kasutab kuni 70 MB mälu, ja MySQL-server, mis võtab kuni 120 MB RAM-i. Tulemuseks on see, et rakendus kasutab 330 MB mälu. Kui teil on väike server, saate Apache'ile eraldada umbes 150 MB mälu.
Kui veeb Apache server töötab, käivitage ülemine käsk. See kuvab palju kasulikku teavet. Allpool on väljavõte tema tulemusest:
ülemine - miljard 1
PID KASUTAJA PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
[...]
15015 www-andmed 20 0 232m 9644 1900 S 0,0 1,6 0:00,02 apache2
15016 www-andmed 20 0 232m 9644 1900 S 0,0 1,6 0:00,01 apache2
15017 www-andmed 20 0 232m 9644 1900 S 0,0 1,6 0:00,02 apache2
Leidke Apache'i veerust RES väärtus (näiteks 9644) ja kirjutage see üles. Hetkel kasutab veebiserver ligi 10 MB mälu. Kui piirate Apache'i alamprotsesside arvu 15-ni, piisab 150 MB eraldatud mälust.
Redigeerige Apache konfiguratsioonifaili (Ubuntu ja Debiani puhul on see /etc/apache2/apache2.confand) ja leidke jaotis mpm_prefork_module. Otsige üles rida MaxClients ja sisestage 15, seejärel salvestage fail ja taaskäivitage veebiserver.
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxClients 30
MaxRequestsPer Child 0
Vaikimisi võib MaxClientsi väärtus olla väga suur. Seda tuleb vähendada.
Kui klientide arv jõuab limiidini, kuvatakse uutele klientidele veateade. Lehe uuesti laadides pääsevad nad saidile juurde.
See kõlab halvasti, kuid siiski on parem need ühendused kiiresti sulgeda ja server normaalselt töötada, kui oodata, kuni server lõpetab rippumise.
Mõnes olukorras võib vähem alamprotsesse aidata parandada serveri jõudlust.
Apache konfiguratsioonid kasutavad sageli prefork mpm, mida peetakse turvaliseks ja sobivaks PHP ja muude keelte jaoks.
Kui vabaneda välised moodulid(PHP või Rails), võite alternatiivina kaaluda töötajate MPM-i.
Selle mooduli lubamiseks sisestage:
sudo apt-get install apache2-mpm-worker
EEMALDAtakse järgmised paketid:
apache2-mpm-prefork libapache2-mod-php5
Installitakse järgmised UUED paketid:
apache2-mpm-töötaja
0 uuendatud, 1 äsja installitud, 2 eemaldatavad ja 2 uuendamata.
Vaja on hankida 2284 B arhiivi.
Pärast seda toimingut vabaneb kettaruumi 8718 kB.
Kas sa tahad jätkata?
Tähelepanu! Ubuntu puhul eemaldab töötaja mooduli installimine prefork mpm, mod_php ja muud ühildumatud moodulid.
Sildid:
Apache on Internetis populaarne veebiserver, mis teenindab paljusid servereid ja saite. Sageli on vaja suurendada veebiserveri jõudlust. Tõenäoliselt on selleks parim viis lülituda skeemile frontend+backend, kuid see võib nõuda päris tõsiseid muudatusi rakenduses (näiteks kaotate tõenäoliselt kõikvõimalikud failide üleslaadimise edenemise indikaatorid :).
Teine võimalus on lihtsalt serveri jõudlust suurendada – paigalda kiirem protsessor ja rohkem mälu.
Kuid nii esimene kui ka teine nõuavad palju aega ja ressursse, nii et esimest korda võite proovida Apache'i kiirendada selle konfiguratsiooni optimeerimisega. On optimeerimisi, mida saab rakendada ainult Apache'i ümberehitamisel, samas kui teisi saab rakendada ilma serverit uuesti kompileerimata.
Laadige ainult vajalikud moodulid
Apache on modulaarne programm, mille funktsionaalsus on enamikus moodulites. Lisaks saab neid mooduleid kas kompileerida või kokku panna DSO-dünaamiliste teekide kujul. Enamik kaasaegseid distributsioone tarnib Apache'i koos jaotusvõrguettevõtjate komplektiga, nii et mittevajalikud moodulid saab hõlpsasti keelata ilma uuesti kompileerimata.
Mälukulu vähendamiseks käivitage apache ainult vajalike moodulitega. Kui otsustate apache'i ise kompileerida, siis olge kaasatud moodulite loendi osas valiv või kompileerige need jaotusvõrguettevõtjatena, kasutades apache1-s apxs-i ja apache2-s apxs2. Mittevajalike DSO-moodulite keelamiseks kommenteerige lihtsalt httpd.conf-i LoadModule'i lisaread. Staatiliselt kompileeritud moodulitega Apache tarbib veidi vähem mälu, kuid moodulite loendi muutmiseks peate selle iga kord uuesti kompileerima.
Valige sobiv MPM
Apache'is töödeldakse iga päringut oma protsessis või lõimes. Kompileerimisel võimaldab apache valida ühe mitmest MPM-ist (multitöötlusmoodulid), mis vastutavad portide kuulamise, päringute vastuvõtmise ja nende päringute levitamise eest alamprotsessidele või lõimedele, milles neid taotlusi töödeldakse.
MPM-i valik sõltub mitmest tegurist, näiteks sellest, kas operatsioonisüsteemil on keermestamise tugi, vaba mälu hulk ning stabiilsus- ja turvanõuded.
Kui turvalisus on väga oluline, peaksite jõudluse ohverdamiseks valima peruser MPM-i.
Kui jõudlus on oluline, siis on valik piiratud kahe mpm: prefork ja worker.
Tööline- voolu MPM, st. selles esitatakse iga päring ühe alamprotsessi eraldi lõimes. Lõimed on OS-i jaoks lihtsamad objektid kui protsessid, mis kasutavad mälu tõhusamalt ja kontekstilülitid on nende jaoks kiiremad. Kuna aga igal lõimel on juurdepääs kogu protsessi mälule, on töötaja mpm suurem krahhide tekkeks: ühe lõime rike võib põhjustada kogu protsessi, milles see lõime asus, kokkujooksmise (sellepärast käivitab töötaja mpm mitu alamosa protsessid, millest igaühes on mitu lõime).
Perfork- mpm kasutab mitut alamprotsessi, iga alamprotsess tegeleb ühe ühendusega. Kuna protsess on raskem struktuur, kasutab see veidi rohkem ressursse, kuid on vähem altid ebaõnnestumisele – iga üksiku päringu töötlemine ei sõltu teistest protsessidest.
Kahjuks nõuab mpm muutmine Apache uuesti kompileerimist. Siin näitavad allikapõhised distributsioonid oma eeliseid: saate Apache'i ja kõik sellest sõltuvad paketid hõlpsalt uuesti kompileerida, ilma et muudaks süsteemi prügimäeks. Binaarsed distributsioonid käsitlevad seda olukorda erineval viisil. Näiteks RHEL-is sisaldab apache rpm kahte apache versiooni – worker ja prefork mpm (vaikimisi kasutatakse preforki). Töötaja mpm aga php-d ei toeta. Nii et kui soovite php ja worker mpm, peate selle ise kompileerima või otsima kolmandate osapoolte hoidlaid.
DNS-i otsing
Direktiiv HostnameLookups sisaldab pöörd-DNS päringuid, nii et IP-aadresside asemel lisatakse logidesse kliendi DNS-hostid. Loomulikult aeglustab see oluliselt päringu menetlemist, sest... päringut ei töödelda enne, kui see saab DNS-serverist vastuse. Seetõttu veenduge, et see direktiiv oleks alati välja lülitatud (HostnameLookups Off) ja kui teil on endiselt vaja DNS-aadresse, saate need hiljem teada, käivitades logi utiliidis logresolve (mis on Apache'iga kaasas).
Lisaks veenduge, et direktiivid Allow from ja Deny From kasutaksid IP-aadresse ja mitte domeeninimed. Vastasel juhul teeb apache kaks DNS-i päringut (tagurpidi ja edasi), et veenduda, et klient on see, kes ta väidab end olevat.
AllowOverride
Kui käsk AllowOverride ei ole seatud väärtusele "Puudub", proovib apache avada .htaccess-faile igas külastatavas kataloogis ja kõigis selle kohal olevates kataloogides. Näiteks:
DocumentRoot /var/www/html
Kui taotletakse /index.html, proovib apache avada (ja tõlgendada) faile /.htaccess, /var/.htaccess, /var/www/.htaccess ja /var/www/html/.htaccess. See pikendab taotluse töötlemise aega. Nii et kui vajate .htaccessi ainult ühe kataloogi jaoks, lubage see ainult selle kataloogi jaoks:
DocumentRoot /var/www/html
Jälgige SymLinksi ja SymLinksIfOwnerMatch
Kui suvand FollowSymLinks on kataloogi jaoks lubatud, järgib server seda sümboolsed lingid selles kataloogis. Kui suvand SymLinksIfOwnerMatch on kataloogi jaoks lubatud, järgib apache sümboolseid linke ainult siis, kui faili või kataloogi omanik, millele link viitab, ühtib määratud kataloogi omanikuga. Seega, kui suvand SymLinksIfOwnerMatch on lubatud, teeb apache rohkem süsteemipäringuid.
Lisaks on vaja täiendavaid süsteemipäringuid, kui FollowSymlinks EI OLE PAIGALDATUD. See. Parim toimivusolukord on siis, kui suvand FollowSymlinks on lubatud.
Sisu läbirääkimised
Püüdke vältida sisuläbirääkimisi.
MaxClients
MaxClientsi direktiiv määrab maksimaalse samaaegsete päringute arvu, mida server toetab. Apache ei loo rohkem protsesse/lõime kui MaxClients. MaxClienti väärtus ei tohiks olla liiga väike (muidu jäävad paljud kliendid teenindamata), kuid te ei tohiks seda arvu liiga suureks seada - parem on mõnda klienti mitte teenindada, kui ammendada kõik ressursid, minna vahetusse ja surra koormuse all. Hea väärtus võib olla MaxClients = veebiserveri jaoks eraldatud mälu maht / loodud protsessi või lõime maksimaalne suurus. Staatiliste failide puhul kasutab apache umbes 2-3 MB protsessi kohta, dünaamiliste failide puhul (php, cgi) – oleneb skriptist, aga tavaliselt ca 16-32 MB.
Kui server juba teenindab päringuid MaxClients, seatakse uued päringud järjekorda, mille suurus määratakse ListenBacklog direktiivi abil.
MinSpareServers, MaxSpareServers ja StartServers
Sest Lõime ja eriti protsessi loomine on kulukas operatsioon. Apache loob need ette. MaxSpareServersi ja MinSpareServersi direktiivid määravad, kui palju protsesse/lõime peaks päringu vastuvõtmiseks ootama (maksimaalne ja minimaalne). Kui MinSpareServersi väärtus on liiga väike ja paljud päringud tulevad ootamatult, on apache sunnitud looma palju uusi protsesse/lõime, mis tekitavad selles stressirohkes olukorras lisakoormust. Teisest küljest, kui MaxSpareServers on liiga suur, koormab apache süsteemi nende protsessidega tugevalt, isegi kui klientide arv on minimaalne.
Proovige seadistada MinSpareServers ja MaxSpareServers nii, et apache ei loo sekundis rohkem kui 4 protsessi/lõime. Kui see loob rohkem kui 4, paigutatakse selle kohta teade ErrorLogi. See on signaal, et MinSpareServers on liiga väike.
MaxRequestsPer Child
Direktiiv MaxRequestsPerChild määrab, mitu päringut üks alamprotsess/lõim saab töödelda enne selle lõpetamist. Vaikimisi on selle direktiivi väärtuseks seatud 0, mis tähendab, et kui protsess/lõim on loodud, siis seda kunagi ei lõpetata (va siis, kui server peatub või see protsess/lõim kokku jookseb). Soovitan määrata MaxRequestsPerChild väärtusega piisav suur hulk(mitu tuhat). See ei tekita tarbetut koormust, kuna apache on sunnitud looma uusi alamprotsesse, samal ajal aitab see vabaneda alamprotsesside mälulekkeprobleemidest (mis on väga võimalik näiteks siis, kui kasutades php ebastabiilset versiooni).
KeepAlive ja KeepAliveTimeout
KeepAlive võimaldab teil teha ühe TCP-ühenduse kaudu mitu päringut. See on eriti kasulik paljude piltidega html-lehtede puhul. Kui KeepAlive on välja lülitatud, siis luuakse lehe enda ja iga pildi jaoks eraldi ühendus (mida peab töötlema põhiprotsess), mis on halb nii serverile kui ka kliendile. Nii et sellistel juhtudel on soovitatav KeepAlive seada sisse. Muude rakenduste jaoks (näiteks allalaadimisserveri jaoks) võib KeepAlive olla kasutu ja isegi kahjulik, sest Kui KeepAlive on lubatud, ei sulge server ühendust kohe, vaid ootab KeepAliveTimeout sekundit uue päringu saamiseks. Et protsessid ei jääks asjatult liiga kauaks ootama, määrake KeepAliveTimeout piisavalt väikeseks, tavaliselt piisab umbes 5-10 sekundist.
Kokkusurumine
HTTP tihendamine määratleti HTTP/1.1 standardis ja nüüd toetavad seda kõik kaasaegsed klientprogrammid ja peaaegu kõik serverid. Server saab vastuse tagastada gzip- või deflate-vormingus ning klientprogramm dekompresseerib andmed kasutajale märkamatult. See vähendab edastatava liikluse mahtu (kuni 75%), kuid loomulikult suurendab protsessori kasutust.
Kui aga teie serverit külastavad paljud aeglase ühendusega kliendid, võib tihendamine vähendada teie serveri koormust, kuna server suudab tihendatud vastuse kiiremini edastada ja vabastada alamprotsessi poolt hõivatud ressursse. See efekt võib olla eriti märgatav, kui teil on kiire protsessor, kuid vähe mälu.
Vahemällu salvestamine on konfigureeritud mooduli mod_deflate käskkirjadega. Pidage meeles, et te ei tohiks seada gzipi pakkimise taset üle 4-5 - see nõuab oluliselt rohkem protsessori aega ja mõju on üsna väike. Noh, muidugi, pole vaja proovida tihendada pilte jpg-ks, gif-iks ja png-vormingus, muusika-, videofailideks ja kõikideks muudeks binaarfailideks, mis on juba hästi tihendatud.
