Andreas Bergman

Använder du nginx inbyggda cache för att minska loaden på din server? Då är det här en plugin för dig, http://wordpress.org/extend/plugins/nginx-manager/

Den purgear automatiskt relevanta delar av Nginx cache när du postar ett nytt inlägg i din wordpress.

I en tidigare post(http://www.abergman.se/hall-koll-pa-din-nginx-servers-status/) skrev jag om en modul för att hålla koll på Nginx status.

Alla som vet något om sälj, vet att säljare och chefer älskar statistik, dessutom så är det ganska smidigt för att se trender över tid, så man kan motivera att köpa in en ny server.

För att göra det så har en smart snubbe(http://kovyrin.net/2006/04/29/monitoring-nginx-with-rrdtool/) skrivit ett litet RRD script för att skapa grafer.

Ladda ner scriptet: http://kovyrin.net/files/mrtg/rrd_nginx.pl.txt

Innan du provar köra det, installera de här paketen om du inte redan har dem:

librrds-perl
libwww-perl

Anpassa inställningarna i scriptet så de passar dig, så bilderna landar där du vill ha dem etc. Sedan lägger du in en rad i cron för att köra scriptet en gång i minuten.

* *     * * *   root    /some/path/rrd_nginx.pl

Jag använde crontab -e, så jag uteslöt “root” ur min fil.

Om allt funkar kommer scriptet nu att spotta ur sin finfina grafer, som du tex kan infoga på en HTMLsida för att kunna kika på dem via webbläsaren, eller så kan du använda dem i nästa rapport där du ber om en ny server.

Vill du veta hur många anslutningar som din nginxserver har aktiva just nu? Eller hur många anslutningar den har tagot emot totalt? Eller vill du skapa en asfet graf i ditt övervakningssystem på hur mycket last Nginx tar?

Oavsett så löser du det såhär:

location /nginx_status { 
  stub_status on;
  access_log   off;
  allow EN.IP.ADRESS;
  deny all;
}

Det ska skrivas i en site-config och inte direkt i nginx.conf. Om du inte riktigt bryr dig om vem som tittar på dina stats, eller om du kanske rent utav vill visa upp dem så kan du ju alltid sätta “allow all” och ta bort “deny all”.

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!

Jag kom idag på en sak som jag förbisett tidigare, nämligen debug-flaggans potential att skapa gigantiska loggfiler, debugflaggan kan man slå på för errorloggarna och då får man fram massor av fantastisk information, tex vilka regler i vhosten som slår på aktuell request eller vilka fel som php-genererar. Dock så blir det ganska stora filer, så det rekomenderas att antingen hålla ordentlig koll på filerna, eller slå av flaggan om du inte jobbar med att debugga siten.

Då jag har så många siter igång och inte orkar ändra alla vhostar så valde jag att skriva om reglerna för logrotate samt sätta maxfile size kontroller på filerna, eftersom en bra errorlog är en tom errorlog:) så nu får jag ett larm om någon fil överstiger 1Mb.

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:)

I mitt lilla projekt om att sätta upp ett eget CDN, Content Delivery Network så har jag nu konfigurerat om Nginx samt installerat Varnish. Det funkar så att Varnish ligger som gateway på port 80 och går igenom alla inkommande requests, om någon request matchar konfigurationen i Varnish så hanterar den det enligt gällande regler. För att uppnå det måste Nginx konfigureras om för att lyssna på en annan port, jag valde för enkelhetens skull port 8080.

 Om du inte redan har installerat Nginx, så finns en guide här

Konfiguration av Nginx, ändra nedan i alla dina vhostar:

Listen 8080

Det gör att Nginx kommer att lyssna på port 8080 istället för 80, det är viktigt att ställa om det på alla vhostar, annars kommer nginx eller varnish inte starta om ordentligt. vill du kan du även skriva 127.0.0.1:8080 så kommer Nginx att bara lyssna på requests som kommer internt på maskinen och inte externt, jag väljer att inte skriva det då jag vill kunna komma åt webbservern direkt externt också, i testsyften.

Installation av Varnish

Varnish finns i Debian stabels paketförråd och installeras med:

apt-get install varnish

Sedan så är det mer eller mindre klart, varnish startas med /etc/init.d/varnish och loggdemonen med /etc/varnishlog start, med största sannolikhet är de redan startade. 

Nu börjar det roliga, men samtidigt besvärliga, vad är det jag vill cacha? Jag har ett enkelt exempel där jag bara cachar statiska filer på en viss domän:

backend default {
        set backend.host = “127.0.0.1″;
        set backend.port = “8080″;
}

sub vcl_recv {
           if (req.http.host ~ “http://cdn.sngw.se“) {
             pass;
           } else {
             if (req.request != “GET” && req.request != “HEAD”) {
                 pipe;
             }
             if (req.request == “POST”) {
                 pass;
             }
             if (req.request == “GET” && req.url ~ “\.(jpg|jpeg|gif|ico|png)$”) {
                 lookup;
             }
             if (req.request == “GET” && req.url ~ “\.(css|js)$”) {

 lookup;
             }

             if (req.request == “GET”) {
                 lookup;
             }
             lookup;
          }
        }
         sub vcl_pipe {
             pipe;
         }

         sub vcl_pass {
             pass;
         }

         sub vcl_hit {
             if (!obj.cacheable) {
                 pass;
             }
             if (req.http.Cookie) {
                pass;
             }
             deliver;
         }

         sub vcl_miss {

fetch;
         }

         sub vcl_fetch {
             if (!obj.valid) {
                 error;
             }
             if (!obj.cacheable) {
                 pass;
             }
             insert;
         }

         sub vcl_deliver {
             deliver;
         }

         sub vcl_timeout {
             discard;
         }

         sub vcl_discard {

     discard;

         }

De här reglerna  cache:ar bara statiska filer och gör ingenting konstigt med dem. Nu är du redo att fortsätta upptäcka mer fantastiska grejer med Varnish ocg nginx, lycka till!

När man optimerar sidor jobbar man i många fall med att separera statiskt innehåll som bilder, javscript och css från dynamiska filer som .php. Eftersom de olika filtyperna har olika sätt att hanteras och olika uppdaterings/åldrigstid så väljer man ofta att leverera de olika filtyperna med olika webbservrar med olika cacheinställningar.

I många fall är det helt värdelöst att ha en dubbel uppsättning webbservrar att hålla koll på utan man väljer att lägga sina statiskafiler hos någon som kan leverera dem åt dig, ett så kallt Content Delivery Network(CDN).  Exempel på sådana är Amazon S3 och även flickr.

Ibland vill man själv ha koll på sitt innehåll och då kan det vara en idé att bygga ett eget CDN, hur man uppnår det på bästa sätt kan diskuteras men det alldra enklaste är helt enkelt att lägga dina filer på en annan server och länka in dem i dina dynamiska sidor.  För att sedan få lite kräm och hastighet på filerna bör du välja en webbserver som ärbra på statiska filer, tex nginx. Vill spara ännu mer kraft kan man även lägga en cache framför, som Varnish.

De stora CMS:erna WordPress och Drupal stöjder båda distribution av filerna till ett CDN, med häjlp av W3 Total Cache-modulen till WordPress kan du även lägga alla dina nyuppladdade filer på CDN:et mha FTP, helt sömlöst utan att dina användare och besökare märker det.

Inomkort kommer det en praktisk guide här på www.abergman.se på hur man bygger ett eget CDN, eller ett PCDN, Private CDN.

I många fall är det behagligt att kunna administrera sina databaser visuellt, ett kanonbra verktyg för det är phpmyadmin, det är dessutom gratis och opensource, vilket gör det hela ännu roligare.

När du installerar phpmyadmin via en pakethanterare, tex APT, så kommer den i många fall ge dig valet att välja vilken webbserver du vill konfigurera phpmyadmin för, än så länge finns inte valet Nginx, men det betyder inte att det inte går att köra phpmyadmin på Nginx. Jag valde att ladda ner phpmyadmin själv och inte använda den version som kommer med när man drar ner den via apt, detta av ren och skär lättja.

Börja med att ladda hem PhpMyAdmin från: http://www.phpmyadmin.net/home_page/downloads.php packa upp grejerna i en passande mapp, jag valde /usr/share men du kan lika gärna använda /var/www, kom ihåg vart du lägger filerna bara då du måste anpassa konfigurationen därefter.

När du packat upp filerna så är det bara att fixa konfigurationen för Nginx, min ser ut som nedan.

server {
        listen   80;
        server_name  host.se;
      access_log  /var/log/nginx/phpmyadmin.access.log;
        error_log   /var/log/nginx/phpmyadmin.error.log debug;

            location / {
                root  /usr/share/phpmyadmin/;
                index  index.php;
               
             }
          location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /usr/share/phpmyadmin$fastcgi_script_name;
                include fastcgi_params;
            }
            location ~ /\.ht {
               deny  all;
            }  

}

Det är alles, lycka till!

I sitt blogginlägg på CmsDirekt skriver David V. Wallin lite kort om hur man får ramverket CodeIgniter att lira på Nginx: Det är egentligen bara en rewriteregel och en liten förändring på hur man skickar sidor till php-fpm. Såhär ser  konfigurationen ut som du kompletterar din vhost med:

location /{

if (!-f $request_filename) {
rewrite ^(.*) /index.php?$1 last;
}

}

location ~ \.php$ {
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param  SCRIPT_FILENAME  /var/www/example.org/index.php;
}

Notera att efter SCRIPT_FILENAME så skickar vi inte med variablen $FASTCGI som vi gör när vi konfigurerar för vanligt php, utan vi skickar explicit med index.php eller vilken sida man nu har som förstasida.