Ge inte efter för en lavin: Förbereda webbservern för höga belastningar. Inaktiverar värdnamnsupplösning
Introduktion
Enligt Netcraft är Apache den mest populära webbservern på Internet, det
betjänar många servrar och webbplatser. Det finns ofta ett behov
öka webbserverns prestanda. Kanske Det bästa sättet Detta
gör - gå till frontend+backend-schemat, men detta kan kräva
ganska allvarliga ändringar i applikationen (till exempel har du förmodligen
alla typer av förloppsindikatorer för filuppladdning kommer att falla bort).
Ett annat sätt är att helt enkelt öka serverns prestanda - putt
snabbare processor och mer minne.
Men både den första och andra kräver mycket tid och resurser, så
till en början kan du försöka påskynda apache genom att optimera den
konfigurationer. Det finns optimeringar som bara kan tillämpas
när man bygger om Apache kan andra användas utan omkompilering
server.
Ladda endast nödvändiga moduler
Apache är ett modulärt program, vars de flesta funktioner är implementerade
i moduler. Dessutom kan dessa moduler antingen kompileras eller
samlas in i form av DSO - dynamiska bibliotek. Mest moderna
distributioner skickar apache med en uppsättning DSO:er, så inga moduler behövs
kan enkelt inaktiveras utan omkompilering.
Kör apache med endast de nödvändiga modulerna för att minska
minnesförbrukning. Om du bestämmer dig för att kompilera apache
själv, välj sedan noggrant en lista med moduler,
som du inkluderar, eller kompilera dem som DSO med apxs in
apache1 och apxs2 till apache2. För att inaktivera onödigt
DSO-moduler, kommentera bara de extra raderna i LoadModule in
httpd.conf. Apache med statiskt kompilerade moduler kommer
förbrukar lite mindre minne, men du måste använda det varje gång
kompilera om för att ändra listan med moduler.
Välj lämplig MPM
I Apache bearbetas varje begäran i sin egen process eller tråd. På
Apache-kompilering låter dig välja en av flera MPM
(Multi-processing modul), som är ansvariga för att lyssna på portar,
ta emot förfrågningar och distribuera dessa förfrågningar till underordnade processer eller trådar,
där dessa förfrågningar kommer att behandlas.
Valet av MPM beror på flera faktorer, såsom tillgången på support
trådar i OS, nummer ledigt minne, samt krav
stabilitet och säkerhet.
Om säkerhet är mycket viktigt, bör du välja peruser MPM, offra
produktivitet.
Om prestandan är viktig är valet begränsat till två
mpm: förgaffel och arbetare.
Arbetare - gängad MPM, d.v.s. i den betjänas varje begäran
en separat tråd för en av de underordnade processerna. Strömmar är lättare
för OS-objekt än processer använder de minnet mer effektivt och
Kontextväxlingar är snabbare för dem. Men eftersom
att varje tråd har tillgång till allt processminne, worker mpm är mer
benägen att misslyckas: fel i en tråd kan göra att det hela misslyckas
processen den här tråden var i (det är därför worker mpm
startar flera underordnade processer med flera trådar in
varje).
Perfork - mpm använder flera underordnade processer, varje barn
processen hanterar en anslutning. På grund av det faktum att processen är mer
tung struktur, det använder lite mer resurser, men det är mindre
benägna att misslyckas - behandlingen av varje enskild begäran beror inte på
andra processer.
Tyvärr kräver ändring av mpm omkompilering av Apache. Här
källbaserade distributioner visar sina fördelar: du kan enkelt
kompilera om apache och alla dess beroende paket utan att ändras
systemet till soptippen. Binära distributioner kommer ur denna situation
annorlunda. Till exempel, i RHEL finns det två versioner i apache rpm
apache - med worker och prefork mpm (prefork används som standard).
Worker mpm stöder dock inte php. Så om du vill ha php och
worker mpm måste du kompilera den själv eller söka efter
tredje parts arkiv.
DNS-sökning
HostnameLookups-direktivet inkluderar omvända DNS-frågor, så loggarna
klienternas DNS-värdar kommer att inkluderas istället för IP-adresser. Självklart det
detta avsevärt saktar ner behandlingen av begäran, eftersom ingen efterfrågan
bearbetas tills den får ett svar från DNS-servern. Det är därför
Se till att detta direktiv alltid är inaktiverat (HostnameLookups
Av), och om du fortfarande behöver DNS-adresser kan du hitta dem senare,
genom att köra loggen i logresolve-verktyget (som följer med Apache).
Se dessutom till att i Tillåt från och neka från-direktiven
IP-adresser användes och inte domännamn. Annars duger apache
två DNS-förfrågningar (bakåt och framåt) för att säkerställa att klienten är rätt
vem han utger sig för att vara.
Tillåt Åsidosätt
Om AllowOverride-direktivet inte är inställt på "None", kommer apache att göra det
försök att öppna .htaccess-filer i varje katalog
besök i alla kataloger ovanför. Till exempel:
DocumentRoot /var/www/html
Tillåt Åsidosätt alla
Om /index.html efterfrågas kommer apache att försöka öppna (och
interpret) filer /.htaccess, /var/.htaccess, /var/www/.htaccess,
och /var/www/html/.htaccess. Detta ökar handläggningstiden för begäran. Så
vad händer om du behöver .htaccess för bara en katalog, tillåt
det är bara för henne:
DocumentRoot /var/www/html
AllowOverride Ingen
Tillåt Åsidosätt alla
FöljSymLinks och SymLinksIfOwnerMatch
Om alternativet FollowSymLinks är aktiverat för en katalog kommer servern att göra det
följ de symboliska länkarna i den här katalogen. Om för
katalogen, alternativet SymLinksIfOwnerMatch är aktiverat, kommer apache att följa
via symboliska länkar endast om ägaren till filen eller katalogen är det
som den här länken anger matchar ägaren till den angivna
kataloger. Så med alternativet SymLinksIfOwnerMatch aktiverat apache
gör fler systemförfrågningar.
Dessutom ytterligare systemförfrågningar krävs när
FollowSymlinks ÄR INTE INSTALLERAD. Den där. den mest optimala situationen för
prestanda - när alternativet FollowSymlinks är aktiverat.
Innehållsförhandling
Försök undvika innehållsförhandlingar.
MaxClients
MaxClients-direktivet sätter högsta belopp parallell
begär att servern kommer att stödja. Apache kommer inte att skapas
fler processer/trådar än MaxClients. MaxClient-värdet är inte tillräckligt
vara för liten (annars kommer många kunder att förbli obetjänade),
men du bör inte ställa in för stor mängd - det är bättre att inte
betjäna vissa kunder än att uttömma alla resurser, komma in i swap och
dö under belastning. Ett bra värde kan vara MaxClients =
mängd minne som tilldelats för webbservern / maximal storlek
barnprocess eller tråd. För statisk apache-filer
använder cirka 2-3 MB per process, för dynamik (php, cgi) - beror
från skriptet, men vanligtvis cirka 16-32 MB.
Du kan uppskatta den ungefärliga storleken genom att titta på rss-kolumnen i utdata
`ps -ylC httpd —sort:rss`
Om servern redan betjänar MaxClients-förfrågningar kommer nya förfrågningar att falla
till en kö vars storlek ställs in med ett direktiv
LyssnaBacklog.
MinSpareServers, MaxSpareServers och StartServers
Därför att att skapa en tråd, och särskilt en process, är en dyr operation, apache
skapar dem i förväg. MaxSpareServers och MinSpareServers direktiv
ställ in hur många processer/trådar som ska vänta redo
acceptera begäran (högsta och lägsta). Om värdet av MinSpareServers
för liten och oväntat många förfrågningar kommer, apache tvingas fram
kommer att skapa många nya processer/trådar, som kommer att skapa
ytterligare börda i detta stressig situation. På andra sidan,
om MaxSpareServers är för stor kommer apache att vara tungt laddad
system genom dessa processer, även om antalet klienter är minimalt.
Försök att ställa in MinSpareServers och MaxSpareServers så att
apache skapade inte mer än 4 processer/trådar per sekund. Om han skapar
fler än 4, kommer ett meddelande om detta att placeras i ErrorLog. Detta är en signal om att
att MinSpareServers är för liten.
MaxRequestsPerChild
MaxRequestsPerChild-direktivet anger hur många förfrågningar som kan vara
bearbeta en underordnad process/tråd innan den avslutas. Förbi
Som standard är värdet för detta direktiv satt till 0, vilket betyder att
en gång skapad kommer en process/tråd aldrig att avslutas (ja, förutom
fall där servern stannar eller processen/tråden kraschar). jag rekomenderar
ställ in MaxRequestsPerChild på något som är tillräckligt stort
antal (flera tusen). Detta kommer inte att skapa onödig stress i samband med
det faktum att apache kommer att tvingas skapa nya underordnade processer, medan
Samtidigt kommer detta att hjälpa till att bli av med problem med minnesläckor hos barn
processer (vilket är mycket möjligt, till exempel om du använder en instabil
php-version).
KeepAlive och KeepAliveTimeout
KeepAlive låter dig göra flera förfrågningar på en enda TCP-anslutning.
Detta är särskilt användbart för html-sidor med många
bilder. Om KeepAlive är inställt på Av, då för själva sidan och
för varje bild kommer att skapas separat anslutning(som
kommer att behöva bearbetas av huvudprocessen), vilket är dåligt för både servern och
klient. Så för sådana fall rekommenderas det att installera
KeepAlive på. För andra applikationer (till exempel för en nedladdningsserver)
KeepAlive kan vara värdelöst och till och med skadligt, eftersom... när den är påslagen
KeepAlive-servern stänger inte anslutningen omedelbart, utan väntar på KeepAliveTimeout
sekunder av ny begäran. För att förhindra att processer hänger sig för länge
i värdelös väntan, ställ in KeepAliveTimeout tillräckligt
liten brukar ca 5-10 sekunder vara lagom.
Kompression
HTTP-komprimering definierades i HTTP/1.1-standarden och är nu
moderna klientprogram och nästan alla dess servrar
Stöd. Servern kan returnera svaret i gzip eller deflate, och
klientprogrammet dekomprimerar data obemärkt av användaren. Detta
minskar mängden överförd trafik (upp till 75%), men naturligtvis
ökar CPU-användningen.
Men om din server besöks av många klienter med långsamma anslutningar,
komprimering kan minska belastningen på din server på grund av att servern
kommer att kunna överföra ett komprimerat svar snabbare och frigöra upptagna resurser
barnprocess. Denna effekt kan vara särskilt märkbar om
Du har en snabb processor, men lite minne.
Caching konfigureras av mod_deflate-moduldirektiv. Hålla inne
Observera att du inte bör ställa in gzip-komprimeringsnivån till mer än 4-5 - detta
kommer att kräva betydligt mer CPU-tid, men effekten kommer att vara tillräcklig
små. Jo, naturligtvis, det finns ingen anledning att försöka komprimera bilder till jpg, gif
och png, musik, videofiler och alla andra binära filer som redan finns
så bra komprimerad.
Cachning på klientsidan
Glöm inte att ställa in Expires-rubriker på statiska filer (se.
mod_expires modul). Om filen inte ändras bör den alltid vara det
försök cachelagra på klienten. Då har klienten snabbare
sidor kommer att laddas och servern kommer att befrias från onödiga förfrågningar.
Apache är en populär webbserver på Internet, den betjänar många servrar och webbplatser. Det finns ofta ett behov av att öka prestandan på en webbserver. Förmodligen är det bästa sättet att göra detta att byta till frontend+backend-schemat, men detta kan kräva ganska allvarliga ändringar i applikationen (till exempel kommer du förmodligen att förlora alla möjliga indikatorer för filuppladdningsförlopp :).
Ett annat sätt är att helt enkelt öka serverns prestanda – installera en snabbare processor och mer minne.
Både den första och den andra kräver dock mycket tid och resurser, så för första gången kan du försöka påskynda Apache genom att optimera dess konfiguration. Det finns optimeringar som bara kan tillämpas när man bygger om Apache, medan andra kan tillämpas utan att kompilera om servern.
Ladda endast nödvändiga moduler
Apache är ett modulärt program, med det mesta av dess funktionalitet implementerad i moduler. Dessutom kan dessa moduler antingen kompileras eller monteras i form av DSO - dynamiska bibliotek. De flesta moderna distributioner levererar Apache med en uppsättning DSO:er, så att onödiga moduler enkelt kan inaktiveras utan omkompilering.
Kör apache med endast de nödvändiga modulerna för att minska minnesförbrukningen. Om du bestämmer dig för att kompilera apache själv, var antingen selektiv med listan över moduler du inkluderar, eller kompilera dem som DSO:er med apxs i apache1 och apxs2 i apache2. För att inaktivera onödiga DSO-moduler, kommentera bara de extra LoadModule-raderna i httpd.conf. Apache med statiskt kompilerade moduler kommer att förbruka något mindre minne, men du måste kompilera om den varje gång för att ändra listan med moduler.
Välj lämplig MPM
I Apache bearbetas varje begäran i sin egen process eller tråd. När den är kompilerad låter apache dig välja en av flera MPM (Multi-processing modules), som är ansvariga för att lyssna på portar, acceptera förfrågningar och distribuera dessa förfrågningar till underordnade processer eller trådar där dessa förfrågningar kommer att behandlas.
Valet av MPM beror på flera faktorer, såsom om operativsystemet har trådningsstöd, mängden ledigt minne och stabilitets- och säkerhetskrav.
Om säkerhet är mycket viktigt, bör du välja peruser MPM, vilket offra prestanda.
Om prestandan är viktig är valet begränsat till två mpm: pregaffel och worker.
Arbetstagare- flödes-MPM, dvs. i den serveras varje begäran i en separat tråd i en av de underordnade processerna. Trådar är enklare objekt för operativsystemet än processer de använder minnet mer effektivt och kontextväxlar är snabbare för dem. Men eftersom varje tråd har tillgång till hela processens minne, är worker mpm mer benägna att kraschar: fel på en tråd kan göra att hela processen där tråden fanns att krascha (vilket är anledningen till att worker mpm startar flera underordnade processer med flera trådar i varje ).
Pergaffel- mpm använder flera underordnade processer, varje underordnad process hanterar en anslutning. Eftersom processen är en tyngre struktur använder den något mer resurser, men den är mindre benägen att misslyckas – behandlingen av varje enskild begäran beror inte på andra processer.
Tyvärr kräver ändring av mpm omkompilering av Apache. Det är här källbaserade distributioner visar sina fördelar: du kan enkelt kompilera om Apache och alla dess beroende paket utan att göra systemet till en dump. Binära distributioner hanterar denna situation på olika sätt. Till exempel, i RHEL, innehåller apache rpm två versioner av apache - med worker och prefork mpm (prefork används som standard). Worker mpm stöder dock inte php. Så om du vill ha php och worker mpm måste du kompilera det själv eller leta efter tredjepartsförråd.
DNS-sökning
HostnameLookups-direktivet möjliggör omvända DNS-frågor, så att klientens DNS-värdar visas i loggarna istället för IP-adresser. Detta fördröjer naturligtvis behandlingen av förfrågan avsevärt, eftersom... begäran behandlas inte förrän den får ett svar från DNS-servern. Se därför till att detta direktiv alltid är avstängt (HostnameLookups Off), och om du fortfarande behöver DNS-adresser kan du ta reda på dem senare genom att köra loggen i logresolve-verktyget (som följer med Apache).
Se dessutom till att Allow from och Deny From-direktiven använder IP-adresser och inte domännamn. Annars kommer apache att göra två DNS-förfrågningar (bakåt och framåt) för att säkerställa att klienten är den han utger sig för att vara.
Tillåt Åsidosätt
Om AllowOverride-direktivet inte är inställt på "None", kommer apache att försöka öppna .htaccess-filer i varje katalog som den besöker och i alla kataloger ovanför den. Till exempel:
DocumentRoot /var/www/html
Om /index.html efterfrågas kommer apache att försöka öppna (och tolka) filerna /.htaccess, /var/.htaccess, /var/www/.htaccess och /var/www/html/.htaccess. Detta ökar handläggningstiden för begäran. Så om du bara behöver .htaccess för en katalog, tillåt det bara för den katalogen:
DocumentRoot /var/www/html
FöljSymLinks och SymLinksIfOwnerMatch
Om alternativet FollowSymLinks är aktiverat för en katalog kommer servern att följa de symboliska länkarna i den katalogen. Om alternativet SymLinksIfOwnerMatch är aktiverat för en katalog, följer apache symboliska länkar endast om ägaren till filen eller katalogen som länken pekar på matchar ägaren till den angivna katalogen. Så när alternativet SymLinksIfOwnerMatch är aktiverat gör apache fler systemförfrågningar.
Dessutom krävs ytterligare systemförfrågningar när FollowSymlinks INTE ÄR INSTALLERAD. Den där. Den bästa prestandasituationen är när alternativet FollowSymlinks är aktiverat.
Innehållsförhandling
Försök undvika innehållsförhandlingar.
MaxClients
MaxClients-direktivet anger det maximala antalet samtidiga förfrågningar som servern kommer att stödja. Apache kommer inte att skapa fler processer/trådar än MaxClients. MaxClient-värdet bör inte vara för litet (annars kommer många klienter att förbli obetjänade), men du bör inte ställa in siffran för högt - det är bättre att inte betjäna vissa klienter än att förbruka alla resurser, gå in i swap och dö under belastning. Ett bra värde kan vara MaxClients = mängd minne som allokerats för webbservern / maximal storlek på den skapade processen eller tråden. För statiska filer använder apache cirka 2-3 MB per process, för dynamiska filer (php, cgi) - beror på skriptet, men vanligtvis cirka 16-32 MB.
Om servern redan betjänar MaxClients av förfrågningar, kommer nya förfrågningar att ställas i kö, vars storlek ställs in med ListenBacklog-direktivet.
MinSpareServers, MaxSpareServers och StartServers
Därför att Att skapa en tråd, och särskilt en process, är en dyr operation som apache skapar dem i förväg. MaxSpareServers- och MinSpareServers-direktiven anger hur många processer/trådar som ska vänta redo för att acceptera en begäran (maximal och minimum). Om MinSpareServers-värdet är för litet och många förfrågningar kommer oväntat, kommer apache att tvingas skapa många nya processer/trådar, vilket kommer att skapa ytterligare belastning i denna stressiga situation. Å andra sidan, om MaxSpareServers är för stor, kommer apache att belasta systemet kraftigt med dessa processer, även om antalet klienter är minimalt.
Försök att ställa in MinSpareServers och MaxSpareServers så att apache inte skapar mer än 4 processer/trådar per sekund. Om det skapar fler än 4 kommer ett meddelande om detta att placeras i ErrorLog. Detta är en signal om att MinSpareServers är för liten.
MaxRequestsPerChild
MaxRequestsPerChild-direktivet anger hur många förfrågningar en underordnad process/tråd kan behandla innan den avslutas. Som standard är värdet för detta direktiv satt till 0, vilket betyder att när en process/tråd väl har skapats kommer den aldrig att avslutas (nåja, förutom när servern stannar eller den här processen/tråden kraschar). Jag rekommenderar att sätta MaxRequestsPerChild lika med ett ganska stort antal (flera tusen). Detta kommer inte att skapa onödig belastning på grund av det faktum att apache kommer att tvingas skapa nya underordnade processer, samtidigt kommer det att hjälpa till att bli av med problem med minnesläckor i underordnade processer (vilket är mycket möjligt, till exempel om du är använder en instabil version av php).
KeepAlive och KeepAliveTimeout
KeepAlive låter dig göra flera förfrågningar på en enda TCP-anslutning. Detta är särskilt användbart för HTML-sidor med många bilder. Om KeepAlive är inställt på Av kommer en separat anslutning att skapas för själva sidan och för varje bild (som kommer att behöva bearbetas av masterprocessen), vilket är dåligt för både servern och klienten. Så för sådana fall rekommenderas det att ställa in KeepAlive på On. För andra applikationer (till exempel för en nedladdningsserver) kan KeepAlive vara värdelöst och till och med skadligt, eftersom När KeepAlive är aktiverat stänger inte servern anslutningen omedelbart, utan väntar i KeepAliveTimeout sekunder på en ny begäran. För att förhindra att processer hänger runt i onödan väntar för länge, ställ in KeepAliveTimeout tillräckligt liten, cirka 5-10 sekunder är vanligtvis tillräckligt.
Kompression
HTTP-komprimering definierades i HTTP/1.1-standarden, och nu stöder alla moderna klientprogram och nästan alla servrar det. Servern kan returnera svaret i gzip eller deflate, och klientprogrammet dekomprimerar data obemärkt av användaren. Detta minskar mängden trafik som överförs (upp till 75%), men ökar naturligtvis CPU-användningen.
Men om din server besöks av många klienter på en långsam anslutning kan komprimering minska belastningen på din server eftersom servern kan leverera det komprimerade svaret snabbare och frigöra resurser som upptas av den underordnade processen. Denna effekt kan vara särskilt märkbar om du har en snabb processor men lite minne.
Caching konfigureras av mod_deflate-moduldirektiv. Tänk på att du inte bör ställa in gzip-komprimeringsnivån till mer än 4-5 - detta kommer att kräva betydligt mer CPU-tid, och effekten blir ganska liten. Jo, det finns naturligtvis ingen anledning att försöka komprimera bilder till jpg, gif och png, musik, videofiler och alla andra binära filer som redan är väl komprimerade.
Alls, om du kan lyft inte Apache, gör inte det. Fundera på om lighttpd eller thttpd kan utföra de uppgifter du behöver. Dessa webbservrar kan komma till stor nytta i situationer där systemresurser Det räcker inte till alla, men det måste fungera. Jag upprepar ännu en gång: vi pratar om de situationer då dessa produkters funktionalitet kommer att vara tillräcklig för att slutföra de tilldelade uppgifterna (förresten, lighttpd vet hur man arbetar med PHP). I de situationer där utan Apache Tja, det finns helt enkelt ingen väg runt det, du kan vanligtvis frigöra mycket systemresurser ändå genom att omdirigera förfrågningar till statiskt innehåll (JavaScript, grafik) från Apache till en lätt HTTP-server. Det största problemet Apacheär hans stora aptit på random access minne. I den här artikeln kommer jag att titta på metoder som hjälper till att påskynda arbetet och minska mängden minne som det tar upp:
Laddar färre moduler
Det första steget är att bli av med onödiga moduler från laddning. Granska konfigurationsfilerna och bestäm vilka moduler du laddar. Behöver du alla nedladdningsbara moduler? Hitta något som inte används och stäng av det, det sparar lite minne.
Behandla färre samtidiga förfrågningar
Ju fler processer Apache får köra samtidigt, desto mer samtidiga förfrågningar han kan bearbeta det. Genom att öka detta antal ökar du därmed mängden minne som allokeras till Apache. Med hjälp av toppen kan du se att varje process Apache Det tar väldigt lite minne eftersom delade bibliotek används. I Debian 5 Med Apache 2 Standardkonfigurationen är denna:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0
Direktiv StartServer bestämmer antalet serverprocesser som startas initialt, omedelbart efter dess start. direktiv MinSpareServers Och MaxSpareServers bestämma det lägsta och högsta antalet "reserv"-processer för barn Apache. Sådana processer väntar på inkommande förfrågningar och avlastas inte, vilket gör det möjligt att snabba upp serverns svar på nya förfrågningar. Direktiv MaxClients definierar det maximala antalet parallella förfrågningar som samtidigt behandlas av servern. När antalet samtidiga anslutningar överstiger detta antal kommer nya anslutningar att köas för bearbetning. I själva verket direktivet MaxClients och bestämmer det högsta tillåtna antalet underordnade processer Apache,lanseras samtidigt. Direktiv MaxRequestsPerChild definierar antalet förfrågningar som den underordnade processen måste behandla Apache innan den avslutar sin existens. Om värdet på detta direktiv är inställt på noll, kommer processen inte att "upphöra".
För din hemmaserver, med motsvarande behov, korrigerade jag konfigurationen till följande:
StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300
Naturligtvis är ovanstående konfiguration helt olämplig för användning på högbelastade servrar, men för hemmet är det enligt min mening helt rätt.
Processcirkulation
Som ni ser ändrade jag värdet på direktivet MaxRequestsPerChild. Genom att begränsa livslängden för underordnade processer på detta sätt med antalet bearbetade förfrågningar kan du undvika oavsiktliga minnesläckor orsakade av dåligt skrivna skript.
Använder KeepAlives som inte är för långa
Håll vid livär en stödmetod permanent anslutning mellan klient och server. Initialt HTTP-protokoll designades för att inte vara orienterad mot beständiga anslutningar. Det vill säga när en webbsida skickas till en klient överförs alla dess delar (bilder, ramar, JavaScript) med hjälp av olika, separat etablerade anslutningar. Med advent Håll vid liv, webbläsare har nu möjlighet att begära en beständig anslutning och, när den väl har upprättats, ladda ner data med en upprättad anslutning. Denna metod ger en betydande ökning av produktiviteten. dock Apache Som standard använder den en för lång timeout innan anslutningen stängs, lika med 15 sekunder. Detta innebär att efter allt innehåll har delgivits kunden som begärt Håll vid liv, kommer den underordnade processen att vänta i ytterligare 15 sekunder på inkommande förfrågningar. Det är dock lite mycket. Det är bättre att minska denna timeout till 2-3 sekunder.
KeepAliveTimeout 2
Minska timeout
Alternativt kan du minska värdet på direktivet Paus, som anger hur lång tid det tar att vänta på att enskilda förfrågningar ska slutföras. Som standard är dess värde 300 , kanske i ditt fall är det meningsfullt att minska/öka detta värde. Jag personligen lämnade det som det är för nu.
Minska avverkningsintensiteten
På vägen mot att öka serverns prestanda kan du prova att minska intensiteten i loggningen. Moduler som t.ex mod_rewrite, kan skriva felsökningsinformation till loggen, och om du inte behöver den, stäng av dess utdata.
Inaktiverar värdnamnsupplösning
Enligt min åsikt finns det inget behov av att omvända lösa IP-adresser till värdnamn. Om du verkligen behöver dem så mycket när du analyserar loggar, så kan du fastställa dem i analysstadiet, och inte medan servern är igång. Direktivet ansvarar för att lösa värdnamn VärdnamnSökningar, som faktiskt är installerat som standard i Av, men kontrollera detta om du verkligen tror att du behöver inaktivera konverteringen.
Värdnamnssökning av
Inaktiverar användning av .htaccess
Filbearbetning .htaccess genomförde Apache varje gång du begär data. Inte bara det Apache måste ladda ner den här filen, det tar fortfarande mycket tid och resurser att bearbeta den. Ta en titt på din webbserver och överväg behovet av filer .htaccess. Om du behöver olika inställningar för olika kataloger, kanske det vore realistiskt att lägga dem i huvudserverns konfigurationsfil? Och inaktivera bearbetning .htaccess möjligt genom direktiv i serverkonfigurationen.
|Apache är en mycket kraftfull webbserver. Att förenkla första installationen, erbjuder det ett stort antal pre installerade moduler. Detta gör Apache utmärkt för att distribuera nya projekt, vilket gör att du snabbt kan sätta upp en robust produktionsmiljö. Men när din webbplats (och därmed din trafik) växer kan du stöta på problem.
Den här guiden hjälper dig att förbättra Apache-prestandan på din virtuella server.
1: Inaktivera onödiga moduler
På Ubuntu och Debian-liknande system finns etc/apache2/mods-enabled och /etc/apache2/mods-available/ kataloger. Den senare lagrar en lista över alla moduler som är installerade på denna server. Och i den mods-aktiverade katalogen finns det moduler som ingår i det här ögonblicket.
Standardsituationen kan vara olika på varje server. Låt oss anta att servern har 17 moduler aktiverade som standard. Vanligtvis är detta för mycket för den genomsnittliga applikationen. Dessutom är det ganska svårt att omedelbart identifiera onödiga moduler som kan inaktiveras, eftersom enskilda moduler är beroende av andra.
Till att börja med rekommenderas det att spara en lista över moduler som är aktiva som standard, så att du i framtiden kan använda den för återställning standardparametrar. Du kan sedan helt enkelt inaktivera alla onödiga moduler en i taget, starta om Apache efter att du har inaktiverat varje modul för att säkerställa att inga fel uppstår i systemet.
På Ubuntu och Debian inaktiveras moduler med detta kommando:
sudo a2dismod autoindex
Enskilda moduler förbrukar mycket resurser; om du inte använder följande moduler, inaktivera dem bara:
- Skriva om
- Pytonorm
- Rack/Ruby/Passagerare
Alla dessa moduler är inte aktiverade som standard, men situationen är individuell för varje server.
Notera: Apache inkluderar vanligtvis omskrivningsmodulen som standard, även om den kan ersättas med aliasmodulen. Om alias passar din applikation, inaktivera omskrivning - detta är en av de tyngsta modulerna. För att ändra från omskrivning till alias, se moduldokumentationen. Även om du inte helt kan inaktivera omskrivning, kan du optimera individuella modulregler.
När du har inaktiverat modulen, starta om Apache och kontrollera sedan felloggen för att säkerställa att inaktiveringen av modulen inte skadade webbservern.
Du kan till exempel få ett felmeddelande som detta:
Syntaxfel på rad 6 i /etc/apache2/sites-enabled/site1:
Ogiltigt kommando "DAVLockDB", kanske felstavat eller definierat av en modul som inte ingår i serverkonfigurationen
Åtgärden "configtest" misslyckades.
Detta innebär att den inaktiverade modulen krävs för korrekt funktion webbserver. Sätt på den.
sudo a2enmod dav_fs
2: Flytta koden
PHP-sajter använder ofta den populära mod_php-modulen, och ruby-sajter använder ofta Passenger Phusion (mod_rails eller mod_rack-moduler).
Problemet är att C-koden för språktolken är kapslad i Apache, vilket kräver mer minne för att se varje sida. Om populär sida din webbplats tar emot 30 HTTP-förfrågningar, en av dem kommer att vara för dynamisk sida, och de återstående 29 är för statiska resurser (bilder, css och javascript). För att förbättra Apache-prestandan kan du eliminera 29 förfrågningar som inte visar dynamiskt innehåll.
Aktivering av mod_php-modulen kan resultera i en enda underordnad Apache-process som kräver 100 MB RAM. Ju fler Apache-processer som körs på servern, desto svårare blir det att bearbeta dem.
För att åtgärda det här problemet kan du använda följande verktyg:
- För PHP kan du installera php-fpm, som är en separat process baserad på fastcgi-protokollet.
- I Python använd uWSGI eller gnunicorn
- För Rails använd Unicorn.
Den startar först en process för PHP, Python eller Ruby och sedan omdirigerar Apache anrop till dynamiskt innehåll till den processen istället för att försöka hantera den med kapslad kod.
Efter att ha tagit bort mod_php-modulen kan storleken på Apache-processer ändras från 90-120 MB till bara 10 MB. Allt dynamiskt innehåll betjänas av bara två processer på backend.
3: Begränsa antalet Apache-processer
Många OS använd standardkonfigurationer som inte är särskilt lämpliga för små servrar - 25 underordnade processer. Om varje underordnad Apache-process kräver 120 MB RAM, kommer servern att spendera 3 GB på enbart Apache.
En användares webbläsare kan begära 4 webbplatselement åt gången, vilket innebär att endast 7-8 personer kan överbelasta servern. Webbsidor fryser eller laddas mycket långsamt.
Servern underhåller ofta sådana döda Apache-processer i aktivt tillstånd, försöker betjäna det begärda innehållet, och detta minskar antalet tillgängliga processer för användare och mängden minne. Resultatet är en dålig användarupplevelse.
Bestäm hur mycket RAM-minne din applikation kräver och hur mycket minne som finns kvar, allokera sedan det mesta av det återstående minnet till Apache.
Till exempel har du tre php-fpm-processer för att bearbeta dynamiskt innehåll, där varje process använder upp till 70 MB minne, och MySQL-server, som tar upp till 120 MB RAM. Resultatet är att applikationen använder 330 MB minne. Om du har en liten server kan du allokera cirka 150 MB minne för Apache.
När Apache webbserver körs, kör det översta kommandot. Den visar många användbar information. Nedan är ett utdrag av hennes resultat:
topp -bn 1
PID ANVÄNDARE PR NI VIRT RES SHR S %CPU %MEM TID+ KOMMAND
[...]
15015 www-data 20 0 232m 9644 1900 S 0,0 1,6 0:00,02 apache2
15016 www-data 20 0 232m 9644 1900 S 0,0 1,6 0:00,01 apache2
15017 www-data 20 0 232m 9644 1900 S 0,0 1,6 0:00,02 apache2
Hitta värdet i RES-kolumnen för Apache (till exempel 9644) och skriv ner det. För närvarande använder webbservern nästan 10 MB minne. Om du begränsar antalet underordnade Apache-processer till 15 räcker det med 150 MB tilldelat minne.
Redigera Apache-konfigurationsfilen (på Ubuntu och Debian är detta /etc/apache2/apache2.confand) och hitta avsnittet mpm_prefork_module. Hitta MaxClients-raden och ange 15, spara sedan filen och starta om webbservern.
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxClients 30
MaxRequestsPerChild 0
Som standard kan MaxClients-värdet vara mycket stort. Det måste minskas.
När antalet klienter når gränsen kommer nya klienter att få ett felmeddelande. Genom att ladda om sidan kommer de att kunna komma åt sidan.
Detta låter dåligt, men det är ändå bättre att snabbt stänga dessa anslutningar och spara normalt arbete server än att vänta tills servern slutar hänga.
I vissa situationer kan färre underordnade processer bidra till att förbättra serverns prestanda.
Används ofta i Apache-konfigurationer förinställning prefork mpm, som anses vara säker och lämplig för PHP och andra språk.
Om du blir av med externa moduler(PHP eller Rails), kan du överväga arbetar-MPM som ett alternativ.
För att aktivera denna modul, skriv in:
sudo apt-get installera apache2-mpm-worker
Följande paket kommer att tas bort:
apache2-mpm-prefork libapache2-mod-php5
Följande NYA paket kommer att installeras:
apache2-mpm-arbetare
0 uppgraderad, 1 nyinstallerad, 2 att ta bort och 2 inte uppgraderad.
Behöver skaffa 2 284 B arkiv.
Efter denna operation kommer 8 718 kB diskutrymme att frigöras.
Vill du fortsätta?
Uppmärksamhet! På Ubuntu tar installation av arbetsmodulen bort prefork mpm, mod_php och andra inkompatibla moduler.
Taggar:Om du bestämmer dig för att öka Apaches prestanda (och idag är det en av de mest populära webbservrarna på Internet), kommer tipsen som vi kommer att ge i den här artikeln att vara användbara för dig.
1. Arbeta bara med de moduler du verkligen behöver, och ta bort allt annat direkt och utan att tveka! Faktum är att i det här fallet kommer du omedelbart att minska minnesförbrukningen, vilket kommer att medföra en ökning av hastigheten. Det andra alternativet är att kompilera modulerna som DSO, med hjälp av apxs (i apache 1) och apxs 2 in (apache 2), vilket minskar hastigheten med cirka 11-15%.
2. Välj rätt MPM (Multi-processing module). Därför att huvuduppgiften MPM - lyssna på portar som uppfyller de fastställda kraven för säkerhet, mängden ledigt minne eller närvaron av trådstöd i OS, då bör du begränsa valet till två MPM - worker och prefork.
Arbetare – överför serviceförfrågningar till en separat tråd.
Perfork - du arbetar med flera underordnade processer, som var och en ansvarar för att bearbeta en anslutning.
För att ändra MPM måste du kompilera om apache med källbaserat, vilket omedelbart kommer att förbättra hastigheten på hela systemet.
3. DNS-inställningar förfrågningar. Aktivera först direktivet "HostnameLookups". För det andra, se till att Allow from och Deny From-direktiven använder IP-adresser snarare än domännamn för att rädda Apache från att behöva göra dubbla förfrågningar för att kontrollera giltigheten av klientdata.
4. Ställ in AllowOverride-direktivet på "None"-läge, annars kommer apache att öppna (eller försöka göra det) alla htaccess-filer i varje besökt katalog, såväl som filer ovanför den:
Därför, om du behöver .htaccess för endast en katalog, gör du så här:
Du bör också notera att när den är aktiverad för en katalog:
FollowSymLinks - servern kommer alltid att följa symboliska länkar i denna katalog;
SymLinksIfOwnerMatch – servern spårar länkar endast om ägaren till katalogen matchar ägaren till katalogen som länken pekar till.
5. Avvisa också innehållsförhandling.
6. Ställ in MaxClients-parametrarna korrekt, som bestämmer antalet samtidigt behandlade förfrågningar. Hitta det själv optimalt värde MaxClients för att betjäna det optimala antalet kunder. Man bör komma ihåg att statiska Apache-filer kräver 2-3 MB per process, för dynamiska - 16-32 MB.
7. Installation av MinSpareServers, MaxSpareServers och StartServers - och detta borde leda till att apache vägrar skapa 4 trådar/processer per sekund, vilket gör att den inte överbelastas systemet även med det maximala antalet klienter.
8. Ändra MaxRequestsPerChild-värdet när du bestämmer hur många förfrågningar 1 underordnad tråd/process måste behandla innan den avslutas. Kom ihåg att detta värde (som standard) är inställt på noll, så det är bättre att ändra det till 1000 eller mer, vilket kommer att spara dig från att läcka minne till underordnade processer, vilket är av stor betydelse när du använder en instabil version av PHP.
9. Aktivera KeepAlive och KeepAliveTimeout, som, när de är inaktiverade, skapar en separat tråd för varje bild som placeras på en HTML-sida, och "snar ner" sidor med ett stort antal bilder stor storlek. I fall med nedladdningsservrar är det bättre att inaktivera KeepAlive, vilket omedelbart kommer att rädda dig från att vänta länge innan servern stänger anslutningar.
10. Använd komprimering, vilket gör att du kan minska mängden överförd trafik med 75 procent. Och gör detta utan rädsla, eftersom idag alla de senaste klientprogrammen och servrarna stöder HTTP-komprimering i HTTP/1.1-standarden. Och ansträngningar bör göras för att komprimera video, musik och alla jpg, gif png-filer.
Det bör noteras att cachningsparametrar ställs in av direktiv från mod_deflate-modulen. Du bör dock inte ställa in gzip-komprimeringsnivån till mer än 4 eller 5, eftersom detta kommer att öka CPU-tiden och minska den totala effekten.
11. Och glöm naturligtvis inte att installera Expires-rubriker på statiska filer (modulen mod_expires används för detta). Eller cache det på klienten om filen inte ändras, vilket kommer att befria servern från onödiga förfrågningar, och klienten kommer att få en snabbare laddningssida.
Apache-prestandaproblem dyker ofta upp på nya VPS. Faktum är att konfigurationsfiler som skapas efter Apache-installationer långt ifrån optimerad.
Symtom dåliga inställningar det kan finnas en VPS som körs med RAM-frosseri på 100 % eller CPU på 100 %. Efter att ha kört top- eller htop-kommandot (om det inte fungerar, kör apt-get install htop) de första raderna kommer att innehålla apache-processen.
Jag ska visa dig den optimala konfigurationen. fil för VPS
Bagge: 512 MB
Processor: 2267 MHz
OS: Debian 5
# # Timeout: Antalet sekunder före mottagning och sändning timeout. # Timeout 300 # # KeepAlive: Huruvida beständiga anslutningar ska tillåtas eller inte (mer än # en begäran per anslutning). Ställ in på "Av" för att avaktivera. # KeepAlive On # # MaxKeepAliveRequests: Det maximala antalet förfrågningar för att tillåta # under en ihållande anslutning. Ställ in på 0 för att tillåta ett obegränsat antal. # Vi rekommenderar att du lämnar denna siffra högt för maximal prestanda. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Antal sekunder att vänta på nästa begäran från samma klient på samma anslutning. # KeepAliveTimeout 15 ## ## Server-Pool Size Regulation (MPM-specifik) ## # prefork MPM # StartServers: antal serverprocesser att starta # MinSpareServers: minsta antal serverprocesser som hålls lediga # MaxSpareServers: maximalt antal serverprocesser som hålls lediga # MaxClients: maximalt antal serverprocesser som får starta # MaxRequestsPerChild: maximalt antal förfrågningar en serverprocess betjänar
I den här inställningsfilen kan du ändra följande parametrar:
- MaxClients– begränsning av det maximala antalet
- StartServer-ställer in antalet underordnade processer när servern startar.
- MinSpareServers– det minsta antalet oanvända underordnade processer.
- MaxSpareServers- Följaktligen det maximala antalet oanvända underordnade processer.
- MaxRequestsPerChild– det maximala antalet förfrågningar som en underordnad process tillåts behandla innan den flödar över. Behövs denna parameter för att undvika läckage av minne eller andra Apache-resurser, eftersom om den underordnade processen svämmar över så kommer den att göra det
samtidigt köra processer httpd. de där. sätter i princip en gräns
för minnesförbrukning genom den "hungrigaste" httpd-processen
tvångsfullbordad. I de flesta fall krävs ingen förändring. Värde 0 betyder inga begränsningar.