På forsiden av Digg.com - hva nå?

Sidene våres var litt treige i går kveld på grunn av denne artikkelen hos Mac1.no. Følgende er noen linjer om hvordan man på kort varsel kan mangedoble kapasiteten til en server og hva man må passe på.

Kort fortalt har en rekke nettsider med Mac-relatert materiale påstått at de har blitt hacket og på den måten fått mye oppmerksomhet. Men, uten å blande meg opp i detaljene og troverdigheten til kilden, mye tyder på at de har sabotert seg selv for å få oppmerksomhet. Artikkelen fikk etterhvert godt fotfeste på Digg.com og havnet etterhvert på forsiden (2. plass).

Sidene våres har til sammen over 140 000 sidevisninger per dag (inklusive søkemotorer), så vi er relativt godt utstyrt til å håndtere trafikk. Digg.com forsiden var likevel litt skremmende, spesielt etter at vi nylig gikk over til ny programvare stack, oppgraderte Apache og satte nytt banner-system i drift for to dager siden.

Gode løsninger
Det finnes mange gode løsninger for å håndtere store mengder med anonyme brukere. Klassikeren er Squid, som eksempelvis Wikipedia bruker hundre(vis?) av. Disse kan håndtere ca. 20 ganger flere brukere enn Apache. Det finnes også nyere utfordrere, spesielt norsk-danske Varnish Cache som utvikles av Linpro og brukes av Aftenposten og VG. Dessverre er koden til sistnevnte svært lite dokumentert og stemningen på epostlisten kunne vært bedre, så det gjenstår å se om prosjektet kan utvikle seg videre uten direkte finansiering. Men teknisk sett er det er en svært god løsning som håndterer langt mer trafikk enn Squid eller Apache.

Hacken
Dessverre krever eksterne cacher at man enten bruker IPTables for å omdirigere trafikken fra port 80 til cachen, eller at man endrer portene som Apache bruker. I utgangspunktet er dette enkle endringer, men likevel ikke noe man har lyst til å begynne på mens man er minutter unna forsiden på Digg og når neste planlagte besøk til serverrommet er to måneder unna. Det er heller ikke trivielt å sette opp disse løsningene til å skjønne forskjellen på brukere som er logget inn og de som ikke er det.

En enkel hack er derfor å sette opp et script som lagrer en statisk versjon av den aktuelle siden. Det vil si at Apache fortsatt må sende ut teksten som utgjør siden, alle bildene og stylesheets, men man slipper å kjøre script og databaseoppslag. I mange tilfeller vil dette være nok til å mangedoble kapasiteten.

Jeg la derfor bare inn et cron-script som hvert minutt lagde en statisk versjon av siden som anonyme brukere ser:
wget -q http://mac1.no/node/5885/ -O mac-hacking-er-pr-stunt

Dette opprettet en statisk fil som, takket være Drupals standard mod_rewrite regler, blir foretrukket fremfor den dynamiske. Samme triks (sjekk om filen/directoryet eksisterer, hvis ikke la index.php ta seg av forespørselen) kan gjøres i nær sagt alle CMSer. I verstefall, dersom URLene går til en sentral fil ( http://mac1.no/index.php?q=node/5885 ) må man kombinere dette med et mod_rewrite triks. Målet er å fange opp forespørselen for den aktuelle siden og videresende til den statiske HTML filen:
RewriteCond ${QUERY_STRING} ^q=node/5885$ [NC]
RewriteRule $index.php^ statisk_5885.html [L]

En annen viktig ting er å redusere hvor ofte serveren må skrive til disken. Det aller viktigste i denne sammenheng er noatime i /etc/fstab, men også logging. Du leste riktig, en sidevisning genererer opp til 40 forespørsler (CSS, bilder, JavaScript) og dermed 40 linjer i loggen. Gode RAID kontrollere med masse cache reduserer problemet, men det er likevel en belastning man bør vurdere å droppe når det blåser opp til storm. Vi bruker primært Google Analytics for å holde tellinga, så det å slå av access-loggen var ikke noe stort tap og Drupal logger automatisk 403 og 404.

Tabben
Hovedmotivasjonen for å skrive dette innlegget er en tabbe jeg har gjort flere ganger, og forhåpentligvis nå slutter å gjøre. Den heter mod_auth_digest. Denne modulen bruker kryptering for å sikre utveksling av informasjon om brukernavn og passord. Problemet er at for å gjøre dette på en uforutsigbar måte trenger den tilfeldige data (entropi) under oppstart. Dette høres ikke så ille ut, men det er vanlig å få Apache til å starte på nytt etter å ha besvart noen tusen forespørsler, noe som ikke skjer før modulen har nok entropi tilgjengelig. Clrngd reduserer problemet, men tydeligvis ikke nok til at Digg folkene ikke forstyrrer. Uansett, løsningen er enkel: Pass på at alle konfigurasjonsfiler med "mod_auth_digest" er kommentert ut og restart Apache.

Justeringer
Det siste man må jobbe litt med er hvor mange Apache prosesser som kjører og hvor mange forespørsler de besvarer før de gir seg. Gode verdier er avhengige av mange ting, ikke minst hvor kompliserte forespørslene er og hvilken MPM modul man bruker. Teoretisk sett burde MPM-worker være den mest effektive, men på vårt oppsett har mpm-prefork og mpm-itk gitt lavere belastning på systemet. Et generelt tips, når du primært sender ut statiske sider, er å begrense seg til 150 forbindelser per prosess og ha minst 50 prosesser tilgjengelige. Med dynamisk innhold trenger man langt mindre, da flaskehalsen sjelden er hvor fort klientene kan ta i mot.