Webperf
Felmeddelanden i 500-serien brukar ofta utvecklaren vara skyldig till, eller så är det en teknisk driftstörning, oavsett vad är det värt att stanna upp och omgående ta tag i dessa problem. Jag kan inte komma på många möten jag skulle stannat kvar i om jag fått reda på att vi hade HTTP-status 500 på vår webbplats.
Förutom det uppenbara problemet att det drabbar dina besökare så ger det en dålig signal till sökmotorer som Google - din webbplats tycks inte vara robust eller pålitlig nog att skicka besökare till. Med andra ord bör du ha koll på dessa fel även om de aldrig inträffar när det är högt tryck på din webbplats.
Det måste inte vara hela sidor som kastar serverfel, delar av det som krävs för en sidvisning kan själva lämna serverfel. Exempelvis om din stilmall genereras på serversidan eller kanske om du har någon hemmaknackad statistiklösning som skapar dolda bilder.
När kan man förvänta sig HTTP-status 500?
Det kan vara en driftsättning av ny kod som gått snett, så om du vet med dig att det är den dagen på månaden kan du kanske lugna dig en timme innan du börjar jaga de som förhoppningsvis jobbar på en lösning.
Det kan också vara så att det är en överbelastning av webbplatsens drift. Ett sådant tillfälle jag beskrev i boken Webbstrategi för alla var när en långsam extern tjänst gjorde att hela webbplatsen gick ner. Du vet det där om att ingen kedja är starkare än sin svagaste länk. I det fallet fick webbservern vänta på svar från en allt för långsam extern tjänst, notera att då en webbserver inte kan ta emot oändligt många samtidiga besökare så börjar den refusera nya besökare genom att slänga Error 500 hej vilt.
Överbelastningsattack?
Om det nu är en attack man råkar ut för, eller annan inte legitim trafik, så kan detta vara en förvarning om att ta kontakt med de som hanterar serverns infrastruktur. I bästa fall finns ett filter att sätta in för att skydda webbplatsen men ändå släppa fram vanliga besökare.
Ett “bus” mot Polisen.se utfördes för många år sedan från massor med webbplatser som ville statuera någon form av exempel med anledning av tillslaget mot serverhallen där The Pirate Bay hade sina servrar. Man läste in en tung PDF-fil från polisen.se vid varje sidvisning på sina egna webbplatser och skickade på så sätt alla sina egna (ovetande) besökare som attack mot Polisen.
Lösningen är inte nödvändigtvis att ta bort PDF-filen, då kanske alla 404-fel istället sänker sajten, däremot kunde man säkert i nätverket kollat var lejonparten av trafiken kom ifrån. Om man innan webbservern filtrerat bort trafik från hamsterpaj.net med flera skulle webbservern fått lite andrum. Exakt hur denna episod slutade minns jag inte, men dessa kampanjer tenderar till att inte vara så långvariga.
Verktyg för att hålla koll på 500 Internal Server Error
Google Webmaster Tools har en alldeles utmärkt vy för fel i både 500 och 400-serierna, du kan till och med få mejl om det inträffar oväntat många fel. Ytterligare en anledning till varför alla webbansvariga måste registrera sig på Google Webmaster Tools (och Bings motsvarighet förstås).
Om du kan få statistik över serverfel på en längre tidsperiod är det att rekommendera. Det är lite surt att inse att ens webbplats en dag sjönk till botten på grund av ökad komplexitet bakom kulisserna och att den ropat på hjälp via error 500 i flera månader.
Vill du göra manuella stickprov fungerar Pingdoms test väl.
