[Weaver]

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.

[SimonP]

Originally posted by opik@Jul 6 2008, 14:10
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.

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.

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.

[mbomelin]

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

[Jine]

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.

[mkblogg]

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?

[Xamda]

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...

[Frej]

Har du optimerat koden och databasen?

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

[jayzee]

Originally posted by mkblogg@Jul 29 2008, 19:37
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/

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.