Regelmatig worden we door klanten gevraagd hoeveel bezoekers een website kan hebben. Vaak komt dit voort uit de vraag welk pakket ze nodig hebben voor hun webhosting. Toch is dat niet zomaar zonder meer vast te stellen en komt er net wat meer bij kijken dan een simpele vuistregel.

Het aantal bezoekers dat je website tegelijkertijd kan hebben is van een aantal factoren afhankelijk.  Uiteraard maakt het een groot verschil of je een relatief simpel en statisch (dus zonder gebruik van bijvoorbeeld PHP) fotoalbum bezoekt of dat je een website gemaakt in een wat groter websitepakket als Drupal, Joomla of WordPress benadert. Toch zijn er een aantal tools beschikbaar die je een aardige inschatting kunnen geven over het maximaal aantal simultane bezoekers. Dit is nuttig om te weten want als je site ineens populair wordt doordat deze onderdeel wordt van een reclamecampagne, kun je het niet gebruiken dat  de site onbereikbaar raakt.

Er is een aantal tools waar je simpelweg de URL van je website ingeeft waarna de tool voor jou zal simuleren dat er een X aantal gebruikers tegelijkertijd op de website komen. Vanuit het Apache-project is daar Apache Bench. Vergelijkbare tools zoals Siege en http_load doen dit op vergelijkbare wijze. Je geeft een totaal aantal bezoekers op en hoeveel bezoekers er tegelijk langs moeten komen en het programma zal je een resultaat geven.

$ ab -n 10 -c 5 http://www.oxilion.nl/

Server Software:        Apache
Server Hostname:        www.oxilion.nl
Server Port:            80

Document Path:          /
Document Length:        16432 bytes

Concurrency Level:      5
Time taken for tests:   1.595 seconds
Complete requests:      10

Nu is het natuurlijk twijfelachtig of dit een waarheidsgetrouwe weergave van een gemiddelde bezoeker is. Immers, je simuleert nu bezoekers die enkel een landingspagina opvragen, meer niet, en hopelijk is de site interessant genoeg voor de gemiddelde bezoeker om op z’n minst een aantal subpagina’s te bekijken. Er vanuit gaande dat deze beginpagina altijd sneller laadt dan de achterliggende pagina’s (je wilt immers dat klanten de eerste pagina altijd vlot binnen hebben), geeft dit een vertekend beeld.

Er zijn een aantal tools waarmee je dit kunt veranderen. Één van de bekenste opensource projecten die hierin een tool vrijgeeft is Apache’s JMeter. Naast een grafische weergave van het verloop van je stresstest kun je hier ook op een fijnmazige wijze opgeven welke URLs je wilt laten volgen. De tools hierboven zijn ook in staat om op de één of andere wijze een lijstje URLs af te lopen, maar JMeter pakt dit op een andere wijze aan. Je kunt JMeter namelijk als proxy instellen in je eigen webbrowser. Als je dan via deze proxy de te testen website opvraagt, wordt alles opgenomen. Niet alleen het lijstje met URLs wordt dan bijgehouden maar ook hoe lang het duurt voordat je doorklikt. Op die wijze ben je in staat om met veel hogere nauwkeurigheid het surfgedrag van je bezoeker na te bootsten.

Ondanks de inmiddels ietwat ouderwets ogende interface, is hiermee wel een mooi overzicht te verkrijgen, met legio mogelijkheden om te testen.

Grafische resultaten van een loadtest

Naast deze tool van Apache zijn er nog meer (commerciële) tools die hetzelfde doel hebben. Een overzicht van test-tools is op internet terug te vinden. Ook de wikipedia-pagina van loadtools houdt een overzicht bij. Mochten jullie nog specifieke tools gebruiken vind ik dat natuurlijk leuk om als reactie op dit artikel te kunnen lezen!

Sinds 12 januari jl. wordt door SIDN enkel de naam van de domeinnaamhouder en het e-mailadres van de administratieve contactpersoon in de WHOIS getoond.

WHOIS is een functie waarmee een ieder gratis alle gegevens bij een domeinnaam kan opvragen. In een antwoord van de WHOIS worden alle persoonsgegevens van de domeinnaamhouder getoond, waaronder een adres en een telefoonnummer. Na diverse debatvoeringen is binnen SIDN besloten dat de bescherming van de persoonsgegevens belangrijker is dan de mogelijkheid om deze gegevens vrij op te kunnen vragen. SIDN is niet de eerste registry die de publicatie van gegevens beperkt heeft; ook voor .eu en .be is dit bijv. al langere tijd beperkt.

Enerzijds zijn wij hier blij mee. Dit betekent namelijk dat wij hier geen discussie over hoeven te voeren met klanten die niet wisten dat het in een openbaar register opgenomen zou worden en die daar vervolgens van schrikken. Anderzijds zal dit voor jullie, onze klanten, betekenen dat wij in gebruiksvriendelijkheid een stap terug hebben moeten doen. In de verhuisprocedure op onze website kan nu namelijk slechts de (bedrijfs)naam van de houder worden ingevuld op het contract dat we opsturen i.p.v. alle gegevens. Dit zal zo blijven totdat DRS EPP af is, daarmee vervalt het verhuisformulier namelijk.

We zijn erg benieuwd hoe jullie dit ervaren!

In de hostingindustrie worden verschrikkelijk veel methoden gebruikt om het dataverbruik te berekenen.  De ene methode is nog weer moeilijker dan de andere. Want, laten we het vooral niet te makkelijk maken. Ik kan daar helaas weinig aan doen. Tijd om ze uit te leggen.

Om de verschillende mogelijkheden eens in kaart te brengen moeten we eerst de verschillende vormen eens opsommen, dit zijn:

- Afname in GB
- Afname per Mb p95 (meest gebruikt)
- Afname per Mb average
- Afname per Mb unmetered
- “Onbeperkt dataverkeer”

Hier komen we al een aantal termen tegen die voor discussie kunnen zorgen, GB, Mbit. Daarom houd ik de volgende standaard aan: 1 Byte bestaat uit 8 bits. De hoofdletter is belangrijk, vooral in de afkorting. Een Mb is dus een Megabit en MB is een MegaByte. Dat scheelt een factor 8. De toevoegen /s geeft aan dat het per seconde is. Veelvouden van bytes zijn vaak vermenigvuldigingen met 1024*.

Afname per GB
Bij een afname per GB betaal je voor de hoeveelheid dataverkeer die is gebruikt. Of het nu inkomend dataverkeer is of uitgaand. Dit wordt vaak gezien als de meest “eerlijke” vorm van afname. Je betaalt namelijk voor het dataverkeer dat je echt gebruikt. Dat hangt natuurlijk ook samen met de prijs.

Deze vorm van afrekening is interessant als je vaak pieken hebt met veel verkeer en het verschil tussen de piek en het “normale” erg groot is. Deze vorm wordt vaak gebruikt op shared omgevingen en losse servers. De andere vormen van dataverkeer zijn namelijk lastig te berekenen per website als deze op hetzelfde, shared, IP draaien. Een nadeel kan zijn dat in deze vorm inkomend en uitgaand verkeer bij elkaar worden opgeteld waardoor het veel duurder kan uitvallen als het inkomend en uitgaand verkeer nagenoeg gelijk is.

Afname per Mb p95
Dit is misschien wel de bekendste vorm van afrekenen bij kwart, halve of hele racks. De methode is eigenlijk vrij eenvoudig. Er wordt elke 5 minuten gekeken hoeveel bandbreedte er wordt gebruikt. Na een maand worden al deze metingen op rij gezet en worden de 5% hoogste metingen (+/- 1,5 dag) eruit gehaald . De meting die daarna het hoogst is geldt als uitkomst en wordt gebruikt in de prijsberekening.

Dit is een goede vorm als je wilt voorkomen dat een forse piek (bijv. DDoS of eenmalig downloaden van een groot bestand) zorgt voor een forse naheffing. Als je een piek krijgt van 200 Mb/s, gedurende een dag, en je gebruikt normaal maar 10 Mb/s, dan wordt die hele piek van 200 Mb/s dus uit de meting verwijderd. In mijn optiek de mooiste vorm om geruzie over de kosten van kortstondig pieken te voorkomen.

Afname per Mb average
De makkelijkste vorm qua berekening. Wederom wordt met een interval (5 minuten) gemeten hoeveel bandbreedte er wordt gebruikt en vervolgens wordt het gemiddelde berekend van al deze metingen. Dit betekent wel dat als je een DDoS krijgt van één dag met 200 Mb/s, dat je dat terug ziet in de naheffing. De mate waarin je het terug ziet is natuurlijk afhankelijk van de duur en de grootte van de piek (DDoS). In het voorbeeld een slordige 7 Mb/s.

Afname per Mb unmetered
Dit noem ik zelf eigenlijk altijd flat-fee of afgeknepen. Deze vorm van verkeer lijkt soms heel interessant vanwege de prijs. Je weet vooraf wat je betaalt en (de verkoper zegt) dan maakt het niet uit hoeveel dataverkeer je daarover verbruikt. Dat is ook waar, er is alleen één belangrijke maar. De verbinding is namelijk afgekapt op bijvoorbeeld 10 Mb/s of 100 Mb/s. Je kunt niet pieken, wat kan zorgen voor enorme vertraging als het druk wordt.

* = Het is 1024 omdat het 2^10 is. 2 is daarbij het aantal mogelijkheden per karakter in het binaire getallenstelsel (nul of één).

Welke vorm van afrekening heeft jouw voorkeur en waarom?

Een secundaire nameserver is, zoals de naam al doet vermoeden, de tweede server die geraadpleegd zal worden wanneer er een DNS lookup gedaan wordt. De secundaire nameserver wordt dan ook maar in weinig situaties gebruikt. Waarom betalen voor iets dat je bijna nooit gebruikt?

Wanneer wordt een secundaire nameserver (ns2) gebruikt?
Er zijn eigenlijk maar twee situaties waarin een secundaire nameserver wordt gebruikt. De eerste situatie is heel simpel; wanneer de primaire nameserver niet of slecht bereikbaar is. De tweede situatie is iets complexer.

Wanneer een registrar, of deelnemer in termen van de SIDN, een domeinnaam registreert moet zij deze aan nameservers koppelen. Op die manier weet een applicatie (je browser of Outlook bijvoorbeeld) op welk IP-adres een bepaalde website (www.) of een mailserver (mail.) te vinden is.

Waarom zou ik een secundaire nameserver willen?
Vaak wordt er gezegd. Als ik mijn hosting doe op hetzelfde systeem als mijn nameserver, dan heb ik toch niets aan een secundaire nameserver? Gedeeltelijk klopt dat. Er zijn twee redenen om het toch anders te doen.

Reden 1. Op het moment dat jouw server onbereikbaar is en iemand een e-mail naar jou wil sturen, kan zijn e-mailprogramma jouw server niet vinden. Heel lastig.

Reden 2. Als je meer domeinnamen krijgt en ze – om welke reden dan ook – uit elkaar wilt halen, dan moet je de DNS van de ene server naar de andere server verhuizen. Daarvoor moet je dan naar je registrar toe om de nameservers voor jouw domein aan te laten passen. Natuurlijk host je ns2 ook nog eens in-zone (wat wil zeggen dat je eigenlijk een recursieve loop maakt, ns2.denniswijnberg.nl is de nameserver van denniswijnberg.nl, maar waar op welk IP zit denniswijnberg.nl). Administratief een zootje dus.

Wat adviseer jij?
Ik adviseer altijd om minimaal twee nameservers te hebben, drie is nog beter. Je moet er dan wel voor zorgen dat:
- De nameservers niet op dezelfde (fysieke noch virtuele) server draaien.
- De secundaire nameserver niet in hetzelfde datacenter staat. Want als dan je datacenter offline is… Juist.