Hej,

En av sidorna jag har hand om har växt snabbt senaste tiden och det verkar inte som att servern hänger med. Sidan har över 1300 unika besökare per dag och över 1 miljon sidvisningar per månad och dessa siffror växer snabbt.

Nu får vi hela tiden 502 Bad Gateway, 504 Gateway timeout, felmeddelanden om att sidan inte kan ansluta till databasen och det är allmänt segt på sidan.

Systemet är uppställt på följande sätt: nginx sköter om det statiska materialet (bilder, .css, .html osv) och apache sköter om det dynamiska (i stortsätt .php). Som databas använder vi MySQL. Allt detta ligger på en server som har en dual core-processor och 1 GB ram. Servern ligger på 30 Mbits lina.

Jag har diskuterat problemet med andra och min plan för att åtgärda dessa problem ser ut på följande sätt:

* Öka ram-minnet till 4 GB.
* Byta webbservermjukvara till Lighttpd
* php i fastcgi-läge

Tänkte kontrollera om folket på detta forum har några kommentarer på detta?

När det gäller databasen bör du kolla vad det är som är jobbigt. Är det queries som saknar index och därför är galet långsamma och låser upp saker?

Ja, något är inte optimerat som det ska, 1300 unika/dag ska den klara, även om 1GB ram är lite snålt. Jag körde 5000 unika/dag på en gammal 3.0 ghz CPU, 2GB ram, vanlig Apache och mySQL, sidan hade diskussionsforum, webshop, bilduppladdning, 20 Mbits lina.

Det är ju i och för sig > 30k sidvisningar per dag, lite mer än vanligt för 1300 unika. Men kolla som sagt databasen, t.ex. mysql slow queries, och kolla om du inte kan cacha hela eller delar av ditt dynamiska innehåll. Din server borde palla klart större belastning än den nuvarande med rätt optimering. Vill du ändå utöka är ju mer minne alltid bra, beroende på hur din databas ser ut skulle du kanske kunna köra databasen på en ramdisk? Det är då om inte mysqls query cache håller allt du behöver. Memcached är ett annat alternativ. Hur du väljer att optimera sidan beror ju helt på hur den ser ut och var flaskhalsarna ligger, det är svårt att svara på exakt vad du bör göra utan mer insyn i din miljö

Ja, optimiseringar av querisen och effektivare cachening av material ska jag definitivt titta på och ni får gärna tipsa om fler sätt man kan optimisera databasen på.

Sen måste jag fråga om 502 och 504-felmeddelanden som genererar av nginx. Har inte lyckas ta reda på vad dessa exakt beror på men tror att det är kommunikationen mellan nginx och php som misslyckas av överbelastning. Så frågan är om det är effektivt att ha två stycken servrar på det här sättet? Jag vill som sagt gå över till lighttpd eftersom att denna uppställning inte känns effektiv.

Jag är säker på att det inte är Apache som är flaskhalsen i ditt fall, som du själv skriver så ligger problemet troligtvis i kommunikationen mellan nginx och php och/eller i queries som är ooptimerade. Jag skulle testa utan nginx.

Haha, nu har jag fått rådet att byta ut både apache och nginx, ta bort bara apache, och nu, ta bort bara nginx.

Tror det jag måste göra är att över huvud taget byta ut nåt för kombinationen apache - nginx verkar inte funka i mitt fall.

nginx är en server som bara funnits i 3 år och är fortfarande i Beta stadiet, medans Apache är en väl beprövad server som funnits i över 13 år. Bara rent logiskt så skulle jag först prova att ta bort nginx, just my two cents...

Tänk hur det lätt det vore om man faktiskt kunde använda den logiken att programvara A har utvecklats längre än programvaa B och såldes måste programvara A vara bättre än programvara B. Man kan inte utgå från hur länge en mjukvara har utvecklats för att bedöma vilket som är bättre. Med den logiken är alla mjukvaror oavsett hur de faktiskt fungerar, hur stabila de faktiskt är och vilka resurser de faktiskt drar alltid bättre än sina motsvarigheter som är i beta. Och verkligheten ser inte hur så.

Problemet med apache jämfört med nginx är att apache har massa krimskrams som gör apache tungt och drar väldigt mycket resurser. Ordet "beta" säger ingenting om denna skillnad.

Apache 2 är moduluppbyggt. Plocka bort dom moduler som du inte använder och vipps, så blir Apache snabbare. Det är ett fel som många gör.

Du sa att allt kör på samma burk. Se till att kommunikation med mysql sker över en unix socket så tjänar du 20% prestanda.

Generellt sett är program som lämnat beta stadiet mer stabila, det är ett faktum.
Det stämmer naturligtvis inte på alla programvaror, men oftast.

Några frågor...

Bad gateway... Det visar ju på att det kan vara något framför apache och nginx som strular. Har du nån form av proxy eller liknande framför?
Uppstår problemet både för statiskt material och dynamiskt?
Om det gäller dynamiskt material, kolla apaches config så inte ServerLimit går i taket, prova höja den.
Om antalet samtidiga anslutningar till mysql inte räcker till så öka max_connections i my.cnf
Lägg till skip-name-resolve i my.cnf om du inte redan har det.
Lägg till skip-bdb om du inte använder BerkeleyDB, och skip-innodb om du inte använder innodb... i my.cnf alltså.

Ang att saker och ting går trögt så kolla följande
Se till att alla dina queries använder index. Detta är sannolikt den största boven i dramat. Kolla mysql-manualen på "EXPLAIN".
Se till att använda mysqls socket istället för tcp-anslutning. Detta görs automatiskt om du använder "localhost" vid anslutning och sökvägen till socketen är rätt i my.cnf. Minskar anslutningstiden drastiskt.
Använd mysql_pconnect istället för mysql_connect. Då görs en persistent connection vilket betyder att man använder en anslutningspool och kan återanvända redan öppna anslutningar för att inte slösa onödig tid på att öppna anslutningar hela tiden.
Släng i mer RAM i burken, 1GB RAM är äckligt lite även om du bara hade kört mysql på burken. RAM behövs för att cacha queries, minimera användandet av tillfälliga tabeller, resultatsortering på disk osv.
Jag har själv aldrig testat nginx men använder mig av thttpd (www.acme.com/software/thttpd). Hur den står sig mot nginx vet jag inte men är stabil och bra.

Har du inte fått till det med allt detta så blir det till att skaffa en burk till och slänga över mysql på den :)

Mina 10 cent sätter jag också på att slänga ut nginx.
Och om du inte använder en hel hög med massa mod_rewrites så kasta ut apache2 med.

mod_fastcgi i lighttpd (lighty) är riktigt riktigt snabbt.
Youtube kör blandannat denna lösning.

En akademisk fråga för oss utan erfarenhet av ritkigt hög belastning:

Varför skall man slänga ut nginx och apache2 för att gå över till lighttpd?
Går det inte lika bra att bara köra lighttpd för php och webbservern och ändå använda nginx som loadbalancer?
Men jag måste erkänna att jag inte alls någon epxert på hög belastning men om wordpress.com använder sig av nginxs laddbalansering så måste ju programmet klara av en miljon sidvisningar i månaden?!
http://barry.wordpress.com/2008/04/2...lancer-update/

Sen håller jag med om att mysql säkert är flaskhalsen. Det ligger inte någon galen query som körs för ofta utan index bakom?

Det antal besökare du nämner är ingenting som inte vilken server som helst (ja, även den du har, kanske med lite mer minne) borde kunna hantera.

Detta oavsett vilken av de olika webbservrarna du använder...

Har du optimerat koden och databasen?

Man börjar alltid där innan man slänger i mer hårdvara.

Anledningen är att du slipper ha 2st servrar som hanterar ditt innehåll utan bara har en som både serverar samt agerar loadbalancer, vilket i sin tur reducerar minnesanvändningen, antal processer som körs samt disk IO. Lighty är känt att vara väldigt snabbt på både statiskt och dynamiskt innehåll och har ypperligt stöd för loadbalancering.
Själv har jag en sajt med ca. 5000 unika besökare per dag och över 100k sidvisningar som servas av lighty. CPU:n går knappt aldrig över 5% och har aldrig haft några som helst problem med att servern kraschar eller sidorna inte renderas.