De forumvertragingen: een doorlichting

[Wapper]

Regelmatige deelnemers aan het forum weten dat het forum bij momenten traag is, en dat foutmeldingen optreden: vertragingen van tientallen seconden en ultiem de Nginx gateway error 502/504.

Het viel me al lang op dat het fenomeen niet random optreedt maar op bepaalde momenten, op het eerste zicht ruwweg in de periode van 18..25 minuten na het uur. Om dat te onderzoeken schreef ik een eenvoudige applikatie die elke 30 sekonden een connectie maakt met het forum, het subforum K&K opvraagt, en de tijd meet tussen het verzenden van het HTTP-request en het ontvangen van de laatste lijn van deze pagina.

Indien na 1 minuut geen antwoord wordt ontvangen dan telt de applikatie uit, en noteert 60.000 als meetwaarde. De applikatie heeft totnogtoe 18,5 uur continue gelopen, en 2200+ meetresultaten verzameld.



De resultaten worden gepresenteerd met de tijd modulo 60 minuten op de x-as, en de vastgestelde responstijden (in millisekonden) op de y-as.
Op deze wijze wordt de "tijdsfilm" opgedeeld in blokken van 1 uur die a.h.w. over mekaar geprojecteerd worden, en zou eventuele systematiek aan het licht moeten komen
Tijdens de 18-urige observatieperiode werden 9 volledige timeouts geteld, en een rist "gewone" vertragingen gaande van enkele tot 58 seconden.
In de periode van 0..18 minuten trad het fenomeen nooit op, dan vanaf 18..23 min. is er een plotse piek, dan wordt het vertragingspatroon langzaam minder dens.




Door de meetdata als tijdhistogram te presenteren wordt het patroon nog veel duidelijker. Op de y-as worden nu - voor elke periode van 1 minuut - het aantal keren geteld waar de responstijd groter was dan 10 seconden in die bepaalde minuut na het uur. (de grafiekhoofding vermeldt verkeerdelijk > 1 seconde)



Het is zonneklaar dat er op H+19 "iets" gebeurt dat de werking van het forum verstoort, na ~10 minuten langzaam quasi uitdooft, waarna alleen nog sporadische problemen optreden.

QED: Het fenomeen treedt niet random op, maar systematisch.

Ik geen flauw idee of de oorzaak te zoeken valt in de vBulletin software zelf, of algemeen in de server die (vermoed ik) niet dedicated is maar gedeeld wordt met mogelijk vele andere gebruikers.
Ik tip op het laatste: misschien kan OVH hier uitsluitsel geven?

[zonbron]

Nice! Netjes gepresenteerd.

Dat lijkt me het gevolg te zijn van een of andere scheduled task. Denk hourly backup/cleanup bvb. De database van dit forum is enorm, misschien zit het aan de grens van wat de serverzijde OVH kan aanbieden in de huidige configuratie. En dan krijgt men ook van die vervelende downtimes. Ik schat de omvang van de database op een 40-tal Gb, minstens...

Het is inderdaad tevens mogelijk dat een andere gebruiker op diezelfde server de problemen veroorzaakt. Feit is dat er op die server elk uur een sceduled task loopt waarvoor er om een of andere reden niet voldoende resources bestaan.

Als de forumsofware van dit forum op dat tijdstip zelf geen scheduled task uitvoert dan zit de oorzaak bij een andere gebruiker van die server of de server zelf.

[Rudy]

Oorspronkelijk geplaatst door Wapper

Regelmatige deelnemers aan het forum weten dat het forum bij momenten traag is, en dat foutmeldingen optreden: vertragingen van tientallen seconden en ultiem de Nginx gateway error 502/504.

Het viel me al lang op dat het fenomeen niet random optreedt maar op bepaalde momenten, op het eerste zicht ruwweg in de periode van 18..25 minuten na het uur. Om dat te onderzoeken schreef ik een eenvoudige applikatie die elke 30 sekonden een connectie maakt met het forum, het subforum K&K opvraagt, en de tijd meet tussen het verzenden van het HTTP-request en het ontvangen van de laatste lijn van deze pagina.

Indien na 1 minuut geen antwoord wordt ontvangen dan telt de applikatie uit, en noteert 60.000 als meetwaarde. De applikatie heeft totnogtoe 18,5 uur continue gelopen, en 2200+ meetresultaten verzameld.

Bijlage 101749

De resultaten worden gepresenteerd met de tijd modulo 60 minuten op de x-as, en de vastgestelde responstijden (in millisekonden) op de y-as.
Op deze wijze wordt de "tijdsfilm" opgedeeld in blokken van 1 uur die a.h.w. over mekaar geprojecteerd worden, en zou eventuele systematiek aan het licht moeten komen
Tijdens de 18-urige observatieperiode werden 9 volledige timeouts geteld, en een rist "gewone" vertragingen gaande van enkele tot 58 seconden.
In de periode van 0..18 minuten trad het fenomeen nooit op, dan vanaf 18..23 min. is er een plotse piek, dan wordt het vertragingspatroon langzaam minder dens.

Bijlage 101750


Door de meetdata als tijdhistogram te presenteren wordt het patroon nog veel duidelijker. Op de y-as worden nu - voor elke periode van 1 minuut - het aantal keren geteld waar de responstijd groter was dan 10 seconden in die bepaalde minuut na het uur. (de grafiekhoofding vermeldt verkeerdelijk > 1 seconde)

Bijlage 101751

Het is zonneklaar dat er op H+19 "iets" gebeurt dat de werking van het forum verstoort, na ~10 minuten langzaam quasi uitdooft, waarna alleen nog sporadische problemen optreden.

QED: Het fenomeen treedt niet random op, maar systematisch.

Ik geen flauw idee of de oorzaak te zoeken valt in de vBulletin software zelf, of algemeen in de server die (vermoed ik) niet dedicated is maar gedeeld wordt met mogelijk vele andere gebruikers.
Ik tip op het laatste: misschien kan OVH hier uitsluitsel geven?

Het zou kunnen dat op H+19, juist na het laatste maaltijd van de dag, het gros van de populatie nog vlug een woordje wilt placeren.

Echter, het fenomeen doet zich op elk willekeurig moment van de dag voor. Meer zelfs, het doet zich vooral voor als je meerdere postings wilt plaatsen. De eerste wordt gepost zonder problemen. Nadien moet je wat geduld uitoefenen.

Je schrijft je posting dus best eerst in een tekstverwerker, word of co. Met alle begrip voor wie schrijft in het tekstvak van dit forum.

Het probleem zit hem bij de server van politics. Of die moet eens worden opgekuist, of in het slechtste geval vervangen.

[zonbron]

Oorspronkelijk geplaatst door Rudy

Het zou kunnen dat op H+19, juist na het laatste maaltijd van de dag, het gros van de populatie nog vlug een woordje wilt placeren.

Echter, het fenomeen doet zich op elk willekeurig moment van de dag voor. Meer zelfs, het doet zich vooral voor als je meerdere postings wilt plaatsen. De eerste wordt gepost zonder problemen. Nadien moet je wat geduld uitoefenen.

Je schrijft je posting dus best eerst in een tekstverwerker, word of co. Met alle begrip voor wie schrijft in het tekstvak van dit forum.

Het probleem zit hem bij de server van politics. Of die moet eens worden opgekuist, of in het slechtste geval vervangen.

De info van @Wapper klopt. Double checked. Elk uur +19min is het gegarandeerd prijs. Dan krijgt men een downtime die dan langzaam verdwijnt naargelang de resources terug vrijkomen. Op uur +19 doet er zich een serveroverload voor. Mijn 2 cent.

Als men het nog niet geprobeerd heeft kan men een repair en defragmentatie van de database uitvoeren, dit indien uur+19min overeenkomt met de hourly backup/cleanup van de forumsoftware. Een mooi startpunt. Teveel fragmentatie en fouten in de db kan problemen geven tijdens die scheduled jobs. Met overload en downtime als gevolg. Bon. Mijn 2 cent. Forumsoftware en SQL zijn mijn ding niet.

[Wapper]

Oorspronkelijk geplaatst door Rudy

Het zou kunnen dat op H+19, juist na het laatste maaltijd van de dag, het gros van de populatie nog vlug een woordje wilt placeren..

En dat nagenoeg elk uur, en de klok rond?
Tracht eerst eens te snappen wat H+19 betekent, en "tijd modulo 60 min".

Echter, het fenomeen doet zich op elk willekeurig moment van de dag voor. Meer zelfs, het doet zich vooral voor als je meerdere postings wilt plaatsen. De eerste wordt gepost zonder problemen. Nadien moet je wat geduld uitoefenen.

Nee, dat doet het net niet, er zit systeem in, zoals in de OP wordt aangetoond. Het is mogelijk,maar niet heel waarschijnlijk, dat het posten van een bericht een andere invloed ondervindt dan gewoon lezen.
Ik zou dat kunnen testen, maar ik kan hier bezwaarlijk een draad volspammen met testberichten elke 30 seconden...

Je schrijft je posting dus best eerst in een tekstverwerker, word of co. Met alle begrip voor wie schrijft in het tekstvak van dit forum.

Geef mij maar <ctrl A <ctrl>C

Het probleem zit hem bij de server van politics.

<Duh>

Of die moet eens worden opgekuist, of in het slechtste geval vervangen.

OVH heeft wereldwijd ~250.000 fysische servers en een veelvoud daarvan aan virtuele servers. Dat zijn echt geen kleine jongens...

[Rudy]

Oorspronkelijk geplaatst door zonbron

De info van @Wapper klopt. Double checked. Elk uur +19min is het gegarandeerd prijs. Dan krijgt men een downtime die dan langzaam verdwijnt naargelang de resources terug vrijkomen. Op uur +19 doet er zich een serveroverload voor. Mijn 2 cent.

Als men het nog niet geprobeerd heeft kan men een repair en defragmentatie van de database uitvoeren, dit indien uur+19min overeenkomt met de hourly backup/cleanup van de forumsoftware. Een mooi startpunt. Teveel fragmentatie en fouten in de db kan problemen geven tijdens die scheduled jobs. Met overload en downtime als gevolg. Bon. Mijn 2 cent. Forumsoftware en SQL zijn mijn ding niet.

Dus, als ik je goed begrijp probeer je best niet te posten om 19 na het uur. Of toch niet binnen de eerste minuten daarna.

[Eduard Khil]

aha, straks eens proberen op dat exacte moment

[zonbron]

Oorspronkelijk geplaatst door Rudy

Dus, als ik je goed begrijp probeer je best niet te posten om 19 na het uur. Of toch niet binnen de eerste minuten daarna.

Klopt. Ik heb wel de indruk dat het soms snel opgelost is en dan kan het weer eens verdomd lang duren. Ik merk zojuist op dat U op 19min zonder problemen hebt kunnen posten. Vermijdt U vooral het posten op exact 19min en 0 seconden.

[Rudy]

Oorspronkelijk geplaatst door zonbron

Klopt. Ik heb wel de indruk dat het soms snel opgelost is en dan kan het weer eens verdomd lang duren. Ik merk zojuist op dat U op 19min zonder problemen hebt kunnen posten. Vermijdt U vooral het posten op exact 19min en 0 seconden.

Je bespioneert mensen ...

[Rudy]

Oorspronkelijk geplaatst door zonbron

Forumsoftware en SQL zijn mijn ding niet.

Wat is er mis met SQL ?

[Xenophon]

Oorspronkelijk geplaatst door Wapper

Regelmatige deelnemers aan het forum weten dat het forum bij momenten traag is, en dat foutmeldingen optreden: vertragingen van tientallen seconden en ultiem de Nginx gateway error 502/504.

Het viel me al lang op dat het fenomeen niet random optreedt maar op bepaalde momenten, op het eerste zicht ruwweg in de periode van 18..25 minuten na het uur. Om dat te onderzoeken schreef ik een eenvoudige applikatie die elke 30 sekonden een connectie maakt met het forum, het subforum K&K opvraagt, en de tijd meet tussen het verzenden van het HTTP-request en het ontvangen van de laatste lijn van deze pagina.

Indien na 1 minuut geen antwoord wordt ontvangen dan telt de applikatie uit, en noteert 60.000 als meetwaarde. De applikatie heeft totnogtoe 18,5 uur continue gelopen, en 2200+ meetresultaten verzameld.

Bijlage 101749

De resultaten worden gepresenteerd met de tijd modulo 60 minuten op de x-as, en de vastgestelde responstijden (in millisekonden) op de y-as.
Op deze wijze wordt de "tijdsfilm" opgedeeld in blokken van 1 uur die a.h.w. over mekaar geprojecteerd worden, en zou eventuele systematiek aan het licht moeten komen
Tijdens de 18-urige observatieperiode werden 9 volledige timeouts geteld, en een rist "gewone" vertragingen gaande van enkele tot 58 seconden.
In de periode van 0..18 minuten trad het fenomeen nooit op, dan vanaf 18..23 min. is er een plotse piek, dan wordt het vertragingspatroon langzaam minder dens.

Bijlage 101750


Door de meetdata als tijdhistogram te presenteren wordt het patroon nog veel duidelijker. Op de y-as worden nu - voor elke periode van 1 minuut - het aantal keren geteld waar de responstijd groter was dan 10 seconden in die bepaalde minuut na het uur. (de grafiekhoofding vermeldt verkeerdelijk > 1 seconde)

Bijlage 101751

Het is zonneklaar dat er op H+19 "iets" gebeurt dat de werking van het forum verstoort, na ~10 minuten langzaam quasi uitdooft, waarna alleen nog sporadische problemen optreden.

QED: Het fenomeen treedt niet random op, maar systematisch.

Ik geen flauw idee of de oorzaak te zoeken valt in de vBulletin software zelf, of algemeen in de server die (vermoed ik) niet dedicated is maar gedeeld wordt met mogelijk vele andere gebruikers.
Ik tip op het laatste: misschien kan OVH hier uitsluitsel geven?

Goed werk.

Echter, parels voor de zwijnen, je gelooft toch niet dat de eigenaar of eigenaars van het forum er iets aan gaan doen?

[Wapper]

Oorspronkelijk geplaatst door Xenophon

Goed werk.

Echter, parels voor de zwijnen, je gelooft toch niet dat de eigenaar of eigenaars van het forum er iets aan gaan doen?

Het is mogelijk dat zij er gewoonweg niets aan kunnen/mogen doen: ook bij het afhuren van serverruimte heeft alles zijn prijs, met bijbehorende prijs/kwaliteitsverhouding, technische mogelijkheden en beperkingen.
Uiteindelijk is de toegang hier gratis, maar het zou wel duidelijkheid scheppen moest men hier ook eens toelichten dat er beperkingen zijn die we in koop moeten nemen.

[zonbron]

Oorspronkelijk geplaatst door Rudy

Wat is er mis met SQL ?

Helemaal niets, dat loopt als een zonnetje.

[Rudy]

Oorspronkelijk geplaatst door zonbron

Helemaal niets, dat loopt als een zonnetje.

tx. ik maakte mij al ongerust.

[Eduard Khil]

het lijkt te kloppen. daarnet idd een time out

[Eyjafjallajökull]

Lijkt inderdaad te kloppen.

Knap werk, Wapper !

[Xenophon]

We hebben dus een deeltijds forum.

Wat gaan ze nu nog allemaal uitvinden?

[Wapper]

3500 metingen later, verspreid over dag/nacht.
De symptomen blijven glashelder, wel blijkt er voor responstijden > 1 seconde reeds vanaf H+13..14 een eerste aanzet te zijn tot het timeout probleem om H+19. Ook de trage afbouw van H+20 tot H+30 is mooi te zien. Daarna alleen nog enkele sporadische "accidents de parcours".

[Knuppel]

Oorspronkelijk geplaatst door Wapper

Het is mogelijk dat zij er gewoonweg niets aan kunnen/mogen doen: ook bij het afhuren van serverruimte heeft alles zijn prijs, met bijbehorende prijs/kwaliteitsverhouding, technische mogelijkheden en beperkingen.
Uiteindelijk is de toegang hier gratis, maar het zou wel duidelijkheid scheppen moest men hier ook eens toelichten dat er beperkingen zijn die we in koop moeten nemen.

D�*�*r zal het probleem wel zitten.
En daarom wordt er ook niets aan gedaan.

[Wapper]

Oorspronkelijk geplaatst door Knuppel

D�*�*r zal het probleem wel zitten.
En daarom wordt er ook niets aan gedaan.

Ik heb het eens nagekeken bij OVH.

-Voor een dedicated rackserver gaat het van 69 tot 179 US$/maand, afhankelijk van de gekozen hardware (Intel Xeon, 32..256 MB RAM, tot 2 x 2 TB HD, prima gerief)

-Voor een Virtual Private Server (gedeeld dus) gaat het van 3.49 tot 13.49 US$/maand.

Voor beide gevallen nog een bijkomende kost per benodigd IP van enkele dollar.