GoT [s]gruwelijk[/s] traag

[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.

[Leon]

Archelois voelt zich niet lekker...

Achelois 2 days, 6:20, load average: 114.94, 84.90, 51.91 100,0% 124,8 req/s

[Hellhound]

Nou ik wil niet lullig doen , maar op dit moment zit ik weer tegen laadtijden aan te kijken van 20+ sec. Niet te doen dus .

[Garrett]

Ik net zo hier... dacht al dat het aan MxStream lag...
"gelukkig" ligt het dus niet aan mij

[WouterG]

Volgens mij ligt nu alles down

[Erkens]

Tomcat schreef op 30 augustus 2002 @ 23:03:
Volgens mij ligt nu alles down

huh? het werkt toch weer?

[SambalBij]

Tomcat schreef op 30 augustus 2002 @ 23:03:
Volgens mij ligt nu alles down

Toch knap dat je dan een bericht kunt plaatsen
Volgens míj is alles net weer up

[Hans]

Misschien moest je es de .plan's lezen op de frontpage.

[Verwijderd]

Tomcat schreef op 30 augustus 2002 @ 23:03:
Volgens mij ligt nu alles down

Knap dat je dit kunt posten dan

[WouterG]

Hans schreef op 30 augustus 2002 @ 23:06:
Misschien moest je es de .plan's lezen op de frontpage.

Had ik gedaan maar daarna niet meer aan gedacht. Sorry.

[Erkens]

Operations schreef op 30 augustus 2002 @ 23:05:
[...]

Toch knap dat je dan een bericht kunt plaatsen
Volgens míj is alles net weer up

Niet alles, image server nog niet

Verwijderd schreef op 30 augustus 2002 @ 23:06:

[...]

Knap dat je dit kunt posten dan

jullie zijn wel laat met reageren zeg

[Illegal_Alien]

Het gaat nu redelijk snel alleen de smilies willen niet

Total: 0,265 | Incl: 0,04, Init: 0,037, Action: 0,191 | DB: 0,073, Tpl: 0,095 | SV: iris.webmagix.net

[Arnout]

Niet te vroeg juichen

Of ben ik nu een pessimist?

[ Voor 0% gewijzigd door Arnout op 31-08-2002 11:06 . Reden: juichen spel je met ch. ]

[Arnout]

Even de .plan erbij gepakt; reactie van Femme:

Femme schreef op 28 augustus 2002 @ 20:19:
De performance problemen van de laatste weken hebben er niets mee te maken en zijn terug te voeren op de software (hier wordt uiteraard ook aan verbetering gewerkt).

Hmmz wat klopt hier niet?

[Maverick]

niets mis mee toch?

Femme zegt hier op een nette manier ff tussen neus en lippen door dat react behoorlijk zuigt

[Crazy D]

Maverick schreef op 31 augustus 2002 @ 11:59:
niets mis mee toch?

Femme zegt hier op een nette manier ff tussen neus en lippen door dat react behoorlijk zuigt

ROFL!
Ook wel netjes trouwens dat de planning gehaald is, 1 nachtje down ipv 2 dagen

[Verwijderd]

Deze page laden:
Total: 6.206 | Incl: 0.196, Init: 0.71, Action: 5.308 | DB: 0.126, Tpl: 4.975 | SV: achelois.webmagix.net

Rap issie niet echt

Tpl == Template toepassing?

Is dat niet op te slaan in de database? Die staat nu uit zn neus te eten.

[ACM]

tpl is laden/parsen template.
Nee die staan niet in de database omdat dat alleen maar _nog_ slomer is.

Die komen momenteel nog van een nfs-mounted dir.

[Azrael]

waarom is die topictitel veranderd

dat slaat toch nergens op?

[ACM]

Azrael schreef op 31 augustus 2002 @ 17:45:
waarom is die topictitel veranderd

dat slaat toch nergens op?

Weet ik niet
Probeer jij maar es in 2 seconde tijd de files van Amsterdam naar bijv Delft te krijgen, is toch best snel

[Azrael]

ACM schreef op 31 augustus 2002 @ 18:06:

[...]

Weet ik niet
Probeer jij maar es in 2 seconde tijd de files van Amsterdam naar bijv Delft te krijgen, is toch best snel

tja, als je ze met de auto zou brengen misschien wel

maar het gaat ook niet zozeer om de snelheid van de bestanden, maar om de wachttijd voordat je die bestanden mag ontvangen

Al moet ik wel zeggen dat het verbeterd lijkt hoor

[JvS]

ik had net een laadtijd van 6 seconden... Onder de 0,3 lijkt me toch wel wat we moeten hebben .

Deze page ging wel weer erg goed

Total: 0,112 | Incl: 0,02, Init: 0,022, Action: 0,076 | DB: 0,039, Tpl: 0,029

topictitel hereditted

[Verwijderd]

Het zit bij mij iedere keer in de template (6 seconden), toch iets aan het filesystem doen

[Verwijderd]

Ik had t ook, maar de optie http_compressie was de boosdoener: uitgevinkt gaat ie veel rapper

[Verwijderd]

ACM schreef op 31 augustus 2002 @ 17:42:
tpl is laden/parsen template.
Nee die staan niet in de database omdat dat alleen maar _nog_ slomer is.

Huh? De content ophalen + transformeren is sneller dan de content ophalen?
Vaag. Je kunt toch ook de content pre-formatted opslaan, die ophalen en alleen plakken in de pages.

Die komen momenteel nog van een nfs-mounted dir.

Ah die ellende.

[Femme]

Maverick schreef op 31 augustus 2002 @ 11:59:
niets mis mee toch?

Femme zegt hier op een nette manier ff tussen neus en lippen door dat react behoorlijk zuigt

Als ik zeg dat de problemen door de software worden veroorzaakt bedoel ik niet specifiek de forumsoftware. Het groote probleem is op dit moment de NFS server. Zie ook het verhaal Hans in "GoT met @home baggertraag?" .