Att idag ha en webbserver som bara lyssnar på IPv6 är rent ut sagt korkat, för alldeles för få människor surfar i Ipv6 rymden. Dock så tycker jag att det är var mans skyldighet att stöjda IPv6 i sina tjänster, så därför bör din server lyssna både på IPv4 och IPv6.
För att uppnå detta i Apache2 så måste man skriva två olika Vhostar, en för IPv4 och en för IPv6, där den enda skillnaden är vilken adress vhosten lyssnar/binder på. Glöm inte att infoga IPv6 adressen i brackets.
Exempel:
<VirtualHost [2a02:750:5::5b2]>
ServerAdmin webmaster@example.com
ServerName www.example.com
ServerAlias example.com
Jag har 2 teorier som jag just nu håller på att testa, de rör hur man borde bygga sitt webbkluster för att få maximal upptid och så liten påverkan som möjligt vid bortfall av en server.
Lösningarna ser i princip identiska ut, men skillnaden ligger i om PHP-hanteras av Apache2-modulen för PHP eller om man hanterar PHP via FastCGI. De bygger båda på öppenkällkod och är helt redundanta. I båda ingår också ett MySQL/MariaDB kluster men det finns inte detaljerat då det inte är mitt primära mål just nu.
Lösning 1, Lastbalanserare och X antal apache2maskiner.
I den schematiska bilden ovan är det 2 olika kluster som delar på samma databaskluster, i schemat är inte lastbalanserarna redundanta men det ska de vara. Om en webbserver faller bort i klustret kommer 50% av beräkningskraften att försvinna och vid ev. peak så kommer troligen ett stort antal av besökarna att lämna siten då den går väldigt långsamt, självklart förutsatt att besökarantalet är större än vad en enskild maskin klarar vid bortfallet. I övrigt så finns alla andra fördelar som ett kluster innebär, möjligheten till att ta ner en maskin för underhåll utan att driften av siten påverkas etc. Beräkningskapaciteten i det kluster som fortfarande har båda sina maskiner i drift påverkas inte.
Lösning 2, Lastbalanserare, X antal apache2maskiner och ett FastCGI kluster.
Fördelen med den här lösningen är att, förutsatt att det är likadan hårdvara som i Lösning 1, den presterar bättre på samma antal maskiner. Detta då alla krävande PHP-beräkningar skickas till ett eget kluster. Det innebär att bortfallet av en webbserver i något av klustret inte kommer att påverka prestandan lika mycket. Planerar man och dimensionerar FastCGI klustret rätt och låter två siter som har olika peakar och tider av hög belastning dela FastCGI kluster så kan de dela på samma kluster. Då kan vi överdimensionera klustret något utan att det har kapacitet som står oanvänd ofta.
Det tredje alternativet jag har är att ha ett enda superstort apache2kluster och låta det göra allt. Det kommer krävas väldigt många fler maskiner för det, och maskiner är som bekant en kostnad. Som komplement till både lösning 1 och 2 kan man dessutom ha en funktion som skapar maskiner on-demand i molnet, då behöver man bara ha igång de maskinerna vid peakar och högtrafik.
Google, som försett internet med grymma tjänster som Gmail och adsense och det fenomenala verktyget Pagespeed. Som ett komplement till sistnämnda har det nu även släppts en modul för Apache2(2.2 och senare) som ska underlätta för administratören att få bra krut i siten. Personligen kan jag tycka att det är ännu ett bevis på att en snabb site bäst uppnås genom att optimera både kod och plattformen som siten körs på.
Än så länge så kan inte mod_pagespeed kontrolleras från en .htaccess-fil, men enligt det här länken så verkar det vara på gång vilket skulle vara ett stort steg i rätt riktning mot att göra användarupplevelsen på internet ännu bättre! Men som jag sa så måste det till mer än bara en servermodul för att det ska bli bättre, alla måste ta tag i sina siter också.
För att installera modulen så måste du manuellt installera en .deb fil med dpkg -i, men bra instruktioner finns på http://code.google.com/p/modpagespeed/
Behöver du hjälp med att konfigurera mod_pagespeed på din server så kan jag hjälpa dig!
Jag ska under natten och morgondagen företa mig att göra benchmarktester av Nginx, Apache2 och Cherokee. De två första är jag väldigt bekant med, men Cherokee bli en ny bekantskap för mig. Cherokee ska jag också passa på att presentera lite mer utförligt och se hur det fungerar med PHP, så det blir en benchmark av WordPress och PHP också, precis om i den här posten: http://www.abergman.se/w3-total-cache-och-nginx/
Precis som förra gången så kommer jag att publicera resultatet dels här och på www.cmsdirekt.se, stay tuned!
Inom kort kommer www.cmsdirekt.se att publicera en jämförelse mellan apache2 och Nginx prestanda på en wordpress installation, dock så kan jag redan nu(eftersom det var jag som gjorde testerna) avslöja att skillanden i prestanda på siten med och utan W3 total cache är några 100%, sedan följer siege resultat från Nginx.
Med W3 total cache:
Transactions: 1888 hits
Availability: 100 %
Elapsed time: 60.24 secs
Data transferred: 8.30 MB
Response time: 0.84 secs
Transaction rate: 31.31 trans/sec
Throughput: 0.14 MB/sec
Concurrency: 26.22
Successful transactions: 1888
Failed transactions: 0
Longest transaction: 29.90
Shortest transaction: 0.05
Utan W3 total cache
Transactions: 90 hits
Availability: 100.00 %
Elapsed time: 60.10 secs
Data transferred: 0.39 MB
Response time: 16.57 secs
Transaction rate: 1.50 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 24.81
Successful transactions: 90
Failed transactions: 0
Longest transaction: 21.02
Shortest transaction: 15.08
Som tydligt framgår så är det en enorm skillnad! Mer detaljer kommer dock i artikeln på www.cmsdirekt.se. Se det här som en liten preview:)
Senaste kommentarerna