Hjælp … jeg er blevet populær.

Når dit website vokser dig overhovedet kommer det typisk bag på dig, det er ikke en situation du har forberedt dig og du har nu fået en mail fra dit webhotel med beskeden om din konto er suspenderet fordi du enten har brugt for meget trafik eller overbelastet serveren.

En anden mulighed er slet og ret at dit site begynder at blive så langsomt at dine brugere klager, og måske endda begynder at forlade siden. Det er selvfølgelig ikke rart, så hvad gør man for at løse problemet?

Den typisk fejl folk begår er at skifte til et andet, lidt større og måske lidt bedre webhotel hvorefter der går et par uger eller måneder indtil det hele gentager sig igen, som almindelig forbruger eller sågar som teknisk dygtig programmør kan det være svært for ikke at sige umuligt at vurdere kvaliteten på et tilfældigt webhotel.

En anden typisk fejl er at gå ud og leje den størst mulige server, og flytte din side derover. Det skal nok hjælpe i starten, primært fordi du pludselig har alle maskinens resourcer for dig selv, du vil opleve at størstedelen af din maskine slet ikke bruges eller at siden stadig er langsom selvom der er mange resourcer tilbage.

Det kan lidt sammenlignes med at købe en racerbil og så sætte din 7 årige søn til at køre i den, der er en ret go chance for at han ikke får den til at køre og hvis endelig han gør ødelægger han både sig selv og bilen.

Du bør selvfølgelig starte ud med at konsultere en person der har forstand på at køre racerbilen, og på samme måde skal du selvfølgelig også søge eksperthjælp når du skal have dit website til at bryde hastighedsgrænserne på internettet. En dårlig opsat dedikeret server eller virtuel server kan faktisk performe dårligere end et ganske almindeligt discount webhotel.

En anden observation man også er nødt til at gøre sig, hvad sker der den dag dit website kører på den størst mulige server med den størst mulige internet forbindelse med så meget ram som dit operativsystem kan håndtere … og du bliver ved med at få flere kunder og få højere og højere belastning på maskinen.

For at det hele ikke bare er metaforer vil jeg gennemgå nogle eksempler på hvad man rent praktisk kan gøre, og kort nævne et par fordele og ulemper:

  • Finjustering af serveren resourceforbrug, der er ikke nogen endelig løsning i din specifikke situation kan det være at din database kræver flere resourcer end din webserver, eller omvendt. Der er nødt til at foreligge en analyse af din applikation og dens resourceforbrug før der kan laves et brugbart estimat. Efterfølgende er man nødt til at finjustere løbende under drift.
  • Fordeling af roller til flere servere, det klassiske råd er at skille webserveren fra databasen og på den måde opnå flere resourcer end én fysisk maskine kan levere, men du rammer igen et problem når du så har brugt alle resourcer på begge maskiner og du ikke kan købe større maskiner.
  • Cluster setup med flere servere til hver rolle, en anden løsning er at sætte hhv. 2 eller flere database og webservere op, på den måde kan du skalere din løsning ved at tilføje flere maskiner af samme størrelse som din nuværende, du kan vælge at opgradere der hvor det giver mening og lade de dele som klarer sig fint være. Den største ulempe ved et cluster setup er at det er utroligt komplekst og typisk kræver en del tilpasning.
  • Flere forskellige former for cache, en cache er et midlertidigt lager hvor man opbevarer ting midlertidigt for hurtigt at kunne finde dem igen. Der findes flere forskellige caching teknikker og de har alle hver deres fordele og ulemper. Det er f.eks. muligt at sætte en række serveren foran webserverne som laver hjælper med at aflaste serverne, hvordan disse performer og generelt påvirker din applikation afhænger 100% af deres opsætningen.En anden mulighed er at installere en op-code cache som f.eks. APC, når webserveren udfører en PHP Fil skal den første fortolke alle kommandoerne i filen og oversætte dem til maskin-kode som serveren CPU kan forstå. Denne process foretages hvergang en PHP fil skal udføres, uanset om indholdet af filen er ændret eller ej. Dette er selvfølgelig et spild af resourcer og det er netop her en opcode cache kommer ind, den husker oversættelsen og genbruger den hvis der er behov for det. Det giver et enormt performanceboost på PHP tunge sider og det giver stort set ingen problemer.
  • Optimering af kildekoden og databasen, selv dygtige programmører laver dårlig kode, og dårlige programmører laver forfærdelig kode. Jo længere tid et projekt er under aktiv udvikling desto mere forværers koden og jævnlig oprydning er nødvendig. Tillæg dertil at de typiske iværksætter-projekter er startet eller udviklet af et par unge knægte, eller ihvertfald nogen som ikke er specialister indenfor deres felt. Det kan være ganske udemærket, men det kan sammenlignes lidt med at bygge et højhus på et fundament af halm og ler.Med andre ord er der næsten altid ydelse at hente i koden, og typisk vil der være behov for løbende at omskrive større eller mindre dele af koden, og det typiske tidspunkt at påbegynde dette arbejde er netop når den første opgradering, til f.eks. en virtuel server, er begyndt og man så småt begynder at øjne behovet for skallering i fremtiden.
  • Cloudløsninger og andre sky-basserede services, du har helt ret, det ligner ikke mig og bruge buzz-words, og pointen med det her punkt er også at afvise at “skyen” er svaret på alle dine bønner. For det første er sky ikke et fast defineret fagligt udtryk og det er derfor noget vrøvl at bruge det som sådan, det er derimod et buzzwork sælgere bruger for at lyde moderne. Alle steder du hører ordet “sky” eller “skyen” kan du sætte “internet” eller “internettet” ind i stedet, og på den måde afkode hvad din sælger forsøger at sælge dig.Lad mig slå det fast, Amazon, Microsoft Azure og den million af små private cloud-udbydere der skyder op verden over er direkte at sammenligne med en klassisk hosting udbyder der udlejer fysiske og virtuelle servere. Forskellen er 80% markedsføring og 20% smarte web-kontrolpaneler.Så ja, du kan sagtens bruge cloud til at løse dit problem, men det er kun en del af løsningen, alt ovenstående er stadig aktuelt uanset om du bruger en udbyder der kalder sit udstyr for en/flere serverpark(er) eller en/flere sky(er)

I min forretning har vi valgt at kombinere rådgivning og drift, således at vi kan designe en komplet hostingløsning og enten levere en projektplan eller slet og ret implementere den og servicere den for kunden, derudover har vi etableret professionel redundant hostingservice i Danmark, og hvis kunden har behov for hosting i udlandet har vi flere forskellige faste partnere vi trækker på. 

Det vigtige er altså ikke hvilken udbyder man vælger, men hvem man vælger til at administrere løsningen og hvordan man gør det.