Cumulus velox

Som du kanske har märkt så har utseendet på sulo.se förändrats en aning på sistone. Det beror på att jag härom veckan flyttade denna sida (och ett flertal andra sidor) till Amazons europeiska moln.

Jag planerar nämligen att använda mig av Amazons automagiska tjänster för lastbalansering, skalning och övervakning (som tidigare enbart var tillgängliga i USA, men nyligen släpptes i Europa).

Den mest uppenbara skillnaden mellan de olika molnen är dock svarstiderna.

Pingdom halva september

Ovanstående graf visar först svarstiderna i USA, sen ser man flytten till EU och därefter bytet till en lite vassare serverinstans. Idag ligger svarstiderna rätt så konstant kring 500 ms (från Sverige).

Nu kör jag (än så länge) bara den näst minsta instansen hos Amazon och ingen CloudFront (som enligt test av Jonas Leijon ger ca 40 % lägre svarstider). Det bör med andra ord gå att komma ner till svarstider på ca 400 ms.

Säger det här dig ingenting?

Låt oss kolla hur svarstiderna hos några svenska webbhotell ser ut. Christian har mätt upptiden på 4 olika webbhotell och även publicerat dessa rapporter offentligt. Utöver upptiden framgår även svarstiderna.

Under september var svarstiderna hos dessa webbhotell den följande:

Binero: 634,54 ms
Glesys: 767,4 ms
Loopia: 1390,71 ms
Patrikweb: 525,39 ms

Nu ska man inte stirra sig blind på detta. Det finns faktorer som kan spela in till både webbhotellen och molnets för- och nackdelar. Men det är ändå roligt att se hur molnet, oavsett vad vissa påstår, är en slagkraftig aktör.

10 tankar på “Cumulus velox

  1. Det vore väldigt intressant att veta:

    1. Hur pingdom mäter responstiden.
    2. Vilka sidor testerna är genomförda mot.
    3. Storleken på sidorna.

    Jag gjorde några enkla tester med curl mot oss själva och på en och samma server får jag helt olika responstider.

    “Serverns standardsida”

    Lookup time: 0,001
    Connect time: 0,007
    PreXfer time: 0,007
    StartXfer time: 0,016
    Total time: 0,016

    “Min blogg – WordPress + Supercache”

    Lookup time: 0,001
    Connect time: 0,007
    PreXfer time: 0,007
    StartXfer time: 0,018
    Total time: 0,105

    En annan blogg (wordpress utan cache)

    Lookup time: 0,026
    Connect time: 0,033
    PreXfer time: 0,033
    StartXfer time: 0,256
    Total time: 0,349

    Jag har mätte från en Telia anslutning och beroende på hur sidan levereras/genereras så får man olika responstider.

    Slutsats. Man kan inte döma webhotell/molnet efter svarstider till en specifik sida. Det kan som du skrev finnas många faktorer men där så klart även nätet och peering partners är en av dom…

    Det kan man se på 5 månades sammanställning i från oss…

    http://img.skitch.com/20090923-jwidtq3x5pupp3nk4yyek8h422.jpg

    Australien är inte vår starka sida… (undersöks)

    Just det. För att testa respons använde jag följande:


    curl -w 'nLookup time:t%{time_namelookup}nConnect time:t%{time_connect}nPreXfer time:t%{time_pretransfer}nStartXfer time:t%{time_starttransfer}nnTotal time:t%{time_total}n' -o /dev/null -s www.sulo.se

    • Ja, det var som sagt därför jag skrev att man inte ska stirra sig blind på dessa svarstider.

      Ska fråga Pingdom om de kan ge en lite mer ingående förklaring till hur de mäter svarstiderna.

  2. Jonathan, om du använder en HTTP-check, vilket jag antar, inkluderar svarstiderna (“response time”) i vår kontrollpanel tiden det tar att kontakta din server och ladda ner HTML-sidan (inga bilder, etc).

    // Peter Alguacil, Pingdom.com

  3. Om fulla html sidor laddas ner är det väl omöjligt att jämföra – då htmlsidan kan vara så olika uppbyggd? Är inte enkel ping-tid ett mer relevant sett att se om man når tjänsten i sig på jämförbara tider (vilket bör vara snabbare för de svenska i Sverige). Dock får man ju inte jämförelsen tex om hur mycket ett webbhotell översäljer en server och är “ok” eller inte ok med att ha segare servrar som resulterar i segare svar vid laddning av html.

    Man borde kanske ha ping tiden – samt som ett sekundärt mättal där kanske 50-100 olika sajter från varje driftspartner som mättest som ovan för att få fram snittsiffror om både vägen dit och hur pass responsiv servrarna är.

  4. Det svåra med ping är att det väldigt ofta spärras i brandväggar och att ICMP många gånger är ett nedprioriterat protokoll.

    Svarstiderna genom att ladda ner hela sidan är väldig relevant för en själv för det motsvarar ju användarens upplevelse. Det är dock ett helt ointressant sätt att jämföra kvalitet med.

  5. Spelar ju ingen roll om html sidan i sig är olika uppbyggd, den läser ju bara den som ren text. Även om det är mycket text så bör det inte påverka så många ms.

    Inte precis man har sina sidor på skiten 56k.

    Det som kan spela roll är dynamisk innehåll som körs på servernivå som php exempelvis.

    Åt andra sidan kan man väl fråga sig vad för kod man skulle kunna tänka köras på sin startsida som skulle ta lång tid att köra på servern.

    Även där borde det inte påverka så mycket.

    Om man ser på egen del så borde jag förlora en hel del ms på egna sidan då den kör på virtuell nod med liteförlite minne så den swappar och även belastar CPU 5 gånger i minuten när den kör vissa graf och statsberäkningar.

    Även att den är virtuell så blir det alltid något lite högre ms.

    Så tycker det är konstigt att andra har så mycket högre än mig, visst jag sitter direkt ansluten till hela stamnätet från Växjö. Med direktförbindelser till VXJ-MLM, VXJ-STH, samt vidare mot GBG.

    Så inga höga ms eller möjliga kapacitet störningar på vägen, men det borde i regel endast kunna påverkat ms till 20-50ms högre.

Kommentarer inaktiverade.