Request Time Out - Hvornår er et website nede?
Vi bliver klogere!
Nu har vi været i luften i noget nær 3 måneder. En af de absolut vigtigste erfaringer vi har gjort os er at det er "normalt" for nogle websites at have en lang responstid.
Det gælder primært for websites der ligger langt væk fra vores sfære, (Europa). Det har resulteret i at brugere har fået "falske" fejlbeskeder hvis sitet har været. fx. 25 sekunder om at svare.
Det har vi ny "løst", således at vores robot er blevet langt mindre følsom overfor langsomt svarende sites, men samtidig giver besked hvis sitet virkelig ikke er til at få fat i. (Det bliver testet 3 gange med en timeout på 40 sekunder).
Når det så er sagt, så er det altså ikke meningen at et site skal tage over 20 sekunder at få fat i, - så vi kommer her med nogle gode råd til hvordan du sikrer dig dit site svarer ordentligt.
Website performance
Google, der jo mere eller mindre bestemmer hvilke websites der skal vises i søgeresultater, lægger stor vægt på at websites er responsive, at de er hurtige og ikke misbruger brugerens båndbredde. Det er faktisk ikke så ringe endda, men det stiller nogle store krav til dit websites performance.Time to first Byte er essentiel, når vi taler om timeouts, er dette den vigtigste faktor, det betyder webserveren har modtaget forespørgslen fra browseren og er begyndt at svare tilbage, vores robot er standard sat op til at vente 20 sekunder, så hvis du har et nogenlunde normalt fungerende website, så burde det svare tilbage inden for 0.5-2 sekunder. - Gør det ikke det, skal du udover at kigge på dit netværk også gå din kode igennem. - Mere følger på dette punkt i vores snart-kommende performance guide hvor vi samler op på de ting vi ser mest.
Netværk!!!
Skal du have et hurtigt website, så er det altafgørende at der ikke er langt fra brugerens browser til din webserver. Har du et stort website der tilgåes fra hele verdenen så kan det i den grad anbefales at lave load-balancing på websitet, således at forespørgsler bliver dirigeret hen på en instans der er tæt på brugeren. Det kan bla. laves i Azure (https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-configure-geographic-routing-method) Har du dit website på egne servere, er det vigtigt at webserveren kører med de mest optimale tilstande netværksmæssigt, hvis vi formoder websitet ligger i DMZ, så er det vigtigt at den boks (virtuel eller fysisk) er konfigurereret med det rigtige netkort, - at routeren / switchen eller hvad du nu ellers har i dit fysiske netværk er konfigurerer til at køre med højst mulig hastighed. Ligeledes er det vigtigt at hvis database og website ligger på forskellige servere, at der er den hurtigst mulige forbindelse mellem disse (fiber?).