NS-site ging offline bij winterweer door fout capaciteitsverdeler

De site van de Nederlandse Spoorwegen ging tijdens het winterweer begin februari offline vanwege een fout bij de configuratie van de capaciteitsverdeler. Ook stond er een verkeerde link op de calamiteitenpagina van het spoorbedrijf.

De site had 1,8 miljoen pageviews per uur aan moeten kunnen, maar bij de helft van het aantal pageviews ging het toch mis, blijkt uit een document dat door freelance-journalist Brenno de Winter namens Nu.nl is gepubliceerd.

De uitval van de site bleek aan twee zaken te wijten: ten eerste stond er een verkeerde link op de calamiteitenpagina, waardoor de webservers een 'exponentiële toename van aanvragen' te verwerken kregen. Bovendien was er een fout gemaakt bij de configuratie van de capaciteitsverdelers, waardoor de site niet het gestelde maximum van 1,8 miljoen pageviews per uur aankon. Daardoor ging de site een gedeelte van de dag down.

De NS-site kampte met een grote toename in verkeer, omdat op vrijdag 3 februari het spoorwegverkeer ernstig werd ontregeld door sneeuwval. Omdat de verstoring niet vooraf was aangekondigd, zaten veel mensen op school en op het werk en moesten naar huis zien te komen. Op pieken haalde de site 928.000 pageviews per uur. Daarom zette NS een calamiteitenpagina in, een lichtere site met alleen actuele informatie, in plaats van de volledige site. De NS overweegt een tweede 'backup-site' te maken voor tijden van grote drukte.

Reacties (56)

[robinverl]

928 000 / 3600 = 258 req / s. Dat is echt niet spannend veel, toch jammer dat zo'n groot bedrijf dat niet af kan.

[MBV]

Zet firebug maar eens aan bij de ns.nl website. Ik gok dat elke pageview een stuk of 50 requests oplevert: op de homepage staan al 27 plaatjes en 17 javascript-bestanden. En dan niet op static.ns.nl, maar domweg op www.ns.nl. Dat moet dus ook allemaal door de load-balancer.

[robinverl]

Homepage doet hier 57 requests, verdeeld onder:
- 27 afbeeldingen
- 12 stylesheets
- 17 scripts
- 1 html document

Die 17 scripts kunnen zeker gereduceerd worden naar één of een paar (met behulp van een minifier). Hetzelfde geldt voor de stylesheets.

Wat over blijft kan in een frontend cache (ala Varnish) en prima geservereerd worden.

En dan hebben we het nog niet gehad over sprites maken van die 27 afbeeldingen.

[MBV]

Of de whitespace van de homepage, of de options list met alle jaartallen van de komende 20 jaar, of algemene bloat in de HTML code. Ik hoop dat ze die gezipt over de lijn sturen...

Die homepage heeft ook 0,3 sec nodig (volgens HTML comment op de laatste regel) om gegenereerd te worden, geen idee of ze dat per gebruiker doen of 1x per minuut.

[Reactie gewijzigd door MBV op 25 juli 2024 03:39]

[Brantje]

Ik denk per gebruiker: <!-- Generated : 2012-05-05 11:56, (0.144s) -->
Zou ten zotte zijn om bij iedere hit te cachen.

[Vaevictis_]

Helemaal mee eens, bij de ANWB hebben ze dit ook op deze manier opgelost. Waar bij de eerste sneeuw er zo'n 800Mb/sec traffic door heen ging is dit door het optimaliseren van de pagina's / scripts en reverse proxy Varnish zeer sterk afgenomen. De backend krijgt nu gewoon maar 1 request en de rest komt uit de cache!

Uiteraard wel SSL termineren op de loadbalancers.

Inderdaad productie kun je loadtesten vanuit de cloud. Zo lastig is dat niet, ik vind het wel een doodzonde als je dat niet goed test.

[PolarBear]

Alleen bij grote storingen is er een simpele pagina met alleen de storingsmeldingen, actuele treintijden en planner. Die pagina is vele malen lichter dan de normale website.

Internet/mobiel
Er is informatie verstrekt via de digitale middelen ns.nl, m.ns.nl en de reisplanner xtra. Dit betreft zowel algemene informatie
over de situatie op het spoor als informatie over trajecten (storingen) en informatie op trein niveau. Op ns.nl is de normale home
page vervangen door de zogenaamde calamiteitenpagina. Hierop heeft de reiziger een direct overzicht over de actuele situatie.

[Reactie gewijzigd door PolarBear op 25 juli 2024 03:39]

[robvanwijk]

Ik denk dat het punt vooral is "de gewone pagina kan (zonder verlies van kwaliteit / functionaliteit!) veel lichter". Als de reguliere versie (bijna?) net zo licht is te maken als de calamiteiten-versie, dan hoef je niet om te schakelen bij drukte. Dan voorkom je een enorme sloot potentiële problemen, dus daar is zeker iets voor te zeggen.

[MuddyMagical]

Let even op dat het hier ging om een speciale calamiteiten pagina die wel degelijk was getest tot 1.8 miljoen pageviews. Er is in de praktijk alleen een fout in gemaakt waardoor deze niet werden gehaald.

Dat de huidige frontpage van NS.nl veel meer requests doet is logisch.

[the_stickie]

gesteld dat het opvragen van de site 500kb aan trafiek veroozaakt, ben je wel >100MB/s op het internet aan het duwen, plus dat elke user een percentje cpu nodig heeft, x aantal MB RAM, en ook nog eens data uit de database... dan blijkt dergelijke belasting toch niet zo evident.
Een enkele server, zelfs een stevige kan dit niet aan, dus heb je een farm nodig en een loadbalancer. Deze complexiteit verhoogt de foutgevoeligheid.

ik ben het met je eens dat het jammer is dat het niet gelukt is zoals ze hadden gehoopt...

[robinverl]

100MB/s kan prima, meeste servers hebben namelijk dubbel gigabit. Verder kan alle images, javascript en css prima via een reverse-proxy en belasten de server dus niet of nauwelijks.

Zeker wanneer je dit gaat verdelen over meerdere servers stelt het vrij weinig voor.

[Verwijderd]

Prachtig... testen in de productie-omgeving. Zo blijft het spannend... :-)

[brompot758]

Production like load testen is best een dure hobby anders. Ze verwachten 500 pageviews per seconde gemiddeld, en je hebt ruim 50 bestanden per page (zie hieronder). Dan moet je dus even 25.000 TPS gemiddeld (zeg even 50.000 TPS piek) wegwerken, daar is best een knappe serverfarm voor nodig. Voor productie kost dat een hoop geld, als je er een tweede naastzet om te loadtesten vedubbel je de kosten.

Nu kun je natuurlijk met een deel van de pageviews op een deel van de hardware draaien, maar de praktijk leert dat je dat met minimaal 33% en liever nog 50% van productie moet doen om representatief te kunnen testen, dat kost ook nog best een flinke schep geld. En zelfs dan vang je bepaalde zaken niet zoals database connection pools die te klein zijn of switches waarvan de backplane het niet trekt.

Hoe graag we het ook anders willen zien, op heel grote server farms is een load test onder volle load gewoon economisch niet haalbaar. En ja, dan kom je er op productie pas achter of het goed gesized is en goed werkt onder load.

[HoppyF]

De kosten van een production like test omgeving valt in het niet bij de kosten van al het materieel en personeel van de NS en ProRail.

Voor de prijs van een stukje trein koop je een complete serverfarm en software en jaarlijkse variabele kosten erbij.
Je moet de kosten dus in verhouding zien.
En vergeet niet, de reiziger informeren is één van de belangrijkste taken van de NS.
Als een trein voor wat voor reden dan ook, niet kan rijden of vertraagd is wil je dat als reiziger weten. En dat altijd, ook als het slecht weer is, midden in de nacht is of 30C buiten is.

De NS (en ook ProRail) leven van de reizigers, zonder reizigers is er geen openbaar vervoer (per trein). Wat er dan overblijft is goederenvervoer.

[j-phone]

Ik neem aan dat de ICT afdeling geen onbeperkt budget heeft, om die reden worden representatieve testen dan ook veelal niet redundant uitgevoerd. Het kan wel zo zijn dat een enkele test een fractie is van de kosten van een trein, maar ja, dat budget zit dan in de weg.

[MadEgg]

En dat is dan, zoals bij veel bedrijven, een goed voorbeeld van een verkeerde verdeling van de beschikbare middelen. Heel veel niet-ICT bedrijven hebben geen idee wat er bij komt kijken om een betrouwbaar netwerk of een betrouwbare website op te zetten, en hoe veel geld dat kost. Dus wordt er maar flink op bezuinigd. Lijkt me hier duidelijk ook het geval te zijn.

[robinverl]

Om te testen ga je natuurlijk niet eigen hardware aanschaffen maar maak je gebruik van een dienst zoals Load Impact http://loadimpact.com/pricing en tal van anderen.

[N3oC]

Er zijn zat dienstverleners die een degelijke loadtest kunnen leveren die zeker niet extreem veel hoeven te kosten. Het grootste probleem is vaak het inzien van de kosten vs baten,down gaan kost indirect veel geld (en kost "het project" niets). Tevens kost een externe partij meer geld dan alleen de software omdat je ook een stuk expertise koopt.

Heel veel hardware heb je tevens niet nodig, een basistest puur op connecties had misschien een loadbalancer probleem naar boven gekomen en daar zijn 2 servers en een 100mbit verbinding genoeg voor.

Vaak worden dit soort testen in de nachtelijke uren gedaan (voor een NS moet dat wel kunnen), en hadden bepaalde punten zeker ontdekt kunnen worden! Dit lijkt als ik het rapport lees, getest op een 'acceptatie' omgeving maar een configuratie niet meegenomen naar productie op de loadbalancer oid.

[Bas_f]

Op een internationale site zoals Facebook is jouw commentaal gegrond. Echter, ns.nl krijgt tussen 03.00 uur en 04.00 uur een minimale hoeveelheid traffic, waardoor dat een uitgelezen moment is om even de productieomgeving op z'n flikker te geven. Op die manier hoef je geen testomgeving in te richten die gelijk is aan de productieomgeving. En zo kun je dus meteen zien of de loadbalancers hun werk doen en of de webservers en databaseservers het zelf goed trekken. Als alles op z'n bek gaat, heb je ruim de tijd om alles weer up en running te krijgen voordat de eerste treinen weer gaan rijden.

[Verwijderd]

Dat is de verkeerde mentaliteit, denk ik. Testen hoort gewoon onderdeel te zijn van de bedrijfsvoering en van de ICT dienstverlening in het bijzonder. Als dat niet haalbaar is, dan is de business case van het bedrijf als geheel niet in orde. Risico's nemen is aantrekkelijk, maar daarvoor is ICT tegenwoordig net iets te belangrijk.

[chromeeh]

Je zult verbaasd zijn over hoe vaak dit gebeurt bij heeeeel veel bedrijven.
Trial en error totdat het wel goed gaat....

[onlinegangster]

Capaciteitverdeler, wat SLECHT!!!

De capaciteit om aanvragen te verwerken is al aanwezig binnen hun serverpark. Die kan je dan ook moeilijk verdelen, me dunkt. De lading, aanvragen, op aanwezige capaciteit die wordt verdeelt. Dus zeg dan ook gewoon ladingsverdeler en liever loadbalancer damn!

[robinverl]

Je verdeelt de belasting over je capaciteit.

[_Eend_]

Het staat zo in het persbericht van de NS.. De dames en heren op de PR afdeling kunnen heel goed ouwenelen communiceren, maar termen als 'Loadbalancer' zullen ze niet vaak horen.

maargoed, als je een IT'er een persbericht laat schrijven gaat het ook niet goed, dan is het meestal te technisch voor de niet-tweakers. Wat ik @ work wel eens voorbij zie komen op de interne storingspagina

[sdekker]

Capaciteitsverdeler... een loadbalancer neem ik aan?

[MuddyMagical]

Dit woord staat ook zo in het document van de NS dus dat zal de reden zijn geweest dat het is overgenomen door de verschillende media.

Dus geen NU.nl vertaling.

[Commendatore]

Prima vertaling, toch?

Hoewel: belastingsverdeler zou beter zijn.

[Reactie gewijzigd door Commendatore op 25 juli 2024 03:39]

[sdekker]

Voor nu.nl misschien wel, voor tweakers.net lijkt me dat onnodig.

[Monochrome]

Tja, dat klinkt ook zo Robin Hood..

[Martao]

Een belastingsverdeler? Makkelijker kunnen we het niet maken, wel leuker?

[beantherio]

Dat vroeg ik me ook meteen af toen ik de titel las. Is het geen Vlaamse vertaling of zo? Zo klinkt het namelijk een beetje.

[witchdoc]

Voor nu.nl misschien wel, voor tweakers.net lijkt me dat onnodig.

Eerder storend zelfs..

Dat vroeg ik me ook meteen af toen ik de titel las. Is het geen Vlaamse vertaling of zo? Zo klinkt het namelijk een beetje.

Een vlaming gaat écht geen vertalingen maken van computertermen hoor. Dat is nog eerder iets voor Nederlanders.

[Verwijderd]

Eerder storend zelfs..

Zeer storend zelfs. Hoop dat de titel gecorrigeerd kan worden? D'r is geen hond in .nl die weet wat een capaciteitsverdeler is en elke tweaker weet wat een loadbalancer is.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 03:39]

[Cageman]

Dan ga ik een keer trots aangeven dat ik een tweaker ben die dat nog niet weet. Ze zijn er wel! Of één, in ieder geval.

[jellever]

De NS is niet echt lekker bezig.. Ik weet via iemand die bij de NS werkt en zich bezighoud met de website dat ze vorig jaar ge-experimenteerd hebben met een uitwijk locatie. Dit hebben ze toen gewoon meteen in hun productie omgeving getest ipv een apparte test omgeving..

[j-phone]

Zoals het in de echte wereld ook zou zijn? Dat vind ik niet zo vreemd eigenlijk.

Edit: het hebben van een OTAP straat is een belangrijk gegeven en ook altijd aan te raden binnen projecten waarin nieuwe producten of upgrades van bestaande producten een rol spelen. Bj het testen van uitwijk functies, die enkel en alleen binnen een productie omgeving kunnen plaatsvinden, vind ik het niet vreemd dat dit binnen de productie omgeving getest werd.

[Reactie gewijzigd door j-phone op 25 juli 2024 03:39]

[Doc Zenith]

De uitwijk voor het regelen van het treinverkeer? Dat is weldegelijk eerst getest met meerdere testomgevingen die exact als productie zijn opgebouwd. Uiteindelijk is het hele proces (omschakelen hardware, maar ook inzet personeel en andere protocollen) ook nog in productie uitgevoerd, dat klopt.

[Verwijderd]

Duizenden gestrande bytes, drama was het.

[HoppyF]

Misschien moet de NS het bouwen en beheren van website overlaten aan bedrijven die daar verstand van hebben.
Het zelf aanmodderen levert alleen een slecht imago op en helpt de reiziger echt niet verder.

Laat de NS zich houden aan het transporteren van reizigers van A naar B.
Dat is alles wat men wil.

Verder valt het op dat het bij de NS en ProRail altijd een combinatie van fouten lijkt te zijn waardoor alles fout gaat.
Bij de minste geringste vertraging van één trein heeft te rest er ook meteen last van.

[Blokker_1999]

Ja, want eigen ICT personeel is slecht en ICT bedrijven maken geen fouten ... Denk je nu echt dat zo een groot bedrijf geen eigen ICT afdeling heeft met gekwalificeerde mensen? Dat zijn ook echt ITers en geen treinbestuurders die een cursus van een dag hebben gehad hoor.

En als er problemen zijn op het spoor. Hoe ga jij dat opvangen? Het is niet alsof een trein even rond het probleem kan rijden over de pechstrook of een andere kan voorbijscheuren op het linkerbaanvak van de snelweg. Op het spoor zit je vast achter je voorligger.

[HoppyF]

Nee, het eigen ICT personeel is helemaal niet slecht.
Zet ze vooral in voor de kantoorautomatisering van de NS en ProRail maar laat een belangrijke portal zoals de website voor de reizigers BUITEN het eigen ICT apparaat.

Ik zeg het nog eens, een website die het bij tijd en wijle zwaar zal krijgen moet je niet zelf willen beheren. Laat dit aan experts over.
De content kun je als NS / ProRail natuurlijk wel aanleveren. (vertragingen/storingen/actuele vertrektijden e.d.)

[TMDevil]

Ik denk dat de NS een groot genoeg bedrijf is om zelf die kennis in huis te hebben (en te houden). Het overlaten aan een ander (ICT) bedrijf lijkt leuk, daardoor komen er veel langere lijnen, en kan er over het algemeen minder snel geschakeld worden. Daarnaast wil dat andere bedrijf natuurlijk er ook aan verdienen, dus zou er net aan SLAs gedaan worden.

Om nu te roepen dat ze meer een extern bedrijf moeten inschakelen is onzin, kijk maar eens naar de problemen die er bij de ING zijn geweest. Die laten het over aan een specialist (KPN), en die specialist had ook zo zijn problemen

Het "outsourcen" van ICT lijkt leuk, maar zo rechtlijnig als jij het voorstelt is het echt niet.

[MBV]

Ik verwachtte dat ze de website zouden uitbesteden aan een bedrijf als Logica. Ik kan er alleen dit van vinden:
http://www.easy-site.nl/E...8882169231143&Time=182833

En wat jij zegt over die kettingreacties: de NS-medewerkers wilden geen rondje om de kerk rijden, dus moet de trein naar Groningen wachten op de machinist uit Maastricht. Als de trein uit Maastricht vertraging heeft, komt de trein naar Groningen ook te laat.

[Reactie gewijzigd door MBV op 25 juli 2024 03:39]

[A4-tje]

het mooiste was en is toch dat je met je smartphone vaak actuelere gegevens hebt dan de conducteurs zelf..... hoe fout kun je zijn als bedrijf. zorg dan tenminste dat iedereen (dus inclusief personeel) dezelfde gegevens hebben. dit is weer een voorbeeld dat NS zich beter bij de treinen kan houden

[PolarBear]

De conducteurs krijgen via hun Railpocket precies de informatie die de reiziger ook heeft. Dat systeem is ook in de lucht gebleven. Zie ook het document waarnaar gelinkt wordt.

Met uitzondering van de tijdelijke uitval van ns.nl, hebben de gerealiseerde verbeteringen qua reisinformatie goed
gewerkt:
 Meer middelen en betere stabiliteit van middelen, waaronder de Reisplanner
 Prominenter en actiever reizigers informeren (sms en reisplanner alert, winterborden, calamiteitenpagina etc.)
 Consistente informatie over duur en oorzaak van verstoringen (teletekst en ns.nl)
 Nieuwe Railpocket voor onze medewerkers, die voortdurend goed hebben gewerkt.

[ari]

Dus de mobiele website voor reizigers afschaffen zodat iedereen afhankelijk wordt van de vaak achterhaalde informatie van het personeel? Lijkt me niet het meest geniale plan ooit...

[iThinkSo]

Nee, exact andersom. De conducteurs voorzien van de data van de site voor reizigers.

[Verwijderd]

Sinds die nieuw Reispockets (conducteur) handhelds, is dat ook het geval.
Probleem met die oude was dat ze via bluetooth moesten tetheren

[Edoras]

Is exact de klacht die ik van een conducteur kreeg. Hij moest iets opzoeken voor een medereiziger en kreeg het niet voor elkaar. Vervolgens was het met mijn smarthphone binnen 20 seconden gepiept waarna ik de volgende reactie kreeg: 'die oude dingen die we hebben zijn een drama, hopelijk krijgen we snel nieuwe want reizigers met smartphones weten vaak meer en sneller wat er aan de hand is'. Blijkbaar lossen die nieuwe reispockets dat op?

[psresource]

Gelukkig kan het ook andersom, het personeel dus dezelfde correcte informatie geven die de klant ook heeft.

[Verwijderd]

Wat een onzin.
Gewoon een kwestie van een DNS pool en meerdere servers, en dan POUND ertussen gooien, geen probleem zou moeten zijn.

[Martao]

Wat weten we het hier toch allemaal weer goed.

[Verwijderd]

Wat doen we anders op tweakers ?
Uit onze neus pulken of zo ?