GOT database probs?

[ACM]

Op vrijdag 26 oktober 2001 22:36 schreef little_soundman het volgende:
Is dit nu weer de laatste smoes ?
Android heeft geen xxx duizend piek betaald voor de zend-encoder. Eerdere kleine aanpassingen door de crew ondersteunen dit gegeven.

Nope, we hebben geen source van topix.
Of zij die encoder gekocht hebben, of wat dan ook. Weet ik niet, maar vrijwel alle aanpassingen (voor zover niet db-related) zijn door Arjen uitgevoerd.

[xoror]

Alles in InnoDB gebeurt binnen transacties, ook als je queries niet expliciteit in je code als transactie behandeld. In InnoDB zullen inserts daarom niet mysterieus verdwijnen zoals dat bij MyISAM soms wel het geval is.

Dat is autocommit. het klopt tot op zekere hoogte wat je zegt. Maar de inserts zullen nog steeds mysterieus verdwijnen als je de zooi niet (zelf) binnen transacties zet. Voor een forum bijv. moeten alle insert queries (dus 1e voor topic gegevens, en daarna body) goed gegaan zijn (voor het plaatsen van een topic). anders moet je een rollback doen. Als je dus alleen inndoDB installed met autocommit, helpt dat in dit geval nog niets.
de insert worden een voor een gecommit wat op het zelfde effect neer komt als met de oude situatie. De autocommit kan je in dit voorbeeld nog als extra overhead zien. De brakke topics gaan (in dit voorbeeld) pas weg als je zelf de SQL aanpast in topix. zoals aangegeven is het lekker gezend encoded.

[xoror]

Op vrijdag 26 oktober 2001 22:43 schreef woutf het volgende:

[..]

In een ander topic liet ACM een stukje topix code zien, en reken maar van yes dat dat ge-encode was, ze kunnen er niks mee. Zelfs template dingen moeten door Android gedaan worden

dit is natuurlijk niet waar. de templates kunnen niet ge-zend encoded zijn. immers ze worden in je code geparsed. dus jij leest die files zelf in om te parsen. je kan prima de templates dus zelf aanpassen. (ik reageer zo omdat jij met je zinnen suggereert dat zelfs de templates ge-encode zijn)

Overigens waarom denkt iedereen dat zend encoder duur is. Je HOEFT niet gelijk de unlimited te kopen. je kan ook huren voor paar honderd dollar per jaar.

[Femme]

Op vrijdag 26 oktober 2001 23:00 schreef xoror het volgende:

Als je dus alleen inndoDB installed met autocommit, helpt dat in dit geval nog niets.

In InnoDB is de kans dat één insert/update mislukt veel kleiner. Het is dus ook veel minder waarschijnlijk dat één van de queries in een 'transactie' (het toevoegen van een nieuw topic of nieuwe posting) mislukt.

[Wouter Tinus]

Op vrijdag 26 oktober 2001 23:08 schreef xoror het volgende:
dit is natuurlijk niet waar. de templates kunnen niet ge-zend encoded zijn. immers ze worden in je code geparsed.

ze worden geloof ik gechecked op het aantal bytes dat ze groot zijn

[xoror]

Op vrijdag 26 oktober 2001 23:13 schreef Femme het volgende:

[..]

In InnoDB is de kans dat één insert/update mislukt veel kleiner. Het is dus ook veel minder waarschijnlijk dat één van de queries in een 'transactie' (het toevoegen van een nieuw topic of nieuwe posting) mislukt.

ik hoop het, ben erg benieuwd. De oorzaak van brakke topics is toch ook nooit gevonden ? (en nee dan bedoel ik niet dat een insert failed het gaat erom waarom ie failed).

[xoror]

Op vrijdag 26 oktober 2001 23:15 schreef WouterTinus het volgende:

[..]

ze worden geloof ik gechecked op het aantal bytes dat ze groot zijn

das flauw, je maakt die zooi met templates omdat je niet om de paar kleine updates alles zelf moet doen. Je geeft daarmee je klanten geen kans kleine veranderingen zelf te doen.

Waarom nemen jullie geen oude versie van topix toen er nog source bij zat en ga je die niet modificeren ? of is het in het contract expliciet opgenomen dat het niet toegestaan is ?

[Coen Rosdorff]

Op vrijdag 26 oktober 2001 23:17 schreef xoror het volgende:

het gaat erom waarom ie failed

Te lange wachttijd (timeout). Door de table-locks kan het nogal lang duren als er veel inserts zijn. (Is "delayed-insert" in dit opzicht eigenlijk wel eens geprobeert ?)

Of mysql die op zijn gat gaat. Of apache die uit elkaar spat omdat hij memory lekt.

Kan vanalles zijn. Niet echt haalbaar om al die kwalen op te lossen. Er kan altijd iets mis gaan. Door van de belangrijkste dingen transacties te maken kan je dat prima opvangen.

Leuk nieuws van vandaag trouwens : Benchmark: Oracle on SuSE is Faster Than NT2000

[McMiGHtY]

Geen enkele technische reden meer om niet over te stappen op Oracle dus

[Femme]

InnoDB doet wat we nodig hebben (row-level locking), draait onder MySQL (waar we ervaring mee hebben) en kost niks.

[Verwijderd]

helemaal mee eens femme. het doet wat het doen moet.
ach der blijft altijd wel wat te zeuren cq wensen over

alleen jammer dat jullie van FreeBsd afgaan

[ACM]

Op maandag 29 oktober 2001 00:22 schreef McMiGHtY het volgende:
Geen enkele technische reden meer om niet over te stappen op Oracle dus

Geen technische (behalve dat we geen Oracle DBA in huis hebben en dat zeker de eerste periode best wel een belangrijke job kan zijn).

De financiele zijn wat belangrijker. Oracle vraagt vrij veel voor 4Cpu's, met dus een setje named users (moeten 500 connecties per server kunnen komen, maar dat zijn natuurlijk grotendeels hetzelfde clubje users)

[Verwijderd]

of ze moeten gaan sponsoren. maar dat zie ik ze nog niet zo snel doen.

[McMiGHtY]

er is al vaak genoeg hulp en hw aangeboden. Misschien moeten ze dat is aannemen?

[Daniel]

Op dinsdag 30 oktober 2001 16:57 schreef McMiGHtY het volgende:
er is al vaak genoeg hulp en hw aangeboden. Misschien moeten ze dat is aannemen?

Een aanbod wordt aangenomen als we er iets aan hebben. Als ik in een Ford rij en iemand biedt mij gratis en voor niks het motorblok van een Volkswagen aan is dat leuk, maar daar heb ik dus niets aan

[Verwijderd]

Ondanks de laatste reactie van 30 Oktober vond ik het toch zinvol om er nog een reactie van mijn kant bij te plaatsen aangezien ik dus dag in dag uit met ColdFusion werk en er ook werkelijk alle ins-en-outs vanaf weet.

Dat de tweakers server niet helemaal lekker lopen kan zo zijn, maar ik zou het eventjes afwachten totdat je de loadbalancer ernaast hebt staan. Het kan zijn dat door de de LVS er de nodige problemen opgelost gaan worden.

Wat betreft de mogelijkheid van Anandtech om een hogere load aan te kunnen op mindere servers heeft alles te maken met het gebruik van ColdFusion in tegenstelling tot PHP.

ColdFusion biedt standaard de optie om queries te cachen en de mogelijkheid om andere queries uit te voeren op de reeds gecachede query. Uit ervaring kan ik mededelen dat dit enorm scheelt in de load. De database wordt als het ware uit het geheugen gehaald ipv harde schijf. Tevens doet ColdFusion dit met pagina's.

De hoeveelheid hardware die jullie nu nodig hebben is denk ik een combinatie van database+scripting language die niet op de huidige hoeveelheid data is berekend.

[Verwijderd]

Op maandag 29 oktober 2001 00:27 schreef Femme het volgende:
InnoDB doet wat we nodig hebben (row-level locking), draait onder MySQL (waar we ervaring mee hebben) en kost niks.

Maar je zou ook is Microsoft kunnen opbellen om te vragen of ze jullie graag zouden willen sponsoren met een versie van MSSQL. Ik als marketing manager van Microsoft zou daar geen moment over aarzelen en mijn software grabbelton erbij pakken om vervolgens je een doosje MSSQL software te overhandigen.

Nee heb je en ja kun je krijgen. Probleem is alleen hoe ga je MSSQL op een Linux machine draaien.. niet dus. Is er dan de optie om van Linux naar Win2K over te stappen

Dus volg dan je hart op zakelijk gebied ipv het tweakers gebied. Wat is het beste?

[Verwijderd]

Gordijnstok: Je wil dus zeggen dat GoT te traag is door verkeerde software die niet berekend is op zo'n hoge load en dat ColdFusion Rulez

Ik snap het.

[Verwijderd]

Op maandag 19 november 2001 14:59 schreef mgfun het volgende:
Gordijnstok: Je wil dus zeggen dat GoT te traag is door verkeerde software die niet berekend is op zo'n hoge load en dat ColdFusion Rulez

Ik snap het.

Nee en ja. Ik vind ( en dat geef ik eerlijk toe ) ColdFusion ( en Jrun) gewoon een beter pakket. Daarnaast zie ik de immer rijzende problemen die al tijden en tijden aan de gang zijn.

Dan weeg ik de hoeveelheid hardware en hits van T.net relatief af tegen die van Anandtech, en dan zie ik toch een flink verschil waarbij T.net het "niet al te goed doet".

Daarbij komt nog dat mysql table locking gebruikt ipv row locking en bij iedere db request dus de gehele tabel vastzet totdat deze is afgerond.

Dan bekijk ik de mogelijkheden van caching door php en die zijn praktisch nihil. Dan bekijk ik die van CF en die zijn erg uitgebreid. Nog steeds is RAM geheugen sneller als een harde schijf.

Nu zeg ik niet dat T.net meteen moet overstappen op ColdFusion, er zijn evt. ook andere talen beschikbaar die wel over caching beschikken, maar wel om is verder te kijken naar professionele pakketten, die evt. worden gesponsord, want het ontbreekt ze aan financiele kracht om bijv. een websphere in te zetten.

[MoBi]

Op maandag 19 november 2001 15:05 schreef Gordijnstok het volgende:

Daarbij komt nog dat mysql table locking gebruikt ipv row locking en bij iedere db request dus de gehele tabel vastzet totdat deze is afgerond.

Dat hebben ze nu opgelost via innodb.

Als je software dat niet ondersteund terwijl je dat wel gebruik van wil maken om dat sommige dingen niet iedere keer hoeven worden opgehaald, dan zou ik ook serieus kijken naar andere pakketten die dat inderdaad wel hebben ja.

Voorbeeld zijn de reviews, waarbij alleen de laastste pagina (die met reacties) dynamisch hoeft te zijn. Als een review geplaatst is veranderd er aan de rest van voorgaande pagina's niks. Maar ze moeten wel iedere keer uit de db gehaald worden. Vooral als er weer een review is waarmee je het slashdot effect over je krijgt dan is dat super makkelijk (cachen dus). Probleem met het forum is dat het (volgens mij nog steeds) niet mogelijk is te load balancen omdat er gebruik word gemaakt van sessie's. Deze kunnen niet naar een andere server worden meegenomen met php.

[Verwijderd]

Of waarom juist die pagina's dynamisch gaan serveren ipv statisch genereren

Oftewel je drukt in je CMS op publish, een html pagina wordt aangemaakt, en alleen de reactie hoeven dynamisch te zijn

[ACM]

Op maandag 19 november 2001 15:59 schreef Gordijnstok het volgende:
Of waarom juist die pagina's dynamisch gaan serveren ipv statisch genereren

Enneuhm, waar zit dan precies het verschil met hoe het nu werkt?

Imho zijn alle problemen die we nu met de load (die we niet eens zo heel erg veel hebben momenteel) op te lossen met zaken die niet een ander software pakket vereisen.

Het grootste nadeel zit hem in het niet kunnen wijzigen van de topix-source en de tijd die het neemt daar een oplossing voor te vinden.

Daarnaast worden vrijwel alle load problemen die er nu nog zijn door de search engine veroorzaakt.
Deze is gewoon niet efficient genoeg met ruim 3Miljoen posts. (en dan wordt er niet eens een LIKE search gedaan )

[Verwijderd]

Op maandag 19 november 2001 16:13 schreef ACM het volgende:

[..]

Enneuhm, waar zit dan precies het verschil met hoe het nu werkt?

Imho zijn alle problemen die we nu met de load (die we niet eens zo heel erg veel hebben momenteel) op te lossen met zaken die niet een ander software pakket vereisen.

Het grootste nadeel zit hem in het niet kunnen wijzigen van de topix-source en de tijd die het neemt daar een oplossing voor te vinden.

Daarnaast worden vrijwel alle load problemen die er nu nog zijn door de search engine veroorzaakt.
Deze is gewoon niet efficient genoeg met ruim 3Miljoen posts. (en dan wordt er niet eens een LIKE search gedaan )

Dan moet je dus meer gaan cachen

Het verschil in die statische pagina's zit hem er juist in dat er totaal geen DB access meer is voor articles. Bijvoorbeeld Vignette V5 (voorheen StoryServer)is hiermee bekend geworden. Dit systeem levert puur alleen statische pagina's die alleen bij het publishen worden aangemaakt.

Alles kun je dan vanaf een webserver ipv applicatieserver serveren, en zo kun je dus je load gigantisch verlagen. Het geld wat je normaal gebruikt had voor nieuwe hardware kun je nu in je zak steken om evt. te investeren in verdiende (evt. langverwachte) loonsverhoging van de redactie, marketingactiviteiten, enterprise software, etc.

Let wel de winst wordt meestal niet hoger, winst is nl. een boekhoudkundige fout.

[ACM]

Op maandag 19 november 2001 16:18 schreef Gordijnstok het volgende:
Het verschil in die statische pagina's zit hem er juist in dat er totaal geen DB access meer is voor articles. Bijvoorbeeld Vignette V5 (voorheen StoryServer)is hiermee bekend geworden. Dit systeem levert puur alleen statische pagina's die alleen bij het publishen worden aangemaakt.

En hoe toepasbaar is dat, denk je, hier ter vervanging van GoT ??

De frontpage kan vast nog wel wat meer gecached van worden, maar topix? Niet zo veel dat je er helemaal statische request van kan maken (ok, vroegere ubb-principe...)

[Verwijderd]

Op maandag 19 november 2001 16:32 schreef ACM het volgende:

[..]

En hoe toepasbaar is dat, denk je, hier ter vervanging van GoT ??

De frontpage kan vast nog wel wat meer gecached van worden, maar topix? Niet zo veel dat je er helemaal statische request van kan maken (ok, vroegere ubb-principe...)

Statisch gezien is Topix 0,0. Topix heeft gewoon een betere code nodig. Zij het niet een ander forum. Qua statisch ging het voornamelijk om de pagina's van T.net.

Qua caching voor een forum zoals topix zijn de mogelijkheden en te behalen winsten behoorlijk hoor. Wat ColdFusion doet is heel snel de ge-cachede versie in de RAM controleren met een nieuwe insert/update statement, en de RAM versie bijwerken.

Omdat Anandtech voor hun forum gebruik maken van fusetalk maken ze automatisch gebruik van deze opties. En toch scheelt dat erg veel.