GoT [s]gruwelijk[/s] traag

[Verwijderd]

Al dagenlang is GoT echt supertraag...
En nu is het helemaal erg, 2 minuten wachten op 1 pagina

Dat het niet aan mijn verbinding ligt weet ik wel zeker, aangezien ik met geen enkele andere site problemen heb, alleen GoT en fok!

Dus... wat is er aan de hand

[wildhagen]

Hier sluit ik me helemaal bij aan... hier met ISDN duurt het soms rustig 35-40 seconden voor er één pagina binnenkomt. En dan heb ik nog de optie "Javascript gebruiken" aangezet, zonder die optie duurt het rustig een minuut. Met 155 Mbit (Surfnet) duurt het wat korter, een seconde of 20-25 per pagina.

Het begint inmiddels gewoonweg onwerkbaar te worden, het lijkt erop dat de servers 100 procent overbelast zijn. Word er al weer aan een upgrade gewerkt?

[Saekerhett]

Inderdaad, net lag FOK! en Tweakers.net er ook al uit, zal wel aan de gemeenschappelijke server liggen (weet niet hoe die heet).

[wildhagen]

Saekerhett schreef op 25 augustus 2002 @ 18:45:
Inderdaad, net lag FOK! en Tweakers.net er ook al uit, zal wel aan de gemeenschappelijke server liggen (weet niet hoe die heet).

Ja, oké, maar dat kan natuurlijk gewoon een incidenteel probleem zijn.

Waar topicstarter het over heeft (en waar ik het mee eens ben) duurt al een hele week lang ongeveer, en het word zelfs steeds erger (steeds trager dus).

[jwbagger]

loadbalancer problemen, was eerder al de conclusie...

[Kees]

de loadbalancer doet toch niet helemaal zoals wij willen dat hij zou doen. Hij heeft het nare trekje om een server die al teveel load heeft rustig op te schepen met de rest van de site, hierdoor is atlas net over zijn bakkes gegaan, en kregen we een sneeuwbal effect.

[T. van Beek]

Dus nu draait het weer beter!
Kees: Misschien load balancers terug sturen?

[wildhagen]

Kees schreef op 25 augustus 2002 @ 19:18:
de loadbalancer doet toch niet helemaal zoals wij willen dat hij zou doen. Hij heeft het nare trekje om een server die al teveel load heeft rustig op te schepen met de rest van de site, hierdoor is atlas net over zijn bakkes gegaan, en kregen we een sneeuwbal effect.

Aha, op die manier. Nou ja, nu heb je ze d'r tussenuit gehaald neem ik aan? Wat gebeurt er nu mee, terug naar de leverancier?

[intoxicated]

Is 't een nieuwe loadbalancer? Want 'k kan me herinneren dat ik bij traces 'vroeger' nooit loadbalancer-got.tweakers.net zag staan. Wat voor specs verder ei'k?

[Wouter Tinus]

Nee, is geen nieuwe, worden al een paar weken gebruikt.

[Femme]

Het is een One4net B-100: http://www.one4net.de/ . De hardware is gebaseerd op een IBM 1U serverdoos met PIII-1000 proc.

[The Bad Seed]

intoxicated schreef op 25 augustus 2002 @ 19:26:
Is 't een nieuwe loadbalancer? Want 'k kan me herinneren dat ik bij traces 'vroeger' nooit loadbalancer-got.tweakers.net zag staan. Wat voor specs verder ei'k?

reviews: Loadbalancing bij Tweakers.net
reviews: Tweakers.net serverpark

[Verwijderd]

Kees schreef op 25 augustus 2002 @ 19:18:
de loadbalancer doet toch niet helemaal zoals wij willen dat hij zou doen. Hij heeft het nare trekje om een server die al teveel load heeft rustig op te schepen met de rest van de site, hierdoor is atlas net over zijn bakkes gegaan, en kregen we een sneeuwbal effect.

GoT, voor al uw stress-testen

[intoxicated]

Duracell schreef op 25 augustus 2002 @ 19:29:
reviews: Loadbalancing bij Tweakers.net
reviews: Tweakers.net serverpark

Thnx, dat artikel had ik destijds blijkbaar gemist

[Osiris]

Hadden jullie de balancers niet ooit eens geprobeerd en getest dan???

Want misschien kunnen ze er ff beter tussenuit ofzow totdat ze het beter doen

[Femme]

Die loadbalancers staan al een half jaar in ons rack en zijn een maand op een deel van de site getest voordat ze heel t.net gingen doen.

De traagheid is volgens mij eerder het gevolg van NFS filesharing.

[Osiris]

Femme schreef op 25 augustus 2002 @ 19:37:
Die loadbalancers staan al een half jaar in ons rack en zijn een maand op een deel van de site getest voordat ze heel t.net gingen doen.

De traagheid is volgens mij eerder het gevolg van NFS filesharing.

* Osiris start google

Ff kijken wat dat NFS filesharing wel niet mag wezen

[wildhagen]

Osiris schreef op 25 augustus 2002 @ 19:42:
[...]

Ff kijken wat dat NFS filesharing wel niet mag wezen

Gokje: filesharing op een NFS-systeem? Klinkt logisch, ik weet het (NFS is dus Network File System).

[Daniel]

Het idee van het NFS systeem is dat alle webservers de files van een centrale server (Atlas in dit geval) halen. Dat gaat goed totdat Atlas teveel load krijgt en de failover niet werkt (dus een andere server neemt de taak van Atlas over als die het te druk heeft). Op dat moment wachten de andere servers op hun data waardoor ze ook een hoge load krijgen. Dan flikkert alles als een kaartenhuis in elkaar, omdat alle servers staan te wachten totdat ze verder kunnen.
Voeg daaraan toe dat, zoals Kees zegt, de loadbalancers de neiging hebben om een server die het al extreem druk heeft nog zwaarder te belasten en je komt in de situatie zoals we die daarnet hadden.

Hardwarecapaciteit is er voldoende, en op korte termijn zal die nog eens fors uitgebreid worden.

[twixx]

Daniel schreef op 25 augustus 2002 @ 20:39:
Het idee van het NFS systeem is dat alle webservers de files van een centrale server (Atlas in dit geval) halen. Dat gaat goed totdat Atlas teveel load krijgt en de failover niet werkt (dus een andere server neemt de taak van Atlas over als die het te druk heeft). Op dat moment wachten de andere servers op hun data waardoor ze ook een hoge load krijgen.

Dus als je Atlas geen httpd taken geeft (en/of andere taken dan NFS) heb je dat effect niet? Een dedicated-NFS-doos? Wellicht is het handiger om cron ieder uur de php vanaf de NFS doos naar localhost (IDE disk) te kopieren?

[kamerplant]

Hoelang zal dit gezeur eigenlijk nog duren schatten jullie?

[Floor-is]

Hopelijk wordt er vrijdag op zaterdag a.s. verbouwd, gerenoveerd, geupgrade en werkt het daarna weer allemaal als een zonnetje

[_MaLa_]

ik vind het na react update dat het langer duurt id..


vind er hardware update plaats ?

[twixx]

Floris schreef op 25 augustus 2002 @ 21:53:
Hopelijk wordt er vrijdag op zaterdag a.s. verbouwd, gerenoveerd, geupgrade en werkt het daarna weer allemaal als een zonnetje

Dat zal wel hardware zijn en kabel-dingetjes. Maar is er een .plan kwa software? Atlas blijkt toch wel een zeer belangrijke single-server.

[Pc123]

Vooral GoT is idd al sinds het afschaffen van Topix heel erg traag, heeft React er niks mee te maken en zijn het alleen de loadbalancer + NFS of werkt het forum zelf ook nog niet helemaal goed?

[Verwijderd]

Ligt het nu aan de forum software of aan de gebruikte hardware.

Want ik (en andere neem ik aan ook) heb de laatste tijd veel errors.
Klik je een topic aan, krijg je gelijk een 404.
Ook de FP trouwens, maar dit zijn meer script errors.

Ligt dit aan de hw of sw ?

Dit is voor mij ff moeilijk in te schatten, omdat die loadbalancers, ter gelijkertijd met de nieuwe forumsoftware zijn geplaats.

[Onno]

Daniel schreef op 25 augustus 2002 @ 20:39:
Het idee van het NFS systeem is dat alle webservers de files van een centrale server (Atlas in dit geval) halen. Dat gaat goed totdat Atlas teveel load krijgt en de failover niet werkt (dus een andere server neemt de taak van Atlas over als die het te druk heeft).

Waarom moet dan ook alles op een centrale server staan? Scripts enz. lokaal mirroren op elke webserver klinkt mij wat logischer in de oren in dit geval eigenlijk.. (hetzij via een distributed filesystem , hetzij via een mirrorsysteem dat bovenop een normaal filesystem geimplementeerd is)

(hoge loads op clients bij een falende NFS server is meestal trouwens heel aardig te voorkomen met wat gepruts met NFS settings)

Hardwarecapaciteit is er voldoende, en op korte termijn zal die nog eens fors uitgebreid worden.

Als de hardwarecapaciteit voldoende is, wat gaat dat dan oplossen?

[JvS]

[nohtml]

Verwijderd schreef op 25 augustus 2002 @ 22:35:
Ligt het nu aan de forum software of aan de gebruikte hardware.

Het ligt aan de hardwareconfiguratie, zoals je kan lezen. Het nieuwe forum is inderdaad wat zwaarder, maar de hoeveelheid hardware is dus voldoende. De loadbalencer doet geloof ik gek (info uit dit draadje overigens )

[Daniel]

Onno schreef op 25 augustus 2002 @ 23:34:
[...]

Waarom moet dan ook alles op een centrale server staan? Scripts enz. lokaal mirroren op elke webserver klinkt mij wat logischer in de oren in dit geval eigenlijk.. (hetzij via een distributed filesystem , hetzij via een mirrorsysteem dat bovenop een normaal filesystem geimplementeerd is)
(hoge loads op clients bij een falende NFS server is meestal trouwens heel aardig te voorkomen met wat gepruts met NFS settings)

Nu ga je vragen stellen die Kees beter kan beantwoorden denk ik

Als de hardwarecapaciteit voldoende is, wat gaat dat dan oplossen?

Ik zeg nergens dat we verwachten dat die uitbreiding DE oplossing zal zijn voor de huidige performance-problemen. Maar in het verleden hebben we zo vaak het verwijt gekregen dat we pas power gingen toevoegen op het moment dat het eigenlijk al te laat was dat het ons nu wel eens een goed idee leek om voorbereid te zijn voor toekomstige ontwikkelingen

[JvS]

Dat het nu dus bloedjesnel is
*zoekt ongelakt stuk hout op*

[Verwijderd]

*Kijkt naar de tijd*
01:35....zou dat er iets mee te maken hebben

Vanmiddag was het namelijk bij lange na niet zo snel

Overigens kan ik niet anders zeggen dan dat ik het helemaal eens ben met Onno's post

[Femme]

Scripts enz. lokaal mirroren op elke webserver klinkt mij wat logischer in de oren in dit geval eigenlijk..

Dat is nu ook het plan (scripts en statische images lokaal en automatisch synchen).

Binnenkort gaan we een lang geplande megaupgrade uitvoeren. Die upgrade staat los van de problemen van de laatste weken.

[Coen Rosdorff]

Tijd om rsync eens van de plak te pakken.
Dat is DE tool voor dat doel.

Als webservers data moeten schrijven kan je daar nfs voor gebruiken. Daarna kan je de data met rsync naar alle andere webservers copy'en.

[Verwijderd]

little_soundman schreef op 27 augustus 2002 @ 01:57:
Tijd om rsync eens van de plak te pakken.
Dat is DE tool voor dat doel.

Als webservers data moeten schrijven kan je daar nfs voor gebruiken. Daarna kan je de data met rsync naar alle andere webservers copy'en.

Daar is men echt wel van op de hoogte

Maar thx voor het advies

[.oisyn]

Verwijderd schreef op 27 augustus 2002 @ 02:33:
Daar is men echt wel van op de hoogte

zou het?

[silentsnow]

Tis idd wat traag, maar 10 sec wachten vind ik niet erg.

(Ben ex-56Ker)

[Arnout]

Hmmz 't wordt weer traaaaag...

[Ankh]

soms ligt het er ook helemaal uit en krijg soms een dns error.. heel errug kewl

* Rammstein zwijmelt weg naar die goeie oude tijd

[Flake]

/me heeft ook snelheidproblemen

[Wokschotel]

Nu ziet het er helemaal niet meer uit. Nouja, lekker minimalistisch kleurgebruik zullen we het maar noemen

[Laurent]

Hier lijkt Atlas nu helemaal onberijkbaar te zijn

[fetcher]

ik mis inderdaad wat plaatjes en wat stylesheets

[_MaLa_]

gewoon plat net

[chem]

jaaaa allemaal roepen dat het langzaam is!

[RedHat]

Dan maar hopen dat het opgelost is met de nieuwe updates, maar hey! Eigenlijks mogen we niet zeuren, want tweakers.net levert ons zoveel, tegen no-price. Ok, we betalen wel een beetje (bannerviews e.d.), maar dat zijn EXTERNE inkomsten.

[Verwijderd]

gvd wat is het traag

[fetcher]

chem schreef op 27 augustus 2002 @ 14:34:
jaaaa allemaal roepen dat het langzaam is!

Weet jij een betere omschrijving?

[RedHat]

Verwijderd schreef op 27 augustus 2002 @ 14:37:
gvd wat is het traag

doe n's normaal

[Erkens]

chem schreef op 27 augustus 2002 @ 14:34:
jaaaa allemaal roepen dat het langzaam is!

_{ehh... het is langzaam}

[ACM]

Onno schreef op 25 augustus 2002 @ 23:34:
(hetzij via een distributed filesystem )

Weet jij een distributed filesystem dat stabiel is, dat niet een ingelogde gebruiker nodig heeft en dat een hoge load aan kan?

Kees en ik hebben dat nog niet echt kunnen vinden, intermezzo viel af (niet bijster stabiel), coda (moet je voor ingelogd zijn) en openafs was het ook niet geloof ik.

Vandaar dat Kees maar teruggegaan is naar nfs met een extra fileserver om het allemaal minder erg te maken.

(hoge loads op clients bij een falende NFS server is meestal trouwens heel aardig te voorkomen met wat gepruts met NFS settings)

Door ze oa een korte soft-timeout te geven ipv een lange hardtimeout zeker?
Staat al ingesteld. NFS is gewoon niet bedoeld om om te kunnen gaan met een dode fileserver

[ACM]

RedHat schreef op 27 augustus 2002 @ 14:37:
doe n's normaal

Michel staat waarsch met een brede grijns over chem's schouder mee te kijken

[Verwijderd]

Load van achelois is ook aan de hoge kant BTW. Ik heb er nu last van dat de CSS niet mee laad met GoT.

[Verwijderd]

Grijns

[Compubiter]

ACM schreef op 27 augustus 2002 @ 14:42:

[...]

Michel staat waarsch met een brede grijns over chem's schouder mee te kijken

Dan had hij er wmb best een smiley achter kunnen plaatsen, want ik vond het ook niet zo "vriendelijk" overkomen ofzo. Niet dat ik me er iets van aantrek (tien minuten geen GoT is tien minuten langer m'n kamer opruimen), maar je lokt natuurlijk wel bepaalde reacties uit .

Verwijderd schreef op 27 augustus 2002 @ 14:43:
Grijns

[RedHat]

ACM schreef op 27 augustus 2002 @ 14:42:

[...]

Michel staat waarsch met een brede grijns over chem's schouder mee te kijken

Ik dacht al bij mezelf, is dit vriendjespolitiek ofzo
Als ik dat had gedaan had ACM snel de banknop ingedrukt

Nog eentje

code:

whoeaaa
   |
   |
   |
   \/

[_MaLa_]

Verwijderd schreef op 27 augustus 2002 @ 14:37:
gvd wat is het traag

heheh doe er eens wat aan ! nieuw

[SH007]

_MaLa_ schreef op 27 augustus 2002 @ 14:45:
[...]


heheh doe er eens wat aan ! nieuw

Door Michel (Parse Führer)

dat zegt genoeg

[Verwijderd]

Was er al gezegd dat het net traag was?

[rb338]

Ben ik dan de enige waar GoT pagina's gewoon binnen 2 sec op 't scherm staan

Ook pings gaan prima:

code:

rb338@debian:~$ ping gathering.tweakers.net
PING loadbalancer-got.tweakers.net (213.239.154.36): 56 data bytes
64 bytes from 213.239.154.36: icmp_seq=0 ttl=250 time=65.3 ms
64 bytes from 213.239.154.36: icmp_seq=1 ttl=250 time=66.1 ms
64 bytes from 213.239.154.36: icmp_seq=2 ttl=250 time=93.8 ms

--- loadbalancer-got.tweakers.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 65.3/75.0/93.8 ms

[edit]
Eej, waarom zit er tussen elke code regel een extra regel

[Laurent]

rb338 schreef op 27 augustus 2002 @ 14:52:
Ben ik dan de enige waar GoT pagina's gewoon binnen 2 sec op 't scherm staan

Ook pings gaan prima:

code:

rb338@debian:~$ ping gathering.tweakers.net
PING loadbalancer-got.tweakers.net (213.239.154.36): 56 data bytes
64 bytes from 213.239.154.36: icmp_seq=0 ttl=250 time=65.3 ms
64 bytes from 213.239.154.36: icmp_seq=1 ttl=250 time=66.1 ms
64 bytes from 213.239.154.36: icmp_seq=2 ttl=250 time=93.8 ms

--- loadbalancer-got.tweakers.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 65.3/75.0/93.8 ms

[edit]
Eej, waarom zit er tussen elke code regel een extra regel

Blijkbaar

maar pings zeggen niet alles hoor, bij mij:
Reply from 213.239.154.36: bytes=32 time=10ms TTL=247
en GoT gaat hier ook erg traag.

[rb338]

Hmm ja vreemd.
Ik heb goeie pings, ook als ik 'm langer laat lopen...
5% packet loss, maar wel acceptabele snelheden

En tja... ik krijg alles gewoon snel op m'n scherm bij 80% van de pagina's die ik laad.
Soms duurt het 1 sec langer, maar wat ik hier lees (40 seconden, 2 minuten) heb ik nog niet meegemaakt

[edit]
ACM heeft natuurlijk gelijk...
Sorry, ben net wakker

[ACM]

Lekker zinvol om de loadbalancers te gaan pingen...

[Verwijderd]

ACM schreef op 27 augustus 2002 @ 14:40:
[nohtml]
[...]
Weet jij een distributed filesystem dat stabiel is, dat niet een ingelogde gebruiker nodig heeft en dat een hoge load aan kan?
Kees en ik hebben dat nog niet echt kunnen vinden, intermezzo viel af (niet bijster stabiel), coda (moet je voor ingelogd zijn) en openafs was het ook niet geloof ik.
Vandaar dat Kees maar teruggegaan is naar nfs met een extra fileserver om het allemaal minder erg te maken.

Waar heb je in vredesnaam een distributed filesystem voor nodig? Dit is internet, of een plaatje nu wel of niet van dezelfde server afkomt boeit niet. Als je dus pages wilt serven van server A, plaatjes van server B en scripts van server C, dan maak je dat toch kenbaar via URLs in de HTML? Waarom zo moeilijk doen met een distributed filesystem?

[edit]
Immers: de browser zelf, start per externe gerefereerde file (image, stylesheet) een aparte connectie op, dus of dat nu vanaf dezelfde webserver komt of vanaf een andere webserver is totaal niet interessant.

[Erkens]

Verwijderd schreef op 27 augustus 2002 @ 16:32:
[...]

Waar heb je in vredesnaam een distributed filesystem voor nodig? Dit is internet, of een plaatje nu wel of niet van dezelfde server afkomt boeit niet. Als je dus pages wilt serven van server A, plaatjes van server B en scripts van server C, dan maak je dat toch kenbaar via URLs in de HTML? Waarom zo moeilijk doen met een distributed filesystem?

[edit]
Immers: de browser zelf, start per externe gerefereerde file (image, stylesheet) een aparte connectie op, dus of dat nu vanaf dezelfde webserver komt of vanaf een andere webserver is totaal niet interessant.

en de included files van php

[.oisyn]

Verwijderd schreef op 27 augustus 2002 @ 16:32:
[...]

Waar heb je in vredesnaam een distributed filesystem voor nodig? Dit is internet, of een plaatje nu wel of niet van dezelfde server afkomt boeit niet. Als je dus pages wilt serven van server A, plaatjes van server B en scripts van server C, dan maak je dat toch kenbaar via URLs in de HTML? Waarom zo moeilijk doen met een distributed filesystem?

[edit]
Immers: de browser zelf, start per externe gerefereerde file (image, stylesheet) een aparte connectie op, dus of dat nu vanaf dezelfde webserver komt of vanaf een andere webserver is totaal niet interessant.

ja en wat voor nut hebben loadbalancers dan nog? Lijkt me niet echt handig balancen, puur op de content

[Wokschotel]

Ik ga m'n geld terugvragen Waaaaardeloos, dat GoT

[Verwijderd]

Wokschotel schreef op 27 augustus 2002 @ 16:50:
Ik ga m'n geld terugvragen Waaaaardeloos, dat GoT

Okee, dat is dan € 100,- voor mijn onkosten

Otis: het is toch echt de bedoeling om de servers zo optimaal mogelijk te benutten om zodoende zo veel mogelijk snelheid te krijgen. Iets wat op het moment niet helemaal wil lukken lijkt het.

[IceStorm]

Zo, Wokschotel krijgt al zijn geld terug (waarbij gezegd moet worden dat tijd in dit geval geen geld is ).

[Osiris]

Aso hè, die Wokschotel...

Mag ik het dan misschien in natura trug hebben???

Verzin maar wat

[.oisyn]

Osiris: ja hoor, icestorm regelt dat wel even

[Verwijderd]

Wie heeft Daniels negers gezien?

[Wokschotel]

IceStorm schreef op 27 augustus 2002 @ 16:54:
Zo, Wokschotel krijgt al zijn geld terug (waarbij gezegd moet worden dat tijd in dit geval geen geld is ).

Mooi zo, dan vind ik jullie tenminste weer lief

Ik ben wel de laatste die gaat lopen zeuren als GoT traag draait. aan de adjes _{en modjes}

Zo, genoeg geslijmd dit jaar

[Coen Rosdorff]

Verwijderd schreef op 27 augustus 2002 @ 02:33:

[...]

Daar is men echt wel van op de hoogte

Maar thx voor het advies

Zou het ??

In de tijd dat elke server nog zijn eigen scripts had, en er nog wel eens verschil was tussen de servers, hebben meerdere mensen ook al aangeraden om rsync te gebruiken om content te synchroniseren.

[ACM]

Verwijderd schreef op 27 augustus 2002 @ 16:32:
Waar heb je in vredesnaam een distributed filesystem voor nodig?

Niet echt ergens voor, behalve dat het een handige manier is om je files over de verschillende servers te distribueren
En ik vroeg me gewoon af of Onno toevallig een dfs kende dat beter werkt dan de genen die kees getest heeft.

Dit is internet, of een plaatje nu wel of niet van dezelfde server afkomt boeit niet.

Klopt

Als je dus pages wilt serven van server A, plaatjes van server B en scripts van server C, dan maak je dat toch kenbaar via URLs in de HTML?

Klopt
Echter kost het nauwelijks werk om alle images te serveren voor 1 server, behalve dat je wilt dat ie altijd online is.
Vergeet alleen niet dat we in jouw idee maar 3 servers kunnen gebruiken, we hebben er zes voor t.net/got die we natuurlijk niet dan "nauwelijks werk" (images), "nauwelijks werk" (stylesheets/javascripts helemaal een lachtertje) "enorm veel werk" (php/scripts-files)

Kortom, we willen graag het zwaarste werk transparant verdelen over de servers, namelijk de executie van die scripts.
Nou kunnen we daar lang en kort over discussieren of die wel zo zwaar zouden moeten zijn, maar laten we voor het gemak aannemen dat dat zo is.
Dan wil je dus die scripts met zo min mogelijk moeite en zo min mogelijk single-point-of-failures over de servers verdelen.

Scheiden op een andere manier is ook niet echt handig, de php-scripts moeten op al die servers staan, net zoals de templatefiles.
Kortom al enkele honderden files, onderhevig aan enige verandering etc.
Die wil je dan niet 6x moeten ftp-en.

Waarom zo moeilijk doen met een distributed filesystem?

De bedoeling is juist dat het niet moeilijk is
Als dat wel moeilijk blijkt te zijn (wat het dus ook blijkt) zal het iets minder moeilijk gezocht moeten worden, bijvoorbeeld met rsync.

[edit]
Immers: de browser zelf, start per externe gerefereerde file (image, stylesheet) een aparte connectie op, dus of dat nu vanaf dezelfde webserver komt of vanaf een andere webserver is totaal niet interessant.

Ochja, dat wist ik al hoor
Enige waar het nog interessant is is de keep-alive gedoe.

[Verwijderd]

Ik moest mij vraag maar hier stellen, en niet in het Bugs forum.

Ik heb continu last van deze melding:



Aan mijn verbinding kan het niet liggen, die zit snor.
De ene keer laadt GoT erg snel, soms heb ik een 3 minuten vertraging, met bovenstaand beeld als resultaat. Refreshen etc. helpt dan geen ruk.
En zo spontaan als ik bovenstaande pagina krijg, zo spontaan is het ook weer bormaal.

En nu de hamvraag.... is dit normaal?

[ Voor 0% gewijzigd door Kees op 27-08-2002 20:05 ]

[SH007]

Verwijderd schreef op 27 augustus 2002 @ 19:40:
Ik moest mij vraag maar hier stellen, en niet in het Bugs forum.

Ik heb continu last van deze melding:

[afbeelding]

Aan mijn verbinding kan het niet liggen, die zit snor.
De ene keer laadt GoT erg snel, soms heb ik een 3 minuten vertraging, met bovenstaand beeld als resultaat. Refreshen etc. helpt dan geen ruk.
En zo spontaan als ik bovenstaande pagina krijg, zo spontaan is het ook weer bormaal.

En nu de hamvraag.... is dit normaal?

Als er problemen met de fileserver(s) zijn, is dit normaal.
Dan komen de javascriptjes, en de CSS niet aan, en dan ziet GoT er zo uit.

[Verwijderd]

ACM schreef op 27 augustus 2002 @ 17:48:
[nohtml]
[...]
Klopt
Echter kost het nauwelijks werk om alle images te serveren voor 1 server, behalve dat je wilt dat ie altijd online is.
Vergeet alleen niet dat we in jouw idee maar 3 servers kunnen gebruiken, we hebben er zes voor t.net/got die we natuurlijk niet dan "nauwelijks werk" (images), "nauwelijks werk" (stylesheets/javascripts helemaal een lachtertje) "enorm veel werk" (php/scripts-files)

Vroeg ik me ook al af, maar goed, het kwam ter sprake hier. A

Kortom, we willen graag het zwaarste werk transparant verdelen over de servers, namelijk de executie van die scripts.
Nou kunnen we daar lang en kort over discussieren of die wel zo zwaar zouden moeten zijn, maar laten we voor het gemak aannemen dat dat zo is.
Dan wil je dus die scripts met zo min mogelijk moeite en zo min mogelijk single-point-of-failures over de servers verdelen.

Dus: multiple webservers met allemaal alle scripts. Loadbalancer die of op user of op request loadbalanced tussen die webservers.

Als je dit al hebt, waarom is het dan toch traag?
Als je dit NIET hebt, waarom niet?

Ik vraag het me gewoon af hoor, want er wordt nu wel heel luchtig gedaan enzo en dat jullie alles al weten en al hebben uitgezocht, maar feit is wel dat het als stroop draait, en dat bv de startpage met alle fora static cached is, dus die moet *plop* op het scherm staan. Dat doetie niet, dus zit er ergens een bottleneck. Als dat een crappy loadbalancer is, dan installeer je toch morgen een nieuwe? (of bouw je er zelf een, op IPnr, op zich is dat weinig code) Als het het NFS is, dan gebruik je dat toch niet? Het is toch niet zo moeilijk om 1 centraal distributiepunt te kiezen en dmv scripts de spullen te distribueren over de redundant webservers in de farm? Zo werkt het nl. ALTIJD bij multiple webservers in een farm die gebalanced wordt door een loadbalancer.

Scheiden op een andere manier is ook niet echt handig, de php-scripts moeten op al die servers staan, net zoals de templatefiles.
Kortom al enkele honderden files, onderhevig aan enige verandering etc.
Die wil je dan niet 6x moeten ftp-en.

Ah, dus omdat iemand niet 6x wil ftp-en, gebruikt men een traag dfs?
Geen idee of Linux een feature kent dat NT 3.51 al had, nl. zodra een file in een directory wordt geplaatst of wordt gewijzigd, je een message krijgt die je kunt afvangen en dus erop kunt anticiperen (bv ftp-en naar 6 dozen).

[...]
[/nohtml]
Ochja, dat wist ik al hoor
Enige waar het nog interessant is is de keep-alive gedoe.

Hangt ervan af waar je de beste balancing van krijgt: op user of op request. Gezien de aard van jullie webapp, veel gets en weinig puts (in verhouding), lijkt het me nuttiger gewoon op request te balancen.

[Kees]

Verwijderd schreef op 27 augustus 2002 @ 20:21:
Dus: multiple webservers met allemaal alle scripts. Loadbalancer die of op user of op request loadbalanced tussen die webservers.

Als je dit al hebt, waarom is het dan toch traag?
Als je dit NIET hebt, waarom niet?

Ik vraag het me gewoon af hoor, want er wordt nu wel heel luchtig gedaan enzo en dat jullie alles al weten en al hebben uitgezocht, maar feit is wel dat het als stroop draait, en dat bv de startpage met alle fora static cached is, dus die moet *plop* op het scherm staan. Dat doetie niet, dus zit er ergens een bottleneck. Als dat een crappy loadbalancer is, dan installeer je toch morgen een nieuwe? (of bouw je er zelf een, op IPnr, op zich is dat weinig code) Als het het NFS is, dan gebruik je dat toch niet? Het is toch niet zo moeilijk om 1 centraal distributiepunt te kiezen en dmv scripts de spullen te distribueren over de redundant webservers in de farm? Zo werkt het nl. ALTIJD bij multiple webservers in een farm die gebalanced wordt door een loadbalancer.

Het is redelijk uitgebreid getest, Iris, argus en atlas hebben bijna 3 maanden vrijwel zonder problemen erop gedraait, alleen sinds de invoering van react (en op het moment dat react ook erop ging lopen) werd het ineens stukken zwaarder, uiteraard dachten we dat we een goede oplossing hadden, dit blijkt niet zo te zijn, en nu zoeken we dus (weer) naar varianten.

Ah, dus omdat iemand niet 6x wil ftp-en, gebruikt men een traag dfs?
Geen idee of Linux een feature kent dat NT 3.51 al had, nl. zodra een file in een directory wordt geplaatst of wordt gewijzigd, je een message krijgt die je kunt afvangen en dus erop kunt anticiperen (bv ftp-en naar 6 dozen).

Hmmjah, dat zit voor een heel klein deel in linux, en dan moet je kijken naar een patch alla intermezzo, het zit (voor zover ik weet) niet standaard in Linux, en als iemand me een dergelijk voorbeeld kan geven zou ik heel dankbaar zijn, want dan kan ik inderdaad wel zoiets schrijven (hetzij FTP, hetzij rsync, hetzij kopieren van de NFS). Het zijn namelijk niet alleen de scripts, maar per minuut komt er wel een usericoon / image bij, die moeten ook verspreid worden over de servers, al met al praten we toch over bijna 100.000 files in 30.000 dirs (okay, moet er nog in snoeien, aantal dingen staan er dubbel op, maar ga toch maar uit van ruim 60.000 files, voornamelijk images (stats images, pricewatch images, usericons etc) die dus ook regelmatig veranderen).

Hangt ervan af waar je de beste balancing van krijgt: op user of op request. Gezien de aard van jullie webapp, veel gets en weinig puts (in verhouding), lijkt het me nuttiger gewoon op request te balancen.

We balancen nu op connectie, gewoon TCP/IP balancing dus. De loadbalancers hebben helaas nog wel enkele tweaks nodig (en onze tweaks pakten ook niet helemaal goed uit, na overleg met brainforce hebben we vanmiddag weer een aantal zaken veranderd, hierdoor lijkt het nu beter te gaan met het verdelen van de werklast.

Ook ben ik vandaag wezen spelen met een aantal NFS opties waardoor het weer iets sneller zou moeten gaan. En tja, we blijven zoeken naar alternatieven

[Raymond]

chem schreef op 27 augustus 2002 @ 14:34:
jaaaa allemaal roepen dat het langzaam is!

Het is langzaam!! Doe er wat aan!

Ben je al bezig?

En nu dan?

En nu?



* Raymond is altijd bereid om te helpen met het opvolgen van bevelen

[Floor-is]

Ik had gisteren load-times van 20+ seconden, dus ja ook bij mij was het niet bepaald snel.

Nu echter is het wel redelijk snel:
Total: 0,587 | Incl: 0,052, Init: 0,077, Action: 0,481 | DB: 0,066, Tpl: 0,395 | SV: ares.webmagix.net

Is dat omdat het nog rustig is of is er iets veranderd?

[Arnout]

Floris schreef op 28 augustus 2002 @ 09:05:
Nu echter is het wel redelijk snel:
Total: 0,587 | Incl: 0,052, Init: 0,077, Action: 0,481 | DB: 0,066, Tpl: 0,395 | SV: ares.webmagix.net

Mwoah, zoeken op mijn eigen posts: Total: 7,897 | Incl: 3,656, Init: 1,985, Action: 2,264 | DB: 1,469, Tpl: 0,837 | SV: adonis.webmagix.net

't Misschien wel frustrerend voor de mensen die met dit probleem bezig zijn dat deze draad levend blijft... maar 't probleem blijft.

[Floor-is]

Sjah frusty voor die mensen of niet: voor iedereen die het forum gebruikt is het ook frustrerend, we willen allemaal GoT-ten, maar met een dergelijk trage opbouw is dat haast onmogelijk omdat je zo lang moet wachten. En het wekt ook een berg irritatie op.

[Arnout]

Hè 't lijkt ineens veel sneller, klik *pats*...

Is er wat veranderd?

[dominic]

Ja merk ook dat het sneller is maar dat was het gisterenmorgen volgens mij ook. Ik denk gewoon dat het niet zo druk is op dit moment.

[Arnout]

dominicbout schreef op 30 augustus 2002 @ 11:06:
Ja merk ook dat het sneller is maar dat was het gisterenmorgen volgens mij ook. Ik denk gewoon dat het niet zo druk is op dit moment.

Nou, 'k zit ook wel es om 6.20 online en dan is er vrijwel niemand online, het is nu zelfs sneller dan vanmorgen 6.20.

[Attilla]

Mja, het zit nu bijna weer op topix snelheid

[Attilla]

[Airwolf] schreef op 30 augustus 2002 @ 11:12:
Mja, het zit nu bijna weer op topix snelheid

Hmm, had ik het nou maar afgeklopt.

Het laden van een forumlijst (of hoe jullie dat noemen) gaat ok, maar zodra je een topic wil openen dan lijkt het net of hij nog even in de database moet graven en daarna opent hij pas.

[Ankh]

code:

Total: 0,204 | Incl: 0,03, Init: 0,035, Action: 0,144 | DB: 0,047, Tpl: 0,094 | SV: adonis.webmagix.net
Total: 2.149 | Incl: 0.913, Init: 0.68, Action: 0.577 | DB: 0.127, Tpl: 0.498 | SV: achelois.webmagix.net

zie het verschil 1ste is frontpage 2de is bookmarks

[raptorix]

Lijkt idd sneller te gaan, wat me opvalt is dat het nogal traag is als je op de reply button drukt.

[Pc123]

Het is al iets beter, maar topics openen en vooral replyen is nog steeds veel te traag, hopelijk helpt meer server capaciteit al iets en dan hoop ik ook maar dat de software oplossing snel gevonden wordt

[KroontjesPen]

Wanneer de tijden al geprint zijn duurt het vaak nog erg lang voordat de pagina er helemaal op staat.
Smilies worden vaak niet geladen, banners geven 404.

<sub>Info
-------------------------------------------------------------------
Total: 29.775 | Incl: 6.171, Init: 3.762, Action: 19.856 | DB: 0.166, Tpl: 19.799 | SV: achelois.webmagix.net

Total: 11,181 | Incl: 1,173, Init: 0,359, Action: 9,663 | DB: 0,095, Tpl: 9,53 | SV: ares.webmagix.net

........................................
en ff "Bekijk bericht"
Total: 20.49 | Incl: 5.354, Init: 3.834, Action: 11.311 | DB: 0.531, Tpl: 9.638 | SV: achelois.webmagix.net

Total: 30.581 | Incl: 3.485, Init: 4.439, Action: 22.595 | DB: 0.138, Tpl: 20.098 | SV: achelois.webmagix.net
..........................................
--------------------------------------------------------------------</sub>


Psst, [Airwolf].
Wel op blank hout afkloppen hè.

[mavink]

Kees schreef op 27 augustus 2002 @ 20:50:
[nohtml]
[...]
Hmmjah, dat zit voor een heel klein deel in linux, en dan moet je kijken naar een patch alla intermezzo, het zit (voor zover ik weet) niet standaard in Linux, en als iemand me een dergelijk voorbeeld kan geven zou ik heel dankbaar zijn, want dan kan ik inderdaad wel zoiets schrijven (hetzij FTP, hetzij rsync, hetzij kopieren van de NFS). Het zijn namelijk niet alleen de scripts, maar per minuut komt er wel een usericoon / image bij, die moeten ook verspreid worden over de servers, al met al praten we toch over bijna 100.000 files in 30.000 dirs (okay, moet er nog in snoeien, aantal dingen staan er dubbel op, maar ga toch maar uit van ruim 60.000 files, voornamelijk images (stats images, pricewatch images, usericons etc) die dus ook regelmatig veranderen).

Kees, kijk eens naar het coda filesystem.
Ik dacht dat jullie daar al eens eerder naar hadden gekeken, maar voor deze situatie is het ideaal. Je kunt een volume repliceren over meerdere servers; als een van de servers uitvalt zullen de clients daar niets van merken. Tevens heeft de client de mogelijkheid tot het aanleggen van een cache, zodat de fileservers ook nog eens minder belast worden. De documentatie is hier en daar wat karig, maar het werkt prima.

[Verwijderd]

even domme vraag tussendoor: hoe komen jullie aan die process tijden?

[Leon T]

Selecteer eens de tekst helemaal beneden aan?
Voila
(dus beneden version 1.6.5-4:1.7.1)

[Renegade]

Selecteer eens onderaan de pagina de tekst na het versie nummer

Of bedoelde je hoe de devvers daaraan kwamen?

[ripexx]

Deze data wordt door de parse devvers o.a. gebruikt om het forum te verbetern en te kijken waar er preformance verbeteringen noodzakelijk zijn, heb ergens eens gelezen dat de total beneden de 0,2 zou moeten zijn, maar dat is afhanekelijk van een aantal andere zaken.

[JvS]

damn:

Total: 0,188 | Incl: 0,022, Init: 0,078, Action: 0,131 | DB: 0,099, Tpl: 0,024

Beneden de 0,2 is inderdaad lekker rondsnorren . Ik kan me nu voorstellen hoe irritant forummen is, als je een gare verbinding met een ping van 300+ ofzo hebt .

Hoe kan het nou dat ik nu ineens midden op de dag 0,188 haal btw?

[ripexx]

Je hebt waarschijnlijk een server te pakken die zeer rustig zijn baantjes aan het trekken is. Die loadbalancers hebben volgens mij nog wat kleine aanpassingen nodig, al moet ik toegeven dat het steeds beter werkt, maar soms wil het echt niet vlotten. Keep up the good work!

[Verwijderd]

Tweakertje schreef op 30 augustus 2002 @ 17:10:
Selecteer eens de tekst helemaal beneden aan?
Voila
(dus beneden version 1.6.5-4:1.7.1)

Heee! Ja ik zie alleen een wit vlak, de snoodaards thnx

[DjGeRo]

Vanavond de big update, veel succes..
Die bugs zaten er heus ook wel in het begin van topix neem ik aan
Traag is die inderdaad:( , maar dat zal me een worst wezen
Maja ik zou alleen succes wensen met de update maar ik lul altijd teveel

Succes dus.