Giv ikke efter for en lavine: Forberedelse af webserveren til høje belastninger. Hurtig optimering af Apache- og Nginx-webserverindstillinger
I det hele taget, hvis du kan ikke løfte Apache, gør ikke dette. Overvej om lighttpd eller thttpd kan udføre de opgaver, du har brug for. Disse webservere kan være meget nyttige i situationer, hvor der ikke er nok systemressourcer til alle, men det burde virke. Jeg gentager endnu en gang: vi taler om de situationer, hvor funktionaliteten af disse produkter vil være tilstrækkelig til at fuldføre de tildelte opgaver (i øvrigt, lighttpd ved hvordan man arbejder med PHP). I de situationer, hvor uden Apache godt, der er simpelthen ingen vej udenom, du kan normalt frigøre en masse systemressourcer alligevel ved at omdirigere anmodninger til statisk indhold (JavaScript, grafik) fra Apache til en let HTTP-server. Det største problem Apache er hans store appetit på RAM. I denne artikel vil jeg se på metoder, der hjælper med at fremskynde arbejdet og reducere mængden af hukommelse, det optager:
Indlæser færre moduler
Det første skridt er at slippe af med unødvendige moduler fra indlæsning. Gennemgå konfigurationsfilerne og afgør, hvilke moduler du indlæser. Har du brug for alle de moduler, der kan downloades? Find noget, der ikke er brugt, og sluk det, det vil spare dig for noget hukommelse.
Behandle færre samtidige anmodninger
Jo flere processer Apache får lov til at køre samtidigt, jo flere samtidige anmodninger kan den håndtere. Ved at øge dette tal øger du dermed mængden af hukommelse, der er allokeret til Apache. Ved hjælp af toppen kan du se, at hver proces Apache Det fylder meget lidt hukommelse, fordi der bruges delte biblioteker. I Debian 5 Med Apache 2 Standardkonfigurationen er denne:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0
direktiv StartServere bestemmer antallet af serverprocesser, der startes i starten, umiddelbart efter dens start. direktiver MinSpareServere Og MaxSpareServere bestemme minimum og maksimal mængde børns "spare" processer Apache. Sådanne processer venter på indkommende forespørgsler og aflæses ikke, hvilket gør det muligt at fremskynde serverens svar på nye forespørgsler. direktiv MaxClients definerer det maksimale antal parallelle anmodninger, der behandles samtidigt af serveren. Når antallet af samtidige forbindelser overstiger dette antal, vil nye forbindelser blive i kø til behandling. Faktisk direktivet MaxClients og bestemmer det maksimalt tilladte antal underordnede processer Apache, lanceret samtidigt. direktiv MaxRequestsPerChild definerer antallet af anmodninger, som den underordnede proces skal behandle Apache før den afslutter sin eksistens. Hvis værdien af dette direktiv er fastsat lig med nul, så vil processen ikke "udløbe".
For min hjemmeserver, med de tilsvarende behov, korrigerede jeg konfigurationen til følgende:
StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300
Selvfølgelig er ovenstående konfiguration fuldstændig uegnet til brug på højt belastede servere, men til hjemmebrug er det efter min mening helt rigtigt.
Proces cirkulation
Som du kan se, ændrede jeg værdien af direktivet MaxRequestsPerChild. Ved at begrænse levetiden for underordnede processer på denne måde med antallet af behandlede anmodninger, kan du undgå utilsigtede hukommelseslækager forårsaget af dårligt skrevne scripts.
Brug af KeepAlives, der ikke er for lange
KeepAlive er en støttemetode permanent forbindelse mellem klient og server. Indledningsvis HTTP protokol blev designet til ikke at være orienteret mod vedvarende forbindelser. Det vil sige, at når en webside sendes til en klient, transmitteres alle dens dele (billeder, rammer, JavaScript) ved hjælp af forskellige, separat etablerede forbindelser. Med adventen KeepAlive, browsere har nu mulighed for at anmode permanent forbindelse og efter at have installeret det, download data ved hjælp af en etableret forbindelse. Denne metode giver en betydelig stigning i produktiviteten. Imidlertid Apache Som standard bruger den en for lang timeout, før forbindelsen lukkes, svarende til 15 sekunder. Det betyder, at efter alt indholdet er blevet serveret til den klient, der har anmodet KeepAlive, vil den underordnede proces vente i yderligere 15 sekunder på indgående anmodninger. Det er dog lidt meget. Det er bedre at reducere denne timeout til 2-3 sekunder.
KeepAliveTimeout 2
Reducer timeout
Alternativt kan du reducere værdien af direktivet TimeOut, som angiver, hvor lang tid det tager at vente på, at individuelle anmodninger er fuldført. Som standard er dens værdi 300 , måske vil det i dit tilfælde give mening at reducere/øge denne værdi. Jeg lod det personligt være lige nu.
Reduktion af logningsintensitet
På vej til at øge serverydeevnen kan du prøve at reducere intensiteten af logningen. Moduler som f.eks mod_rewrite, kan skrive fejlfindingsoplysninger til loggen, og hvis du ikke har brug for det, skal du slukke for dens output.
Deaktivering af værtsnavnsopløsning
Efter min mening er der ingen grund til at omvendt løse IP-adresser til værtsnavne. Hvis du virkelig har så meget brug for dem, når du analyserer logs, så kan du bestemme dem på analysestadiet, og ikke mens serveren kører. Direktivet er ansvarligt for at løse værtsnavne Værtsnavnopslag, som faktisk er installeret som standard i Slukket, men tjek dette, hvis du virkelig mener, at du skal deaktivere konverteringen.
Værtsnavnopslag slået fra
Deaktivering af brug af .htaccess
Filbehandling .htaccess løb Apache hver gang du anmoder om data. Ikke kun det Apache skal downloade denne fil, det tager stadig meget tid og ressourcer at behandle den. Tag et kig på din webserver og genovervej behovet for filer .htaccess. Hvis du har brug for forskellige indstillinger for forskellige mapper, ville det måske være realistisk at placere dem i hovedserverens konfigurationsfil? Og deaktiver behandling .htaccess muligt ved direktiv i serverkonfigurationen.
Hvis du beslutter dig for at øge ydeevnen af Apache (og i dag er det en af de mest populære webservere på internettet), så vil de tip, vi vil give i denne artikel, være nyttige for dig.
1. Arbejd kun med de moduler, du virkelig har brug for, og slet alt andet med det samme og uden tøven! Faktum er, at i dette tilfælde vil du straks reducere hukommelsesforbruget, hvilket vil medføre en stigning i hastigheden. Den anden mulighed er at kompilere modulerne som DSO ved at bruge apxs (i apache 1) og apxs 2 in (apache 2), hvilket reducerer hastigheden med omkring 11-15%.
2. Vælg den korrekte MPM (Multi-processing module). Da MPM's hovedopgave er at lytte på porte, der opfylder de etablerede krav til sikkerhed, mængden af ledig hukommelse eller tilstedeværelsen af trådunderstøttelse i OS, bør du begrænse valget til to MPM'er - worker og prefork.
Arbejder – overfører serviceanmodninger til en separat tråd.
Perfork - du arbejder med flere underordnede processer, som hver især er ansvarlige for at behandle én forbindelse.
For at ændre MPM skal du omkompilere apache ved hjælp af kildebaseret, hvilket straks vil forbedre hastigheden på hele systemet.
3. Konfiguration af DNS-anmodninger. Først skal du aktivere "HostnameLookups"-direktivet. For det andet skal du sørge for, at Tillad fra og afvis fra-direktiverne bruger IP-adresser i stedet for domænenavne for at undgå, at Apache skal lave dobbelte anmodninger for at kontrollere gyldigheden af klientdataene.
4. Indstil AllowOverride-direktivet til "Ingen", ellers vil apache åbne (eller forsøge at gøre det) alle htaccess-filer i hver besøgte mappe, såvel som filer over det:
Derfor, hvis du kun har brug for .htaccess til én mappe, så gør dette:
Du skal også bemærke, at når den er aktiveret for en mappe:
FollowSymLinks - serveren vil altid følge symbolske links i denne mappe;
SymLinksIfOwnerMatch – serveren vil kun spore links, hvis ejeren af mappen matcher ejeren af den mappe, som linket peger til.
5. Afvis også Content Negotiatio.
6. Indstil MaxClients-parametrene korrekt, som bestemmer antallet af samtidig behandlede anmodninger. Find din optimale MaxClients-værdi for at betjene det optimale antal kunder. Det skal huskes, at statiske Apache-filer kræver 2-3 MB pr. proces, for dynamiske - 16-32 MB.
7. Installation af MinSpareServers, MaxSpareServers og StartServers - og dette skulle føre til, at Apache nægter at oprette 4 tråde/processer i sekundet, hvilket vil tillade den ikke at overbelaste systemet selv med det maksimale antal klienter.
8. Skift MaxRequestsPerChild-værdien, når du bestemmer, hvor mange anmodninger 1 underordnet tråd/proces skal behandle, før den afsluttes. Husk, at denne værdi (som standard) er sat til nul, så det er bedre at ændre den til 1000 eller mere, hvilket vil spare dig for at lække hukommelse til underordnede processer, hvilket er af stor betydning, når du bruger en ustabil version af PHP.
9. Aktiver KeepAlive og KeepAliveTimeout, som, når de er deaktiveret, opretter en separat tråd for hvert billede placeret på en HTML-side, og "sænker" sider med et stort antal billeder stor størrelse. I tilfælde med downloadservere er det bedre at deaktivere KeepAlive, hvilket med det samme vil spare dig for at vente lang tid, før serveren lukker forbindelser.
10. Brug komprimering, som giver dig mulighed for at reducere mængden af transmitteret trafik med 75 procent. Og gør dette uden frygt, da alle de nyeste klientprogrammer og servere i dag understøtter HTTP-komprimering i HTTP/1.1-standarden. Og der bør gøres en indsats for at komprimere video, musik og alle jpg, gif png-filer.
Det skal bemærkes, at caching-parametre er indstillet af direktiver fra mod_deflate-modulet. Du bør dog ikke indstille gzip-komprimeringsniveauet til mere end 4 eller 5, da dette vil øge CPU-tiden og reducere den samlede effekt.
11. Og selvfølgelig, glem ikke at installere Expires-headere på statiske filer (mod_expires-modulet bruges til dette). Eller cache den på klienten, hvis filen ikke ændres, hvilket vil frigøre serveren for unødvendige anmodninger, og klienten vil modtage en hurtigere indlæsningsside.
Apache-ydeevneproblemer opstår ofte på nye VPS. Faktum er, at de konfigurationsfiler, der oprettes efter installation af Apache, langt fra er optimeret.
Symptomer på en dårlig opsætning kan være en VPS, der kører med RAM på 100% eller CPU på 100%. Efter at have kørt top- eller htop-kommandoen (hvis det ikke virker, kør apt-get install htop) de første linjer vil indeholde apache-processen.
Jeg viser dig den optimale konfiguration. fil til VPS
VÆDDER: 512 MB
Processor: 2267 MHz
OS: Debian 5
# # Timeout: Antallet af sekunder før modtagelse og afsendelse timeout. # Timeout 300 # # KeepAlive: Om der skal tillades vedvarende forbindelser (mere end # en anmodning pr. forbindelse). Indstil til "Fra" for at deaktivere. # KeepAlive On # # MaxKeepAliveRequests: Det maksimale antal anmodninger for at tillade # under en vedvarende forbindelse. Indstil til 0 for at tillade et ubegrænset beløb. # Vi anbefaler, at du lader dette tal være højt for at opnå maksimal ydeevne. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Antal sekunder at vente på den næste anmodning fra den # samme klient på den samme forbindelse. # KeepAliveTimeout 15 ## ## Server-Pool Size Regulation (MPM-specifik) ## # prefork MPM # StartServers: antal serverprocesser, der skal startes # MinSpareServers: minimum antal serverprocesser, der holdes ledige # MaxSpareServers: maksimalt antal serverprocesser som holdes ledige # MaxClients: maksimalt antal serverprocesser tilladt at starte # MaxRequestsPerChild: maksimalt antal anmodninger en serverproces betjener
I denne indstillingsfil kan du ændre følgende parametre:
- MaxClients– begrænsning af det maksimale antal
- StartServere- indstiller antallet af underordnede processer, når serveren starter.
- MinSpareServere– minimumsantallet af ubrugte underordnede processer.
- MaxSpareServere- derfor det maksimale antal ubrugte underordnede processer.
- MaxRequestsPerChild– det maksimale antal anmodninger, som en underordnet proces må behandle, før den løber over. Tiltrængt denne parameter for at undgå at lække hukommelse eller andre Apache-ressourcer, da hvis den underordnede proces løber over, vil den gøre det
kører httpd-processer samtidigt. dem. i bund og grund sætte en grænse
til hukommelsesforbrug ved den "sultneste" httpd-proces
kraft ophørt. I de fleste tilfælde kræves ingen ændring. Værdi 0 betyder ingen begrænsninger.
Populariteten af en webside er ikke kun en fordel, men også en ekstra hovedpine for systemadministratoren. Efterhånden som strømmen af besøgende stiger, skaber det en større belastning på serveren, som over tid holder op med at klare sit ansvar. På dette tidspunkt rejser spørgsmålet sig om indkøb af hardware, som dog kan udskydes til bedre tider. I denne artikel lærer du, hvordan du får en server til at håndtere belastninger, selv når den nægter at gøre det.
Populariteten af en webside er ikke kun en fordel, men også en ekstra hovedpine for systemadministratoren. Efterhånden som strømmen af besøgende stiger, skaber det en stigende belastning på serveren, som over tid simpelthen holder op med at klare sit ansvar. På dette tidspunkt rejser spørgsmålet sig om indkøb af hardware, som dog kan udskydes til bedre tider. I denne artikel lærer du, hvordan du får en server til at håndtere belastninger, selv når den nægter at gøre det.
Lad os sige, at du har en webserver til din rådighed, hvorpå der kører en mere eller mindre besøgt dynamisk hjemmeside, oprettet på basis af et af PHP CMS'erne. Generelt er situationen mest typisk for moderne RuNet. Siden udvikler sig, vokser, der er flere og flere besøgende, og du begynder at bemærke gradvist stigende forsinkelser i hastigheden af indholdslevering. De enkleste målinger viser, at serveren ikke længere kan klare de opgaver, den er tildelt, og onde tanker om at købe hardware (leje mere kraftfuld virtuel server). Men der er ingen grund til at haste i de fleste tilfælde, situationen er let at vende til din fordel.
Denne artikel vil fortælle dig, hvordan du optimerer server- og klientsiden af et websted til høj belastning. Under diskussionen vil vi dække følgende emner:
- Apache optimering;
- PHP optimering;
- Installation af eAccelerator;
- Installation af Nginx som frontend;
- Installer Memcached;
- Klientoptimering.
Apache optimering
Rodkomponenten på de fleste moderne hjemmesider er selvfølgelig Apache. Det har vist sig at være den mest funktionelle, stabile og brugervenlige HTTP-server, som både kan bruges til at betjene en hjemme-webside og til højbelastede virksomhedsinternetprojekter. Et problem: Apache er en meget tung applikation, der hungrer efter serverressourcer.
Og dette bør tages i betragtning ved opsætningen. Her er en liste over anbefalinger, der bedst følges, når du forbereder en HTTP-server til drift:
- Brorparten af Apaches funktionalitet er indeholdt i indlæsbare moduler, som kan aktiveres eller deaktiveres ved at redigere konfigurationsfilen (LoadModule-direktivet). En god praksis er fuldstændigt at deaktivere alle ubrugte moduler, hvilket vil forbedre serverens ydeevne og spare RAM.
- Apache behandler hver ny anmodning i sin egen tråd og giver dig mulighed for at bruge forskellige tilgange til at udføre denne operation. Hvis du har bygget Apache2 fra kilden, har du måske bemærket, at der i byggemulighederne er mulighed for at vælge den såkaldte MPM. Dette er multi-processing-modulet, der bruges til at parallelisere HTTP-serveren.
Der er tre af dem i alt:
- prefork er en klassisk MPM, der implementerer multi-processing model, der bruges i Apache 1.3. Hver tråd behandles i en separat proces. Ikke den mest produktive mulighed, men den mest stabile. Anvendes som standard.
- worker - Trådbaseret MPM. Serveren afføder flere processer, hver med flere tråde. Én anmodning - én tråd. Prefork er mere produktiv, men mindre stabil.
- begivenhed - begivenhed MPM. I stedet for tråde behandles anmodninger ved hjælp af en hændelsesbaseret model svarende til den, der bruges i nginx. Den mest produktive MPM, men også den mindst stabile (er i det eksperimentelle udviklingsstadium).
Mange distributioner giver dig mulighed for at installere forskellige muligheder Apache, som adskiller sig i den MPM, de bruger, kan nemt findes i depotet ved at søge "apache2-mpm".
- Apache giver dig mulighed for at kontrollere det maksimale antal tråde, der dannes ved hjælp af MaxClients-indstillingen. Indstil ikke dens værdi for højt, ellers bestemt øjeblik serveren vil opbruge al RAM, begynde at bytte, og mange flere klienter vil forblive ubetjente, end det ville være tilfældet, hvis der blev sat en hård grænse. Den optimale værdi er lig med mængden af tilgængelig hukommelse for Apache divideret med maksimal størrelse spawned tråd (tjekket med ps eller top).
- Som mange andre HTTP-servere giver Apache dig mulighed for at kontrollere varigheden af keep-alive-forbindelser, som bruges til at sende flere anmodninger/svar inden for en enkelt forbindelse. Keep-alive giver dig mulighed for at gemme serverressourcer uden at tvinge den til at oprette en separat tråd for hvert billede, CSS og andre sideelementer. Du bør dog ikke holde sådan en forbindelse åben for længe, for det kræver også ressourcer. En god værdi for KeepAliveTimeout-indstillingen ville være 5-10 sekunder, og hvis alle afhængige komponenter på siden sendes til klienten af separate servere, og den aktuelle server kun bruges til at betjene HTML/PHP, er der ingen grund til at understøtte hold-alive overhovedet, og det er bedre at indstille KeepAlive-indstillingsværdien til Off.
- Apache kan ikke lide komprimering. Hvis du beslutter dig for at øge hastigheden på sidelevering ved hjælp af komprimering, så husk, at det højst sandsynligt vil skabe en endnu større belastning på serveren. Hvis komprimering virkelig er nødvendig (for eksempel for en mobilportal, hvis hovedstrøm af klienter bruger en GPRS-kanal), så sæt kompressionsforholdet til et minimum, dette vil kun føre til en lille stigning i volumen af den resulterende data, men vil spare serverressourcer betydeligt.
PHP optimering
Ofte kommer den største belastning slet ikke fra HTTP-serveren, men fra tolken af det programmeringssprog, der bruges til at skabe hjemmesidens dynamiske indhold. I dag er det mest populære sprog til serverside-webscripting PHP, så vi vil fokusere på det i vores artikel. Åbn filen /etc/php5/apache2/php.ini (stien til Ubuntu, kan være anderledes i andre distributioner) og rediger følgende linjer:
- memory_limit - grænse for forbrugt hukommelse ved generering af en webside. Før du ændrer denne parameter, anbefales det at udføre passende målinger og basere værdien på deres resultater.
- display_errors = Fra, error_log = /var/log/php - omdiriger fejlmeddelelser til en logfil. Aktiver denne indstilling, når alle scripts er fuldstændigt fejlrettet.
- upload_max_filesize og post_max_size - den maksimale størrelse af uploadede filer og POST-anmodninger. Igen skal værdien vælges ud fra behovene i din webapplikation.
Nu kan du lukke filen og udføre dyb optimering ved hjælp af PHP-acceleratoren.
Installation af Eaccelerator
PHP er et fortolket sprog. Det betyder, at hver gang et script kaldes på dette sprog, startes PHP-fortolkeren, som udfører fuld analyse kildekode. Desuden, hvis et sekund senere det samme script startes igen, vil hele proceduren blive gentaget igen. Dette er spild af ressourcer, så vi bruger et værktøj kaldet eAccelerator, som vil kompilere PHP-kilder til binær repræsentation, optimerer dem og vil omhyggeligt gemme dem i RAM for hurtigere adgang. Alene takket være dette vil hastigheden for behandling af PHP-scripts blive tidoblet (bekræftet af test).
eAccelerator-pakken er ikke tilgængelig i lagrene i populære distributioner, så du bliver nødt til at bygge den selv. Installer først de nødvendige værktøjer til montering:
$ sudo apt-get install php5-dev build-essential
$ cd /tmp/
$ wget http://bart.eaccelerator.net/source/0.9.6.1/
eaccelerator-0.9.6.1.tar.bz2
$tar xvjf eaccelerator-0.9.6.1.tar.bz2
$cd eaccelerator-0.9.6.1
$phpize
$ ./configure --enable-eaccelerator=delt
$make
$ sudo make install
Opret en mappe til at gemme cachen:
$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator
Og endelig forbinder vi eAccelerator til PHP (tilføj til begyndelsen af filen):
# vi /etc/php5/apache2/php.ini
; Tilslutning af udvidelsen
extension = "eaccelerator.so"
eaccelerator.enable = "1"
; Maksimal diskcachestørrelse (MB)
eaccelerator.shm_size = "64"
; Cachelagringsmappe
eaccelerator.cache_dir = "/var/cache/eaccelerator"
; Aktiver kodeoptimering
eaccelerator.optimizer = "1"
; Genkompilér ændrede scripts
eaccelerator.check_mtime = "1"
; Deaktiver fejlretningstilstand
eaccelerator.debug = "0"
; Cache alle filer (tomt filter)
eaccelerator.filter = ""
; Ubegrænset hukommelsescachestørrelse
eaccelerator.shm_max = "0"
; Hvis der ikke er plads i cachen, skal du slette objekter, der er ældre end
1 time (3600 sekunder)
eaccelerator.shm_ttl = "3600"
eaccelerator.shm_prune_period = "0"
; Cache data både i hukommelsen og på disken
eaccelerator.shm_only = "0"
; Komprimer cachelagrede data med maksimalt niveau kompression
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
Installerer nginx
Da et stort dynamisk websted er populært, kan det skabe en sådan belastning på serveren, at Apache begynder at kvæle og spytte.
Og pointen her er ikke engang, at hardwaren ikke tillader det, men selve HTTP-serverens tyngde. Apache er fantastisk til at give tilbage dynamisk indhold, dog består de fleste moderne websider af statisk indhold på den ene eller anden måde, og at bruge en kraftfuld, kompleks og meget tung HTTP-server til at betjene dem ville være lige så dumt som at køre et terrængående køretøj på vejene i Schweiz. Vi vil bruge den lette Nginx HTTP-server til at aflaste Apache og frigøre den fra den utaknemmelige opgave at servere statisk indhold. I modsætning til Apache bruger Nginx en hændelsesbaseret anmodningsbehandlingsmodel, som kun kræver én HTTP-serverproces for et vilkårligt antal klienter.
Dette reducerer belastningen på strygejernet markant, men skaber visse problemer ved behandling af dynamisk indhold (hvorfor det ikke bruges som den primære HTTP-server). Typisk er Nginx installeret på en dedikeret maskine, som vender mod det eksterne netværk og fungerer som det første kontrolpunkt langs anmodningsstien, men en mulighed med én fysisk server, når Apache og Nginx kører på samme maskine, er også acceptabel. Lad os dvæle ved det. Åbn filen /etc/apache2/ports.conf og skift to muligheder:
NameVirtualHost *:81
Hør 81
Installer derefter Nginx:
$ sudo apt-get install nginx
Åbn konfigurationsfilen og skriv følgende ind i den:
# vi /etc/nginx/nginx.conf
# Nginx-bruger
bruger www-data;
# Indstil antallet af Nginx-processer lig med antallet
processorkerner
arbejdsprocesser 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
begivenheder (
worker_connections 1024;
}
http(
# Standardindstillinger
inkludere /etc/nginx/mime.types;
default_type application/octet-stream;
server_names_hash_bucket_size 64;
access_log /var/log/nginx/access.log;
sendfil på;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
tcp_nodelay på;
# Aktiver komprimering
gzip på;
gzip_proxied any;
gzip_min_længde 1100;
gzip_http_version 1.0;
gzip_buffere 4 8k;
gzip_comp_level 9;
gzip_types text/plain text/css application/
x-javascript text/xml application/xml
application/xml+rss text/javascript;
inkludere /etc/nginx/conf.d/*.conf;
inkludere /etc/nginx/sites-enabled/*;
}
Lad os oprette vores værtskonfiguration:
# vi /etc/nginx/sites-enabled/host.com
server (
hør 80;
servernavn vært.com;
access_log /var/log/nginx.access_log;
# Nginx leverer al statik uafhængigt
placering ~* \.(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)$ (
root /var/www/host.com/;
indeks index.html index.php;
access_log off;
udløber 30d;
}
# Adgang til filer som .htaccess nægtes
placering ~ /\.ht (
benægte alle;
}
# Alle anmodninger om alt andet indhold videregives til Apache
beliggenhed/(
proxy_pass http://127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-for $remote_
adr;
proxy_set_header Vært $host;
proxy_connect_timeout 60;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_redirect off;
proxy_set_header Forbindelse lukket;
proxy_pass_header Indholdstype;
proxy_pass_header Indhold-Disposition;
proxy_pass_header Content-Length;
}
}
Det er det, genstart Apache og Nginx:
$ sudo service apache2 genstart
$ sudo service nginx genstart
Installerer memcached
Memcached er et datacachesystem i hukommelsen, der kan bruges til distribueret lagring og accelerere adgang til data af enhver type.
Dette er en af de mest populære løsninger inden for total hjemmesideoptimering til høje belastninger, som hverken kræver konfiguration eller omfattende API-læring. Normalt bruges memcached af to parter, så at sige, hvoraf den ene lægger data ind i cachen, og den anden henter dem. I et webmiljø spilles rollen som den første part normalt af et lille PHP-script, der skriver vigtige (med hensyn til uploadhastighed) data til memcached, mens den anden part normalt er en letvægts frontend-server (normalt nginx) vha. et særligt modul til at læse og returnere data fra memcached. Memcached bruges ofte til at cache hele sider på et websted, hvorved hastigheden for adgang til disse sider øges med flere størrelsesordener. I det enkleste tilfælde ser denne konfiguration sådan ud:
1. Installer memcached:
$ sudo apt-get install memcached
2. Følgende tilføjes til serverafsnittet i nginx-konfigurationsfilen:
# vi /etc/nginx/nginx.conf
beliggenhed/(
# Indstil den memcachede nøgle til den anmodede
URI
sæt $memcached_key $uri;
# Adresse og port på den memcachede dæmon
memcached_pass 127.0.0.1:11211;
# Standardtitel
default_type text/html;
# Hvis dataene ikke findes i cachen, anmoder vi om det fra backend
fejl_side 404 = /faldback;
}
placering /tilbagegangs (
proxy_pass backend;
}
3. For PHP er memcache-udvidelsen installeret (klient for memcached):
$ sudo pecl installer memcache
4. Følgende kode er indlejret på siderne:
$ vi smalle.php
# Memcached initialisering udeladt
ob_start();
$html = ob_get_clean();
$memcache->set($_SERVER["REQUEST_URI"], $html);
echo $html;
Alt dette fungerer godt, men kun for meget enkle, næsten statiske websteder. Pointen er, at siden ikke altid skal være ens for alle besøgende. Hvad hvis startsiden cachelagres, når en gæst kommer ind på siden, og derefter kommer en registreret deltager til siden og bliver bedt om at registrere sig igen.
Sygdom. Der er dog en ret simpel vej ud af denne situation. Problemet kan løses med en teknologi dækket af mos og spindelvæv kaldet SSI (Server Side Includes). SSI giver dig mulighed for at opdele en webside i flere blokke, som bliver sat sammen af frontend på det tidspunkt, hvor kundens anmodning behandles. For eksempel ved at bruge SSI opdeler du hovedsiden på et websted i to dele:
# vi /var/www/index.php
Dette er nøjagtig den samme side, hvis autentificeringskode er placeret i auth.php-filen, og resten af siden er i body.php. Twist er, at du kun placerer cachingkoden ovenfor i det fjerde trin i den anden af disse filer. Som et resultat tegner følgende billede sig:
- En person kommer til webstedet for første gang. Hjemmesidens hovedside anmodes til nginx.
- Nginx-serveren anmoder om index.php-filen fra backend (Apache), støder på SSI-direktiver inde i den og laver *2* flere anmodninger til backend (auth.php og body.php).
- Efter at have modtaget forespørgsler starter Apache PHP-fortolkeren til at behandle de ønskede filer, hvilket (blandt andet) får indholdet af den tunge body.php-fil til at ende i den memcachede cache.
- Svaret returneres af nginx, som kombinerer filerne til et indeks. php og giver dem til klienten.
- Herefter kommer en registreret deltager til webstedet, en anmodning om index.php sker fra back-end (selvom det højst sandsynligt vil blive taget fra cachen på nginx selv), dog kun en enkel og nem godkendelse. php-anmodningen vil gå til Apache, mens body.php vil blive taget fra den memcachede cache.
Det siger sig selv, at SSI skal aktiveres i konfigurationen nginx fil ved at bruge "ssi on" muligheden placeret i "placering /" sektionen. Det er værd at bemærke, at auth.php-blokken også kan cachelagres, men for at gøre dette skal du tildele en identifikator til alle registrerede brugere, gemme den i cookies og bruge den til at generere en unik memcached nøgle.
Klientoptimering
Denne artikel er afsat til server-side optimering af websteder, men det ville være blasfemi ikke at tale om klient-side del af denne proces. Derfor vil vi kort gennemgå listen over anbefalinger, der har til formål at minimere den samlede mængde data, der overføres:
- Brug gzip eller deflate til at komprimere sider og data. For at gøre dette kan du bruge HTTP-servermoduler: ngx_http_gzip_module for nginx, mod_compress for lighttpd og mod_deflate for Apache.
- Brug pakker til at optimere og fjerne unødvendigt skrald fra HTML og JavaScript (normalt fjerner de alle kommentarer og mellemrum, erstatter navne med kortere osv., f.eks. web-optimizer, code.google.com/p/web-optimizator) .
- Bring CSS og JavaScript-kode ind separate filer, så kan de cachelagres af browseren og anvendes på andre sider (de kan også placeres på separat server så de lades parallelt).
- For glattere og korrekt læsning placere sider i browseren indlæser CSS i begyndelsen af siden og JavaScript i slutningen.
- Glem ikke at indstille Expires og Cache-control headers, så CSS og JavaScript kan cachelagres af browseren.
- Brug ikke JPG og PNG, når du kan bruge GIF (for eksempel til små ikoner).
Balancering
Round robin DNS er en af de enkleste typer belastningsbalancering. For at implementere det er det nok at tildele IP-adresserne på to eller flere servere til et domænenavn. Der er dog også en væsentlig ulempe: Hvis en af serverne fejler, vil nogle klienter stadig blive sendt til den.
memcached
Hvis du har store nok mængder hukommelse, er det en god praksis at starte den memcachede dæmon med '-L' flaget. Som et resultat vil dæmonen forberede al den hukommelse, der er allokeret til den, til brug på forhånd. Dette vil forbedre den overordnede ydeevne af memcached en smule ved at eliminere behovet for konstant at allokere hukommelse, mens du kører.
Apache er en populær webserver på internettet, den betjener et ubegrænset antal servere og websteder. Der er ofte behov for at øge ydelsen på en webserver. Måske bedste måde for at gøre dette skal du gå til frontend+backend-skemaet, men dette kan kræve ret seriøse konfigurationer i applikationen (for eksempel vil du sandsynligvis have alle mulige fremskridtsindikatorer for upload .
En anden måde er blot at øge serverens ydeevne - installer en hurtigere processor og mere hukommelse.
Ja, både 1. og 2. kræver meget tid og ressourcer, så for 1. gang kan du forsøge at fremskynde Apache ved at optimere dens konfiguration. Der er optimeringer, som kun kan anvendes ved genopbygning af Apache, mens andre kan bruges uden at genkompilere serveren.
Indlæs kun de moduler, du har brug for
Apache er et modulært program, hvor det meste af dets funktionalitet er implementeret i moduler. Med alt dette kan disse moduler enten kompileres eller samles i form af DSO - dynamiske biblioteker. De fleste moderne distributioner sender apache med et sæt DSO'er, så lad være nødvendige moduler Du kan simpelthen deaktivere det uden at genkompilere.
Kør apache med kun de nødvendige moduler for at reducere hukommelsesforbruget. Hvis du beslutter dig for selv at kompilere Apache, så vær enten selektiv med hensyn til listen over moduler, du inkluderer, eller kompilér dem som DSO'er ved hjælp af apxs i apache1 og apxs2 i apache2.
For at deaktivere unødvendige DSO-moduler, skal du blot kommentere de ekstra LoadModule-linjer i httpd.conf. Apache med statisk kompilerede moduler vil forbruge lidt mindre hukommelse, men du bliver nødt til at omkompilere den hver gang for at konfigurere listen over moduler.
Vælg den passende MPM
I Apache behandles hver anmodning i sin egen proces eller tråd. Når den er kompileret, giver apache dig mulighed for at vælge en af flere MPM'er (Multi-processing moduler), som er ansvarlige for at lytte til porte, modtage anmodninger og distribuere disse anmodninger til underordnede processer eller tråde, hvori disse anmodninger vil blive behandlet.
Valget af MPM afhænger af flere omstændigheder, såsom tilgængeligheden af trådunderstøttelse, mængden af ledig hukommelse og stabilitets- og sikkerhedskrav.
Hvis sikkerhed er meget vigtigt, bør du vælge peruser MPM, hvilket ofrer ydeevnen.
Hvis ydeevne er den største bekymring, så er valget begrænset til 2 mpm: forgaffel og arbejder.
Arbejder- flow MPM, dvs. i den serveres hver anmodning i en separat tråd i en af de underordnede processer. Tråde er lettere objekter end processer, de bruger hukommelse mere effektivt, og kontekstskift er hurtigere for dem. Men på grund af det faktum, at hver tråd har adgang til hele processens hukommelse, er worker mpm mere tilbøjelig til at fejle: fejl i 1 tråd kan føre til nedbrud af hele processen, hvori denne tråd var placeret (dette er hvorfor worker mpm lancerer flere underordnede processer med flere tråde i hver).
1C
Pergaffel- mpm bruger flere underordnede processer, hver underordnede proces håndterer en forbindelse. På grund af det faktum, at processen er en tungere struktur, bruger den lidt flere ressourcer, men den er mindre udsat for fejl - behandlingen af hver enkelt anmodning afhænger ikke af andre processer.Desværre kræver ændring af mpm genkompilering af Apache. Det er her kildebaserede distributioner viser deres fordele: du kan ganske enkelt genkompilere Apache og alle dens afhængige pakker uden at gøre systemet til et dump. Binære distributioner håndterer denne situation på forskellige måder.
For eksempel er der i RHEL i apache rpm to versioner af apache - med worker og prefork mpm (prefork bruges som standard). Men worker mpm understøtter ikke php. Så hvis du vil have php og worker mpm, bliver du nødt til at kompilere det selv eller finde tredjeparts repositories.
DNS-opslag
HostnameLookups-direktivet muliggør omvendte DNS-forespørgsler, så klientens DNS-værter vises i logfilerne i stedet for IP-adresser. Det bremser naturligvis behandlingen af anmodningen betydeligt, fordi... anmodningen behandles ikke, før den modtager et svar fra DNS-serveren. Sørg derfor for, at dette direktiv altid er slået fra (HostnameLookups Off), og hvis du stadig har brug for DNS-adresser, kan du finde ud af dem senere ved at køre loggen i logresolve-værktøjet (som følger med Apache).
Sørg desuden for, at Tillad fra- og Afvis fra-direktiverne bruger IP-adresser og ikke domænenavne. Ellers vil apache lave to DNS-anmodninger (tilbage og frem) for at sikre, at klienten er den, han hævder at være.
BAFPUG møde 2011-11-05
TilladOverride
Hvis AllowOverride-direktivet ikke er sat til 'Ingen', vil apache forsøge at åbne .htaccess-filer i hver mappe, den besøger, og i alle mapper over den. For eksempel:
DocumentRoot /var/www/html
Hvis /index.html anmodes om, vil apache forsøge at åbne (og fortolke) filerne /.htaccess, /var/.htaccess, /var/www/.htaccess og /var/www/html/.htaccess. Dette øger anmodningsbehandlingstiden. Så hvis du kun har brug for .htaccess for én mappe, så tillad det kun for den mappe:
DocumentRoot /var/www/html
FølgSymLinks og SymLinksIfOwnerMatch
Hvis FollowSymLinks er aktiveret for en mappe, vil serveren følge symbolske links i den mappe. Hvis SymLinksIfOwnerMatch-funktionen er aktiveret for en mappe, vil apache kun følge symbolske links, hvis ejeren af filen eller mappen, som linket peger på, matcher ejeren af den udpegede mappe. Så med SymLinksIfOwnerMatch aktiveret laver apache flere systemanmodninger.
Derudover yderligere systemanmodninger påkrævet, når FollowSymlinks IKKE ER INSTALLERET. At. Den bedste situation for ydeevne er, når funktionen FollowSymlinks er aktiveret.
Indholdsforhandling
Prøv at undgå indholdsforhandling.
MaxClients
MaxClients-direktivet sætter største antal parallelle anmodninger, som serveren vil understøtte. Apache vil ikke skabe flere processer/tråde end MaxClients.
MaxClient-værdien bør ikke være meget lille (ellers vil mange klienter forblive ubetjente), og du bør ikke angive et meget ubegrænset antal - det er bedre ikke at betjene nogle klienter end at udtømme alle ressourcer, gå i bytte og dø under belastning. En god værdi kan være MaxClients = mængden af hukommelse, der er allokeret til webserveren / større størrelse børneproces eller tråd. For statiske filer bruger apache omkring 2-3 MB pr. proces, for dynamiske filer (php, cgi) - det afhænger af scriptet, men normalt omkring 16-32 MB.
Hvis serveren allerede betjener MaxClients af anmodninger, vil nye anmodninger blive sat i kø, hvis størrelse er indstillet ved hjælp af ListenBacklog-direktivet.
MinSpareServers, MaxSpareServers og StartServers
Fordi At skabe en tråd, og især en proces, er en dyr operation, som apache udfører dem på forhånd. MaxSpareServers- og MinSpareServers-direktiverne angiver, hvor mange processer/tråde der skal vente klar til at acceptere en anmodning (maksimum og minimum).
Hvis MinSpareServers værdien er meget lille, og der kommer mange anmodninger på én gang, bliver apache nødt til at oprette mange nye processer/tråde, hvilket vil skabe yderligere belastning i denne stressende situation. På den anden side, hvis MaxSpareServers er meget stor, vil apache belaste systemet kraftigt med disse processer, selvom antallet af klienter ikke er stort.
Prøv at indstille MinSpareServers og MaxSpareServers således, at apache ikke skaber mere end fire processer/tråde i sekundet. Hvis det opretter mere end 4, vil en besked om dette blive placeret i ErrorLog. Dette er et signal om, at MinSpareServers er meget utilfredse.
MaxRequestsPerChild
MaxRequestsPerChild-direktivet angiver, hvor mange anmodninger en underordnet proces/tråd kan behandle, før den afsluttes. Som standard er værdien af dette direktiv sat til 0, hvilket betyder, at når først en proces/tråd er oprettet, vil den aldrig blive afsluttet (vel, ikke medregnet tilfælde, hvor serveren er stoppet eller denne proces/tråd går ned).
Jeg anbefaler at sætte MaxRequestsPerChild lig med noget tilstrækkeligt et stort antal(flere tusinde). Dette vil ikke skabe unødig belastning på grund af det faktum, at apache bliver nødt til at skabe nye underordnede processer, samtidig vil det hjælpe med at slippe af med problemer med hukommelseslækager i underordnede processer (hvilket meget vel kan ske, hvis du f.eks. bruger en ustabil version af PHP).
KeepAlive og KeepAliveTimeout
KeepAlive giver dig mulighed for at lave flere anmodninger på en enkelt TCP-forbindelse. Dette er især nyttigt for HTML-sider med mange billeder.
Hvis KeepAlive er sat til Off, vil der blive oprettet en separat forbindelse til selve siden og for hvert billede (som skal behandles af masterprocessen), hvilket er dårligt for både serveren og klienten. Så for lignende tilfælde anbefales det at indstille KeepAlive til On.
For andre applikationer (for eksempel til en downloadserver) kan KeepAlive være ubrugelig og endda skadelig, fordi Når KeepAlive er aktiveret, lukker serveren ikke forbindelsen med det samme, men venter i KeepAliveTimeout sekunder på en ny anmodning. For at forhindre processer i at hænge rundt i ubrugelig ventetid i meget lang tid, skal du indstille KeepAliveTimeout lille nok, ca. 5-10 sekunder er normalt nok.
Kompression
HTTP-komprimering blev defineret i HTTP/1.1-mønsteret, og nu understøtter alle moderne klientprogrammer og næsten alle servere det. Serveren kan returnere svaret i gzip eller deflate, og klientprogram Dekomprimerer data ubemærket af brugeren. Dette reducerer mængden af transmitteret trafik (op til 75%), men øger naturligvis processorimplementeringen.
Men hvis din server besøges af mange klienter på en langsom forbindelse, kan komprimering reducere belastningen på din server, fordi serveren kan levere det komprimerede svar hurtigere og frigøre ressourcer optaget af den underordnede proces. Denne effekt kan især være mærkbar, hvis du har en hurtig processor, men ikke nok hukommelse.
Caching ændres af direktiver fra mod_deflate-modulet. Husk på, at du ikke bør indstille gzip-komprimeringsniveauet til mere end 4-5 – det vil kræve væsentligt mere CPU-tid, og effekten bliver ret lille. Nå, selvfølgelig, du behøver ikke at prøve at komprimere billeder til jpg, gif og png, musik, videofiler og alle andre binære filer, som allerede er perfekt komprimeret.
Caching på klientsiden
Glem ikke at indstille Expires-titler på statiske filer (se mod_expires-modulet). Hvis filen ikke ændres, skal den altid cachelagres på klienten. Så vil klientens sider indlæses hurtigere, og serveren vil være fri for unødvendige anmodninger.
Fremragende artikel, genoptrykt fra Highload-webstedet.
Vi læser også:
- Script til optimering af Mysql-ydelse
- AWStats loganalysator til statistik
- FTP-server baseret på vsftpd og MySQL i Debian (Ubuntu)
- Implementering af mod_macro til konfiguration virtuelle værter Apache
- Kontrollerer Linux-serveren for hacking
En anden måde er blot at øge serverens ydeevne - installer en hurtigere processor og mere hukommelse.
Både den første og den anden kræver dog meget tid og ressourcer, så for første gang kan du forsøge at fremskynde Apache ved at optimere dens konfiguration. Der er optimeringer, der kun kan anvendes ved genopbygning af Apache, mens andre kan anvendes uden at genkompilere serveren.
Indlæs kun nødvendige moduler
Apache er et modulært program, hvor de fleste af funktionerne er implementeret i moduler. Desuden kan disse moduler enten kompileres eller samles i form af DSO - dynamiske biblioteker. De fleste moderne distributioner sender Apache med et sæt DSO'er, så unødvendige moduler nemt kan deaktiveres uden omkompilering.Kør kun apache med de nødvendige moduler for at reducere hukommelsesforbruget. Hvis du beslutter dig for selv at kompilere apache, så vær enten selektiv med hensyn til listen over moduler, du inkluderer, eller kompilér dem som DSO'er ved hjælp af apxs i apache1 og apxs2 i apache2. For at deaktivere unødvendige DSO-moduler, skal du blot kommentere de ekstra LoadModule-linjer i httpd.conf. Apache med statisk kompilerede moduler vil bruge lidt mindre hukommelse, men du bliver nødt til at omkompilere den hver gang for at ændre listen over moduler.
Vælg den passende MPM
I Apache behandles hver anmodning i sin egen proces eller tråd. Når den er kompileret, giver apache dig mulighed for at vælge en af flere MPM'er (Multi-processing moduler), som er ansvarlige for at lytte på porte, acceptere anmodninger og distribuere disse anmodninger til underordnede processer eller tråde, hvori disse anmodninger vil blive behandlet.Valget af MPM afhænger af flere faktorer, såsom om operativsystemet har threading-understøttelse, mængden af ledig hukommelse og stabilitets- og sikkerhedskrav.
Hvis sikkerhed er meget vigtigt, bør du vælge peruser MPM, hvilket ofrer ydeevnen.
Hvis ydeevne er vigtig, så er valget begrænset til to mpm: forgaffel og arbejder.
Arbejder - gevind MPM, dvs. i den serveres hver anmodning i en separat tråd i en af de underordnede processer. Tråde er lettere objekter for operativsystemet end processer, de bruger hukommelse mere effektivt, og kontekstskift er hurtigere for dem. Men fordi hver tråd har adgang til hele processens hukommelse, er worker mpm mere tilbøjelig til at gå ned: fejl i en tråd kan få hele processen, hvori tråden var placeret, til at gå ned (hvilket er grunden til worker mpm starter flere underordnede processer med flere tråde i hver ).
Perfork - mpm bruger flere underordnede processer, hver underordnede proces håndterer én forbindelse. Fordi processen er en tungere struktur, bruger den lidt flere ressourcer, men den er mindre tilbøjelig til at fejle - behandlingen af hver enkelt anmodning afhænger ikke af andre processer.
Desværre kræver ændring af mpm genkompilering af Apache. Det er her kildebaserede distributioner viser deres fordele: du kan nemt omkompilere Apache og alle dens afhængige pakker uden at gøre systemet til et dump. Binære distributioner håndterer denne situation på forskellige måder. For eksempel, i RHEL, indeholder apache rpm to versioner af apache - med worker og prefork mpm (prefork bruges som standard). Worker mpm understøtter dog ikke php. Så hvis du vil have php og worker mpm, bliver du nødt til at kompilere det selv eller lede efter tredjeparts repositories.
DNS-forespørgsler
HostnameLookups-direktivet muliggør omvendte DNS-forespørgsler, så klientens DNS-navne vises i logfilerne i stedet for IP-adresser. Det bremser naturligvis behandlingen af anmodningen betydeligt, fordi... anmodningen behandles ikke, før der modtages et svar fra DNS-serveren. Sørg derfor for, at dette direktiv altid er slået fra (HostnameLookups Off), og hvis du stadig har brug for DNS-adresser, kan du finde ud af dem senere ved at køre loggen i logresolve-værktøjet (som følger med Apache).Sørg desuden for, at Tillad fra- og Afvis fra-direktiverne bruger IP-adresser og ikke domænenavne. Ellers vil apache lave to DNS-anmodninger (tilbage og frem) for at sikre, at klienten er den, han hævder at være.
TilladOverride
Hvis AllowOverride-direktivet ikke er sat til "Ingen", vil apache forsøge at åbne .htaccess-filer i hver mappe, den besøger, og i alle mapper over den. For eksempel:DocumentRoot /var/www/html
Hvis /index.html anmodes om, vil apache forsøge at åbne (og fortolke) filerne /.htaccess, /var/.htaccess, /var/www/.htaccess og /var/www/html/.htaccess. Dette øger anmodningsbehandlingstiden. Så hvis du kun har brug for .htaccess for én mappe, tillad det kun for den mappe:
DocumentRoot /var/www/html
FølgSymLinks og SymLinksIfOwnerMatch
Hvis indstillingen FollowSymLinks er aktiveret for en mappe, vil serveren følge de symbolske links i den mappe. Hvis indstillingen SymLinksIfOwnerMatch er aktiveret for en mappe, vil apache kun følge symbolske links, hvis ejeren af filen eller mappen, som linket peger på, matcher ejeren af den angivne mappe. Så når SymLinksIfOwnerMatch-indstillingen er aktiveret, foretager apache flere systemanmodninger.Derudover kræves yderligere systemanmodninger, når FollowSymlinks IKKE ER INSTALLERET. At. mest optimal situation for ydeevne - når indstillingen FollowSymlinks er aktiveret.
Indholdsforhandling
Prøv at undgå indholdsforhandling.MaxClients
MaxClients-direktivet angiver det maksimale antal samtidige anmodninger, som serveren vil understøtte. Apache vil ikke skabe flere processer/tråde end MaxClients. MaxClient-værdien bør ikke være for lille (ellers vil mange klienter forblive ubetjente), men du bør ikke indstille tallet for stort - det er bedre ikke at betjene nogle klienter end at opbruge alle ressourcer, gå i bytte og dø under belastning. En god værdi kan være MaxClients = mængden af hukommelse, der er allokeret til webserveren / den maksimale størrelse af den afledte proces eller tråd. For statiske filer bruger apache omkring 2-3 MB pr. proces, for dynamiske filer (php, cgi) - afhænger af scriptet, men normalt omkring 16-32 MB.Du kan estimere den omtrentlige størrelse ved at se på rss-kolonnen i outputtet af `ps -ylC httpd --sort:rss`
Hvis serveren allerede betjener MaxClients af anmodninger, vil nye anmodninger blive sat i kø, hvis størrelse er indstillet ved hjælp af ListenBacklog-direktivet.
MinSpareServers, MaxSpareServers og StartServers
Fordi At skabe en tråd, og især en proces, er en dyr operation, som apache skaber dem på forhånd. MaxSpareServers- og MinSpareServers-direktiverne angiver, hvor mange processer/tråde der skal vente klar til at acceptere en anmodning (maksimum og minimum). Hvis MinSpareServers værdien er for lille, og mange anmodninger kommer uventet, vil apache være tvunget til at oprette mange nye processer/tråde, hvilket vil skabe yderligere belastning i denne stressende situation. På den anden side, hvis MaxSpareServers er for stor, vil apache belaste systemet kraftigt med disse processer, selvom antallet af klienter er minimalt.Prøv at indstille MinSpareServers og MaxSpareServers således, at apache ikke skaber mere end 4 processer/tråde i sekundet. Hvis det opretter mere end 4, vil en besked om dette blive placeret i ErrorLog. Dette er et signal om, at MinSpareServers er for lille.
MaxRequestsPerChild
MaxRequestsPerChild-direktivet angiver, hvor mange anmodninger en underordnet proces/tråd kan behandle, før den afsluttes. Som standard er værdien af dette direktiv sat til 0, hvilket betyder, at når først en proces/tråd er oprettet, vil den aldrig blive afsluttet (nå, undtagen når serveren stopper eller denne proces/tråd går ned). Jeg anbefaler at sætte MaxRequestsPerChild lig med et ret stort antal (flere tusinde). Dette vil ikke skabe unødvendig belastning på grund af det faktum, at apache vil blive tvunget til at oprette nye underordnede processer, samtidig vil det hjælpe med at slippe af med problemer med hukommelseslækager i underordnede processer (hvilket er meget muligt, hvis du f.eks. bruger en ustabil version af php).KeepAlive og KeepAliveTimeout
KeepAlive giver dig mulighed for at lave flere anmodninger på en enkelt TCP-forbindelse. Dette er især nyttigt for html-sider med et stort antal billeder. Hvis KeepAlive er sat til Off, vil der blive oprettet en separat forbindelse til selve siden og for hvert billede (som skal behandles af masterprocessen), hvilket er dårligt for både serveren og klienten. Så i sådanne tilfælde anbefales det at indstille KeepAlive til On. For andre applikationer (for eksempel til en downloadserver) kan KeepAlive være ubrugelig og endda skadelig, fordi Når KeepAlive er aktiveret, lukker serveren ikke forbindelsen med det samme, men venter i KeepAliveTimeout sekunder på en ny anmodning. For at forhindre, at processer hænger unødigt og venter for længe, skal du indstille KeepAliveTimeout lille nok, ca. 5-10 sekunder er normalt tilstrækkeligt.Kompression
HTTP-komprimering blev defineret i HTTP/1.1-standarden, og nu understøtter alle moderne klientprogrammer og næsten alle servere det. Serveren kan returnere svaret i gzip eller deflate, og klientprogrammet dekomprimerer dataene ubemærket af brugeren. Dette reducerer mængden af overført trafik (op til 75%), men øger naturligvis CPU-bruget.Men hvis din server besøges af mange klienter på langsomme forbindelser, kan komprimering reducere belastningen på din server, fordi serveren kan levere det komprimerede svar hurtigere og frigøre ressourcer optaget af den underordnede proces. Denne effekt kan især være mærkbar, hvis du har en hurtig processor, men lidt hukommelse.
Caching er konfigureret af mod_deflate-moduldirektiver. Husk på, at du ikke bør indstille gzip-komprimeringsniveauet til mere end 4-5 – det vil kræve væsentligt mere CPU-tid, og effekten bliver ret lille. Nå, selvfølgelig er der ingen grund til at forsøge at komprimere billeder til jpg, gif og png, musik, videofiler og alle andre binære filer, der allerede er godt komprimeret.
Caching på klientsiden
Glem ikke at indstille Expires-headere på statiske filer (se mod_expires-modulet). Hvis filen ikke ændres, bør du altid prøve at cache den på klienten. Så vil klientens sider indlæses hurtigere, og serveren vil være fri for unødvendige anmodninger.Original: "Konfiguration af Apache for maksimal ydeevne". Vishnu Ram V: http://linuxgazette.net/123/vishnu.html