NS overweegt tweede website tegen overbelasting

Om de problemen met overbelasting van de NS-website tegen te gaan, overweegt de NS om een tweede website met een aparte url in het leven te roepen voor wanneer de huidige site down gaat. Het is een van de scenario's die de NS overweegt.

Een woordvoerder van de Nederlandse Spoorwegen bevestigde de plannen nadat Het Financieele Dagblad er een bericht over had gepubliceerd. Het openen van een tweede website is een van de scenario's die wordt overwogen om de structurele problemen met overbelasting van de NS-website tegen te gaan. Volgens woordvoerder Eric Trinthamer van de vervoerder zou die tweede website bijvoorbeeld alleen actuele reisinformatie kunnen bevatten, waardoor deze lichter is.

Volgens Trinthamer wordt overwogen om die tweede site een aparte url te geven. "Zonder een tweede url kun je geen aparte website opzetten", stelt hij. Het is echter de bedoeling om bezoekers van NS.nl bij overbelasting door te leiden naar de tweede website. Waarom die website niet plat zou gaan wanneer al het verkeer vanaf de eerste wordt doorgeleid, is echter onduidelijk.

Trinthamer zegt: "Het moet zo gebruiksvriendelijk mogelijk zijn. Het is een van de maatregelen die we naar de minister hebben gestuurd." Een andere optie is een backup die op dezelfde url draait, zoals overigens ook gebruikelijk is voor backuplocaties.

Problemen op het spoor leiden vaak tot problemen op de NS-website. Ook vorige week vrijdag, toen de sneeuwval in heel Nederland voor grote vertragingen zorgde, was de website nauwelijks bereikbaar, terwijl reizigers juist werden opgeroepen om in verband met die problemen op de website te kijken. Volgens de NS kan de website momenteel 24.000 bezoekers per minuut aan. Een jaar terug was de maximale belasting nog 7000 bezoekers per minuut.

Reacties (139)

Mooi dat tweakers hier allemaal gaan vertellen hoe het wel moet zonder dat ook maar iemand inzicht heeft in infrastructuur van de NS site. Daarnaast is het ook maar de vraag hoeveel extra geld je wilt pompen in de capaciteit van de site voor die enkele keren per jaar. Helemaal als alles zo aan verandering onderhevig is.

De vergelijking die gemaakt werd met Zwitserland is dan ook niet relevant omdat die ook 1miljard euro meer per jaar in het spoornet steken en de prijzen van kaartjes ook duurder zijn

Bij de ANWB en de Schiphol site waren de problemen het zelfde maar daar klaagt niemand over (Vliegtuigen moesten nog vertrekken volgens de site terwijl ze al geland waren)

Uit het jaarverslag:

Kosten uitbesteding automatisering 2010: 114 miljoen.

Helaas wordt de materiële vaste activa niet opgesplitst waardoor het lastig is om te zeggen wat er hiernaast nog aan "IT" wordt uitgegeven. Naast lonen.

Uiteraard is het ook zo dat automatisering bij de NS verder gaat dan een aantal webservers waardoor dat een bedrag zoals bovenstaand natuurlijk geen reflectie geeft op de onderhoudskosten van het "website-serverpark".

Wat je wel kunt zien is dat het eigen vermogen van in 2009 op 2.876 Miljoen stond en in 2010 op 2.974 (pag. 141). Nu weten we niet wat dit in 2011 is geworden maar persoonlijk lijkt me dat je 10 miljoen aan uitbreiding van je "website-serverpark" toch wel je site in de lucht moet kunnen houden in de piek momenten.

Precies!
Daarnaast is het kopen van extra 'ijzer' gewoon zelden een optie. De complexiteit van de setup wordt dusdanig lastiger dat je daardoor ook weer extra risico's inbouwt.
Een load-balancing database bijvoorbeeld is veel gevoeliger voor storingen tijdens normaal gebruik.

En de routeinformatie komt ook uit een systeem dat maar een max. capaciteit heeft. Voor elke route moet gekeken worden wat de alternatieven zijn, als je van Utrecht naar Amsterdam wilt kun je misschien wel 10 verschillende routes nemen. Op het moment dat er een vertraging optreed moeten er weer meer opties onderzocht worden die weer alternatieven hebben...

O ja, en de gebruiker heeft ook ... 'F5' ... een ... 'F5' .... handje ... 'F5' ... ervan ... 'F5' ... het systeem extra te belasten als het niet snel genoeg gaat. Zodra het systeem richting 100% belasting gaat kan het best zijn dat de load daardoor ineens verdubbeld.

Wat ik trouwens hilarisch vond vorig jaar was dat de reizigers aan het klagen waren dat het 'blauwe bord' in de vertrekhal van Utrecht leeg was... er reed geen enkele trein, er was geen trein in te plannen, DUS was het bord leeg. Dat er NIKS rijd is ook informatie, maar blijkbaar is die informatie ongewenst

Wat ik trouwens hilarisch vond vorig jaar was dat de reizigers aan het klagen waren dat het 'blauwe bord' in de vertrekhal van Utrecht leeg was... er reed geen enkele trein, er was geen trein in te plannen, DUS was het bord leeg. Dat er NIKS rijd is ook informatie, maar blijkbaar is die informatie ongewenst

Die informatie ('geen informatie') is niet per se ongewenst, maar dan moet die informatie wel duidelijk en logisch zijn.
Een leeg informatiebord kan ook betekenen dat het systeem niet werkt; het zou vele malen duidelijker zijn als er op het bord ook daadwerkelijk stond dat er geen vertrekkende treinen zijn.

[Reactie gewijzigd door Ghost Dog op 10 februari 2012 02:41]

Wat een onzin om hier een tweede website voor aan te steken, met nota bene nog een extra URL ook.

Er zijn legio mogelijkheden om dit netjes dynamisch te laten schalen. Bijvoorbeeld het on the fly uitbreiden van het serverpark (automagisch extra virtual servers aansteken) of andere oplossingen zoals het verpakken van dynamische content naar statische pagina's op piekmomenten, zoals bijvoorbeeld nu.nl de extreme pieken kan opvangen.

Een aparte URL is werkelijk de meest klant onvriendelijke en minst effectieve oplossing die ik ooit heb gehoord. Ik weet niet waar de NS zijn advies inkoopt, maar ik adviseer (gratis!) om dat maar eens ergens anders te doen

Je vergeet dan wel dat het berekenen van de tijden en routes niet statisch KAN. Dit is dus een optie waar je of gigantisch moet gaan schalen, of je schakelt die functionaliteit uit.

Dit laatste is feitelijk wat ze doen door een tweede statische site ernaast te hanteren met basis informatie over storingen en vertragingen.

Deze oplossing zal ook niet uit de lucht gevallen zijn. Er zitten vast prima experts achter dergelijke ideeen, en niet een of andere NS-woordvoerder die dit even uit z'n mouw schudt

Deze oplossing zal ook niet uit de lucht gevallen zijn. Er zitten vast prima experts achter dergelijke ideeen, en niet een of andere NS-woordvoerder die dit even uit z'n mouw schudt

Denk (hoop!) dat dat wel klopt, ja. Er gaat ook vaak informatie verloren bij de overdracht van technici naar woordvoerder en woordvoerder naar pers. De woordvoerder weet duidelijk niet waar hij het over heeft als de pers doorvraagt.

De technici leggen hun scaling, load-balancing oplossingen waarschijnlijk uit als "dat is dan net alsof we tijdelijk een tweede website draaien die iets minder kan." Want hoe ga je anders dat aan je management uitleggen die amper een desktopcomputer kunnen gebruiken?

Ik hoop het, maar ben wel realistisch. Ik heb al in 2003 aan het Centraal Reizigers Informatie Systeem (CRIS) gewerkt, als contractor voor ProRail. Dat was een oefening in frustratie.

Zo was ProRail er heilig van overtuigd dat er 24 uur in een dag zitten. Het lukte ons niet om ze te overtuigen dat het toch echt een variabele was ipv een constante.

Ook op technisch vlak hadden ze een erg beperkte kijk. Zo zagen ze kans om te kiezen voor Alpha gebaseerde systemen op exact dezelfde dag dat Compaq aankodigde dat ze End-Of-Life gingen. En die systemen moesten dus nog 15 jaar mee!

Een statische backupsite die in plaats van de hoofdsite wordt geplaatst is geen oplossing? Of zelfs een beetje fatsoenlijke caching van de hoofd-content binnen een goede loadbalanced oplossing?

Of gewoon een automatische redirect naar een noodsite vanaf het hoofddomein zodat de reiziger gewoon naar ns.nl kan gaan?

Ok, de bezoekersaantallen waarmee de NS te maken krijgt zijn wel heel extreem, maar ik zie geen reden waarom dit niet mogelijk is met een beetje logisch nadenken + voldoende capaciteit op hun hoofd-url.

Inderdaad! Ze kunnen de huidige site verbeteren. Op dit moment hebben ze geen browser caching. Ook maken ze geen gebruik van nginx over apache.

Ik hoop dat deze man de taal van de technici niet goed begrepen heeft. Het is absoluut zinnig om de reisinformatie van een ander domein te laten serveren dan de content van de NS-website zelf. Komt ook nog eens de performance ten goede. Tweakers doet dit ook door gebruik van het domein tweakimg.net voor plaatjes e.d.

Op die manier kun je makkelijk apart capaciteit schalen voor reisplanner en voor overige functies (wat ik stiekem eigenlijk al hoop dat gebeurt op applicatieniveau!)

Ook is het, maar ik heb geen idee hoe het nu zit, absoluut een goed idee om de database in stukken te splitsen (sharding), naast caching. De database heeft maar heel weinig inserts/updates. Daarnaast zoeken mensen natuurlijk grotendeels reisadvies voor "vandaag", terwijl reisadviezen voor over een paar dagen dan dus rustig naar een andere database kunnen worden gestuurd. Dit hangt natuurlijk een beetje ervanaf hoe die database is opgebouwd.

Al met al, er zijn heel veel manieren om de verschillende bottlenecks op te lossen en de NS-reisplanner is juist zo'n dienst die goed kan schalen. Zoiets zal de NS-woordvoerder wel bedoeld hebben.

Om een "tweede" website in de lucht te brengen is natuurlijk waanzin.

[Reactie gewijzigd door Keypunchie op 9 februari 2012 10:33]

Wat een onzin om een 2e websites te bouwen die minder kan.
Zet de boel gewoon in een grote cloud zoals die van amazon waar duizenden dingen draaien zodat hij gewoon wat meer van de cloud vraagt en je het totaal niet merkt als het druk is.

Een simpele statische gele pagina met blauwe letters bijvoorbeeld. De meeste treinen vallen toch uit, dus de informatie van treinen die wel rijden kunnen op de voorpagina. Op pagina twee een lijst met alle uitgevallen treinen, in één request. De boel doorzoeken met een javascriptje client side.

Geen plaatjes, geen fratsen. Niks niet.

En dit alles updaten met een cron die elke minuut draait.

en dan kom je bij het probleem dat mensen hele databases moeteng gaan downloaden...
ik noem een xml file met 1000'en regels al snel niet heel klein meer... en dan nog de javascripts voor de UI.. en je bent misschien van de server load af maar niet van de bandwidth verslinding..

dan zou je dat dus weer per station moeten filteren oid om te zorgen dat men niet alle treinen van heel nederland gaat downloaden.. maar dan wordt je rijs plannen nog steeds een verschikkelijk werkje als je met semi-bevroren handen op een perron in midden-nergenshuize al 2 uur op je trein staat te wachten...


ik vrees dat gracefull degradation nog wel eens lastiger kan zijn dan je zou willen...

1 malig veel is veel beter dan continue belasting.
Reken maar uit. 24000 bezoeker per minuut die 1MB downloaden(in 1 request) is 400MB/s dat is voor een paar servers wel te doen. En de volgende minuut hoef je dus die 24000 mensen niet meer van prik te voorzien. Als ze 100KB downloaden, maar ze moeten 10 requests doen, heb je dezelfde bandbreedte, maar meer requests, en dus meer load op je servers.

Laat de NS website nou net iets meer zijn dan 100KB per request....

Het geen de NS wil doen is nog helemaal zo gek nog niet. Simpel weg op het moment dat alles naar de peop gaat een simpele site tonen die veel minder bandbreedte en server tijd vergt per page view dan de huidige site. Dat is helemaal zo'n gek idee nog niet alleen de manier waarop men dat wil doen toont weer aan dat men geen idee heeft wat men aan het doen is.

Een alternatieve URL een andere server etc is allemaal helemaal niet nodig.

Het is en blijft belachelijk dat met een maximum van wat 50k hits per seconde de NS niet instaat is een server te bouwen die dit simpel weg aan kan. Het lijkt heel erg veel en dat is het ook de server moet erg groot zijn en je zult aardig wat kennis van zaken moeten hebben en hard moeten zijn tegen de mensen die de site bouwen om bepaalde dingen simpel weg niet toe te laten.
Een aantal voorbeelden zijn bijvoorbeeld niet 18 afzonderlijke javascript bestanden laden, ook de 12 CSS stylesheets zijn een beetje teveel van het goede. Als je dit terug dringt tot 2 bestanden die alle functionaliteit bevatten dan laad de pagina een stuk sneller. Er zijn erg veel dingen die je kunt doen om de site een stuk lichter te maken voor de backend zo kun je ook de images samenvoegen en aan de client kant weer laten uitpakken iets dat ook weer een boel zal schelen omdat je niet steeds de overhead hebt van het opnieuw starten van een download. Dat de client wat meer werk heeft hier aan meh... dat merkt de eindgebruiker echt niet meer met de systemen van tegenwoordig.

De NS moet simpel weg mensen inhuren die weten wat ze doen als het gaat om het opzetten van een site van dit formaat waar je van tijd tot tijd een enorme hoeveelheid aan requests kan verwachten.

De Amazon cloud is helemaal zo'n gek idee nog niet maar om te beginnen kunnen ze bij de NS niet verkroppen dat ze zelf dit niet kunnen hosten en daar naast zouden ze dan ook echt iets van techniek moeten begrijpen en dat doen ze duidelijk niet. De kosten zullen erg mee vallen als je kijkt naar wat je nu kwijt bent voor een vergelijkbare betrouwbare site.
Veel mensen vergelijken Amazon en andere cloud oplossingen met een simpele hosted server ergens in een rack, en kijk eens naar de kosten... maar bedenk je dan eens dat je hier niet een server maar een server in een cloud hebt die dus ook kan migreren naar andere hardware mocht de hardware waar deze op dit moment op draait zich even niet lekker voelen. Ook kun je het ding zo neer zetten dat het automagisch schaalt en je betaald alleen voor het geen je gebruikt niet voor de tijden dat de server midden in de nacht bijvoorbeeld simpel weg 1 honderdste van het verkeer ziet dat er in de spits voorbij komt.
Het argument dat Amazon duur is is lang niet altijd waar zeker voor een systeem als de NS servers kun je in de Amazon cloud een zeer betaalbare meer betrouwbare en betere oplossing dan zelf een systeem opzetten dat voor een groot deel van de tijd simpel weg stil staat en als het echt aan de slag moet telkens weer blijkt net niet goot genoeg te zijn.
Juist het schalen van de cloud aanbiedingen is wat ze voor dit soort dingen heel erg aantrekkelijk maakt omdat je niet betaald op het moment dat het verkeer normaal is en op het moment dat het belachelijk hoog is je simpel weg voldoende capaciteit hebt om het aan te kunnen zonder dat je de hardware ooit hebt hoeven aanschaffen.

ik denk dat ik een betere oplossing weet, eentja waardoor al die mensen de site niet gaan plattrekken... namelijk: gewoon de treinen laten rijden als ze er zijn... gewoon ad-hok licht op groen treintje door...

ik heb van het weekend 3 treinen op het allerlaatst niet zien vertrekken omdat ze toevallig te laat binnen kwamen dus is er geen ruimte op het spoor en vertrekken ze leeg... en ondertussen sta je dus 2 uur te wachten op een trein zonder te weten of er die avond nog 1 zal gaan rijden...

het zou dus leuk kunnen zijn als 'thuiskomen' meer prioriteit kreeg dan een of andere leuk bedacht maar totaal onwerkbaar schema...

Weet je wel wat Amazon kost als je een beetje verkeer begint te krijgen?

Zet gewoon een paar reserve servers klaar en zet een goeie geek aan het werk voor een mooie loadbalancing oplossing.

Edit: De mooie oplossingen vliegen hier in de reacties over de tafel. De persoon uit het artikel weet er gewoon echt te weinig vanaf. Klinkt echt als een leken oplossing de hij voorstelt.

[Reactie gewijzigd door teek2 op 9 februari 2012 11:16]

voor een mooie loadbalancing oplossing.

Wat je wil is graceful degradation. Schakel bij (te) hoge belasting minder noodzakelijke delen uit. Totdat je uiteindelijk nog maar een enkel tekstbestandje hebt met de meest belangrijke info.

Precies. Dat is een vrij aardige oplossing voor de NS. Een propere load-balancer is natuurlijk ook gewoon een optie. Het idee alleen al van een 2e website is echt absurd en weer typisch NS. Moeilijk doen lijkt altijd de voorkeur te hebben.

Als het niet de load, maar de bandbreedte is die het probleem vormt, dan zou ik zeggen: pleur die kansloze foto-carousel uit op de frontpage, totdat het weer rustig is. Of laat die idioten die die site gemaakt hebben wat minder scripts includen, maar bundel en minify ze. Ook dit is niet echt om aan te zien op die site.

Precies. Dat is een vrij aardige oplossing voor de NS. Een propere load-balancer is natuurlijk ook gewoon een optie. Het idee alleen al van een 2e website is echt absurd en weer typisch NS. Moeilijk doen lijkt altijd de voorkeur te hebben.

Het idee van een 2e website is duidelijk belachelijk. Maar voor een leek (en dat zijn ze duidelijk bij de NS, naar het blijkt) een simpele, en logische oplossing. Wij, als tweakers, kijken daar heel anders tegenaan.

Maar de NS zou er goed aan doen om eens professionals in te huren voor een goedwerkende website, ipv een leek de boel te laten organiseren, met inderdaad load balancing servers en gracefull degradation technieken.

Maar de NS zou er goed aan doen om eens professionals in te huren voor een goedwerkende website,

Dit is nu juist zo'n oplossing van die zogenaamde professionals die menige semi-overheid op een dwaalspoor weten te brengen met hun veel te duur betaalde adviezen.

2de website/server lost het probleem niet op. Als de eerste hier niet doet gaat iedereen massaal naar de 2de en ligt die er uit. 3x raden er komt dan een 3de website.

Er zijn in nederland een paar goede hoster die met loadbalancer kunnen werken en dat zelf kunnen uitvoeren via 2 datacentra mocht de ene er uit liggen.

Sorry Olaf, maar ik denk niet dat dat is wat de NS nodig heeft, al is het alleen al om het punt dat bezoekers hier niet op zitten te wachten. Die willen dezelfde functionaliteiten als altijd, anders raken ze in de war. Iets wat je niet wilt aangezien die piekdrukte waarschijnlijk alleen voorkomt als men toch al behoorlijk geïrriteerd is over de core business van deze club :-)

Bij hoge load zijn de meeste bezoekers op zoek naar zeer specifieke informatie. Door de layout van de uitgeklede website hetzelfde te houden maar de functionaliteit te beperken kunnen de bezoekers op een vertrouwde manier, maar dan veel sneller, hetzelfde doen en de informatie krijgen die ze zoeken.

Graceful degradation betekend niet dat je de website helemaal uitkleed tot het bare minimum. Graceful is de operatieve factor hier: Zorg dat bezoekers hetzelfde kunnen blijven doen met een lagere bandbreedte en serverload.

Dit komt ook door de grafische gedeelte van de website. Vergelijk maar tussen alleen tekst met animaties. Inderdaad met animatie heb je hoge load omdat alles beweegt en mooi moet zijn.

Wat heb jij aan het digitale spoorboekje op de website als 85% van de treinen niet rijdt?
Niks, dus die functie kan uit en worden vervangen door een statisch bericht over wat nog wel operationeel is.

Met de 200 miljoen die ze achter hebben gehouden ivm OV chipkaart project http://www.telegraaf.nl/o..._duur_door_truc_NS__.html zouden ze best en webfarm achter een multihomed loadbalancers kunnen hangen.

Maar waarschijnlijk mag het geen geld kosten en kiezen ze willens en weten voor een budgettair "voordelige" oplossing, zoals ze nu ook al voor het spoor doen.

Enige site die er moet komen met een overzicht van verstoringen/problemen in de winters sinds bestaan van NS, mogelijk dat het dan duidelijk gaat worden dat het door het management komt en niet door het materiaal op zichzelf.

Correctie..... NS management gaat Italiaanse treinen gebruiken, deze vallen uit zichzelf bij goed weer al uit elkaar, deuren gaan tijdens het rijden open, kabels liggen los en ze kunnen niet tegen vorst. Al met al is het veiliger dat een trein zelf niet kan rijden dan dat er met onderliggende wissels een probleem is

http://www.geenstijl.nl/m...250_nog_slechter_dan.html

[Reactie gewijzigd door totaalgeenhard op 9 februari 2012 12:22]

[...]
Correctie..... NS management gaat Italiaanse treinen gebruiken, deze vallen uit zichzelf bij goed weer al uit elkaar, deuren gaan tijdens het rijden open, kabels liggen los en ze kunnen niet tegen vorst. Al met al is het veiliger dat een trein zelf niet kan rijden dan dat er met onderliggende wissels een probleem is

http://www.geenstijl.nl/m...250_nog_slechter_dan.html

Je vergeet een, vooral in Nederland, belangrijk voordeel van die Italiaanse treinen aanschaf: 50% korting op de aanschafprijs.
Nadeel is wel dat ze in Denemarken allemaal niet meer rijden ...

[Reactie gewijzigd door Xubby op 9 februari 2012 13:01]

50% op tweedehandse treinen is geen slechte deal, heb je straks minder om op af te schrijven. (hoeveel % van aanschaf prijs is subsidie van het RIJK?)

Idd. Nu.nl werkt daar ook mee, wat je goed kunt zien zodra er ergens ter wereld een grote ramp is (of iets anders wat veel interesse wekt).

Dit is een goede oplossing zonder extra kosten.
Bij grote luchvaartmaatschappijen werkt dat ook.
Bijvoorbeeld bij vulkaanerupties en andere calamiteiten.

Ze moeten gewoon alle mobiele apps via een andere site laten lopen. Daar gaat het alleen om de essentiële data, want de skin zit al in de App. Daar hebben de mensen het meeste aan als ze op het perron staan. Als je thuis zit is het vervelend dat de site eruit is, maar je zit niet gestrand op Utrecht CS bijvoorbeeld.

Wat een onzinnige opmerking.
Je gaat echt geen reserve servers neerzetten voor die 2 dagen per jaar dat ze nodig zijn;

Een passieve amazon setup die invalt in geval van nood, lijkt me inderdaad de broodnodige oplossing.

Virtualiseren.
Het wordt druk? heb je er zo een VM bijgezet, in de loadbalancer ermee en klaar.
Zijn wij hier ook druk mee bezig, en hoor al van meer bedrijven dat ze dit doen.
Bespaart kosten, is efficient en snel.

dan nog heb je een extra machine nodig, tenzij je structureel niet al de power van je server gebruikt..

Lijkt me onlogisch als je aan de max users zit? Dan staan die servers neem ik aan 100% te stoken. Of ze moeten een bandbreedte probleem hebben, maar dat lijkt me wel een van de eerste dingen die je goed regelt...

virtualiseren is hier de oplossing net NIET voor.

Waar haal je namelijk die extra virtual machine vandaan? Dezelfde kvm/esx bak?

Virtualiseren is leuk, om dingen of te scheiden dan wel om een paar laag belaste systemen te consolideren, maar niet om belasting-problemen op te vangen.


Ik zie zowieso niet hoe het zo'n groot probleem moet zijn. Google en facebook hebben ook niet google1.com, google2.com en google3.com omdat het 'te druk is' maar mooie technische oplossingen die hier boven en onder al ruim beschreven worden.

Het is jammer dat niet aangegeven wordt waar het probleem hem in zit, bandbreedte, loadbalancer die het niet aan kan danwel server(s) die overbelast zijn.

Virtualiseren.
Het wordt druk? heb je er zo een VM bijgezet, in de loadbalancer ermee en klaar.
Zijn wij hier ook druk mee bezig, en hoor al van meer bedrijven dat ze dit doen.
Bespaart kosten, is efficient en snel.

en een wassen neus. gevirtualiseerde oplossingen kunnen per virtuele pizza doos niet dezelfde belasting aan als echte hardware. Ik heb hier al menig bedrijf grandioos mee op z'n snuffert zien gaan.

Wil jij meer kunnen? Dan zal je meer ijzer moeten neergooien.

Dat komt omdat sommige mensen virtualisatie niet snappen (waaronder jij blijkbaar).

Ja, virtualisatie kan hier een deel van de oplossing zijn. Bijvoorbeeld:

Bij een bepaalde load kan er meer hardware ingeschakeld worden om snel te kunnen loadbalancen. Statische data en frontend kan gecloned worden op een snelle en effectieve manier. Ook Cache, proxy en loadbalancer server kunnen snel gecloned worden.

Virtualisatie is vooral dynamisch zijn. Het is geen heilige graal maar een goede stap in de richting.

Wat kosten extra servers dan? Het is tijdelijk; voor een dag of twee... En dan alleen statische pagina's serveren. Al is de rekening 50000 euro, dat is niks vergeleken met wat zo'n dag kost.

Jah lekker makkelijk. Even in de cloud gooien.

Nou ben ik nogal kritisch over het hele clowd gebeuren. Maar één van de grootste voordelen is natuurlijk wel schaalbaarheid.
Zodra de NS merkt dat de load te hoog wordt op de servers kan je er via een externe partij natuurlijk vrij simpel een paar extra servers bij schakelen. Natuurlijk heeft dat tijd nodig om op te zetten, maar binnen 15min moet het te doen zijn (mits de site (infrastructuur) goed is opgezet).

Het idee van een 2e site is natuurlijk gewoon kansloos. Tenzij ze een uitgeklede versie van de site bedoelen, met alleen statisch html pagina's, waardoor je ook een heel hogere load aan kan (zoals buienradar.nl bijvoorbeeld).

[Reactie gewijzigd door TMDevil op 9 februari 2012 09:59]

Is gewoon het serverpark uitbreiden niet een betere optie?

Zou nogal raar zijn als je een aparte site hebt voor vertragingen. www.nsvertragingen.nl.
Overigens zou die site volgens mij ook nog vaker bezocht worden ook.

Veel te duur, servers in huis hebben die het hele jaar uit hun neus staan te eten.

De NS is geen stichting die elk dubbeltje moet omdraaien.
Het is een commerciële partij die een dienst verleent, waaronder informatie over de reizen die ze aanbieden.

We hebben het hier niet over de bakker op de hoek mensen.

Ter info:
Winst 2011: 108 miljoen euro
Omzet van 1,79 miljard euro

http://www.nuzakelijk.nl/...er-omzet-en-winst-ns.html

Ja dus? Het is gewoon een commercieel bedrijf, hoor.
Je reactie slaat dus werkelijk nergens op.

Bovendien heb je denk ik geen idee waar het om gaat? De standaard capaciteit van de website is al flink overgedimensioneerd, want 's nachts gebeurt er natuurlijk (bijna) niks. En zo zit er al flinke variatie in gebruik per dag, waar men rekening mee houdt. Dus er staan al servers uit hun neus te eten. Als je dan ook nog eens rekening moet gaan houden met een onverwachte calamiteit, dan wordt het belachelijk veel. En dan nog, wat je ook neer zet: het is altijd een keer te weinig. Je ziet het: de NS heeft zijn capaciteit alweer verdriedubbelt het afgelopen jaar en het is nu al weer te weinig!

Zover ik weet is 'thuus bij de NS' gewoon een datacenter van InterConnect. Gewoon een (behoorlijk) datacenter dus.

De capaciteitsvraag voor een website meet je natuurlijk overdag en niet 's nachts. Aangezien de NS 's nachts bijna geen diensten levert (op het nachtboemeltje na) aan consumenten, hoef je die nacht dus echt niet mee te nemen.

Als je dan naar de capaciteitsvraag voor overdag kijkt, ga je dáár een buffer inbouwen. Onverwachte calamiteiten kan geen vorst of sneeuw zijn, of bladeren op de rails. Dat gebeurt ieder jaar opnieuw....en gaat dus ook ieder jaar opnieuw mis. Onverwacht?

Als je een slimme oplossing bouwt, hoeft het allemaal niet zo extreem veel duurder te zijn. Zoals hierboven al wordt aangegeven kan er ook weleens inhoudelijk naar de site gekeken worden. Daarnaast is de NS niet de enige die in de treinen zit in de wereld. Ze zouden bijvoorbeeld ook eens kunnen kijken bij de DB. Zelfs buiten de treinen zijn er vergelijkbare dienstverleners te vinden die hier ook oplossingen voor hebben moeten bouwen. Misschien eens wat rondsnuffelen op Schiphol?

Tot slot is investeren in goede communicatie middelen lonend. Het op zwart gaan van je website is dat in ieder geval niet. Het is de hoogste tijd dat de NS wat competentie gaat uitstralen. Ook op het gebied van techniek.

[Reactie gewijzigd door EnigmA-X op 9 februari 2012 18:32]

als hun netwerk overbelast is zal dat niet werken.. ik zou zelf dmv een round-robin dns (om maar de goedkoopste oplossing te nemen, maar een fail-over werkt misschien beter )
met een paar reverse squid proxies om de load zo goed mogelijk te verspreiden op verschillende servers bij verschillende providers (thuus bij de ns, rackspace, ovh, etc) eventueel cloudfllare als laatste redding...

loadbalancing blijkt dus moeilijk te zijn voor hun ? 2e website wat een onzin

Als je een enorme piek hebt in aantal gebruikers, zoals we die zien bij grote spoorproblemen, is het uitbreiden van de capaciteit gewoonweg geen schaalbare oplossing meer. Ik ben erg teleurgesteld dat vele tweakers zoals jij dezelfde (domme) reactie hebben dat ze maar gewoon een een groter serverpark moeten nemen zodat hun hoofdsite niet stuk gaat.

Het is gewoon te duur je serverpark te voorzien op een 10 keer groter bezoekersaantal dan je normaal hebt, om toch maa rin geval van nood die paar dagen op een jaar online te blijven.
Als de NS nu een succesvol privébedrijf met genoeg geld was had je een zaak, maar voor een staatsbedrijf in ecnonomisch moeilijke tijden is dat een idioot standpunt.


Een goedkopere oplossing is zoals aangehaald gracefull degradation, waarbij je de dienst deels terugschaalt om toch een zeker niveau van dienstverlening te kunnen garanderen.
Ik weet neit of jij en de andere klagers hier dat beseffen, maar de huidige ns-site is behoorlijk zwaar: je kunt er niet gewoon de verbindingen en vertragingen bekijken, maar ook tickets kopen en je persoonlijke abonnement bekijken en eventueel aanpassen. Daarbij ziet alles er wat 'fancy' uit.
Het is een behoorlijk dynamische moderne website.

Ik vind het dus een geweldig idee om op momenten van nood de site terug te schalen zodat tenminste iedereen de dienstverlening nog kan bekijken. Een simpelere, meer statische website waar je gewoon de noodzakelijke info kunt raadplegen: geen mogelijkheid tot kopen van tickets of je persoonlijke abonnement bekijken: enkel dienstverlening.
dat verlicht de belasting op de servers enorm! Waardoor je met dezelfde capaciteit dus een veelvoud aan bezoekers kunt bedienen.

het uitbreiden van de capaciteit [is] gewoonweg geen schaalbare oplossing meer. Ik ben erg teleurgesteld dat vele tweakers zoals jij dezelfde (domme) reactie hebben dat ze maar gewoon een een groter serverpark moeten nemen zodat hun hoofdsite niet stuk gaat.

Een loadbalancer is een betere oplossing dan twee sites. Loadbalancers schalen veel beter. Die werken ook nog uitstekend met 3 servers. 3 sites daarentegen, dat is niet schaalbaar.

Waarschijnlijk weten ze bij de NS ook wel wat een loadbalancer is. Het probleem is dat niet alles zich makkelijk laat loadbalancer. Het is geen kunst om een loadbalancer voor een batterij webservers te zetten. Een website zoals die van de NS biedt dynamische informatie aan die waarschijnlijk ergens centraal wordt bijgehouden in een database. Als de prestaties van die database niet voldoende opgeschaald kunnen worden bereik je niets met je batterij webservers die geen verbinding kunnen maken met een overbelaste database-server.

Graceful degredation vind ik ook niet zo'n geweldige oplossing. De actuele reisinformatie lijkt me de zwaarste functionaliteit op de website. Als je die weglaat hou je weinig zinvolle informatie over als de pleuris uitbreekt. De NS zou moeten kijken hoe het systeem schaalbaar gemaakt kan worden. Stel dat er nu inderdaad wordt gewerkt met web/applicatieservers en een centrale reisinformatieserver, dan zou het zinvol zijn om een laag tussen beide in te bouwen die bestaat uit servers die zelfstandig en zeer snel reisinformatie op verzoek van de webservers kunnen aanleveren. De middenlaag bevat een kopie van de gegevens in de centrale database en wordt bijvoorbeeld elke minuut van actuele wijziging voorzien of wanneer de centrale database aangeeft dat er wijziging zij in de reisinformatie. De centrale database hoeft alleen nog maar de middenlaag van updates te voorzien. Zowel de middenlaag als de frontend kunnen zeer goed opgeschaald worden. Dat kan eventueel met vm's die op afroep door een hosting provider worden ingezet als het normale serverparkje van de NS het werk niet meer aan kan.

...wat ga je balanceren? Denk je dat de hele NS site afhankelijk is van 1 machine? Die zou de capaciteit die momenteel al geleverd wordt nooit kunnen leveren: er wordt dus al degelijk al gebalanced. Hoe efficiënt dat is weet ik niet maar het gebeurt wel al.
Het gaat dus niet om een banalcing-probleem, maar om een probleem dat de ruwe kracht nodig om de huidige volledige site aan zo een piek aan gebruikers te leveren gewoonweg niet kan geleverd worden op een economisch verantwoorde manier.

Daarom is een aparte light-versie van de website wel degelijk een goed idee. Of dit gebeurt door een ander domein en werkelijk andere machines te gebruiken is maar een kwestie van invulling: natuurlijk vind ik het makkelijker als eenzelfde adres naar de op dat moment meest geschikte site wijst, en de hardwarekost is ook lager ( en dus de opstelling efficienter) als dezelfde servers afhaneklijk van de situatie de light of de volledige website teruggeven.
Maar alngs de andere kant is een apart adres en een apart serverpark:
-makkelijker op te stellen (niet dat het ZO moeilijk is alles op 1 plaats/adres te doen)
-duidelijker voor de gebruiker (waarom ziet de site er plots anders uit???)
-redundanter (als het serverpark voor de volledige site in moeilijkheden komt door overbelasting of gewoonweg fysieke redenen zoals natuurramp of een cyberaanval blijft de light-versie werken - tenzij het probleem zo grootschalig is dat ook die getroffen wordt natuurlijk)

Met een beetje geluk draaien ze die tweede site op dezelfde server....

Op Nu.nl staat:

Afgelopen vrijdag raakte het treinverkeer ernstig ontregeld door sneeuwval. De website, die reizigers massaal bezochten, viel ook enkele keren uit. Dat kwam onder meer doordat sommige vertragingen of wijzigingen handmatig op de website moeten worden doorgevoerd. Op dat moment is de website onbereikbaar. Een groot deel van de wijzigingen gaat overigens wel automatisch.

Dat is toch op zich al vreemd?

Geen idee hoe het bij de NS werkt, maar het belgische railtime faalt ook als er te veel problemen zijn bij het spoorverkeer. Informatie van vertragingen per trein komen automatisch van een back-end, maar de ticker die de storingen weergeeft is een manueel process.

Dat is inderdaad heeeeeel vreemd. Een website niet bereikbaar omdat je wijzigingen in de data er achter doorvoert... Wat voor idiote oplossing hebben ze daar?

Of gewoon 1 statische html pagina maken met de storingen/updates die je online gooit zodra het zo druk wordt (want daar komt 99% voor), en dan de mogelijkheid om door te klikken naar de normale website..
Of misschien de normale website een beetje uitkleden, zoals de mobiele website (http://mobiel.ns.nl/), want die bleef wel gewoon overeind tijdens de drukt volgens mij.

Nee helaas, de mobiele website ging afgelopen vrijdag ook vrolijk down. Even als de apps voor smartphones.

Ja dat weet ik niet, misschien tijdig geweest, afgelopen vrijdag kwam me vrouwtje niet op de site met der mobiel [(galaxy s android) maar ik wel zonder problemen, gebruik geen android.. Natuurlijk hoort dit niks met elkaar te maken te hebben, daarom dacht ik dat de site gewoon onstabiel was, maar voor mij wel de hele dag door bereikbaar geweest, althans op de momenten dat ik keek.

De website zelf wel maar zodra je aanspraak ging doen op een Database niet meer. Zoals het plannen van een route.
Denk dat daar ook het pijnpunt zit op piekmomenten.

kunnen ze geen deal maken met een grote hostingleverancier dat ze extra capaciteit krijgen wanneer nodig?
in een goede vm omgeving mag dat geen probleem zijn.

Dit heet cloud, en de leveranciers zijn o.a. Amazon, Google, Microsoft, Rackspace, etc.