stored procedures @ t.net?

[Verwijderd]

hehe, de dbserver bleek niet zo goed bestand tegen zo'n vloed aan hits, maar maken jullie gebruik van stored procedures, die zijn speciaal voor zulke gelegenheden, alleen weet ik niet of MySQL ze ondersteunt, MSSQL wel in ieders geval, dat gebruiken wij het levert een performance verbetering van 10x op, dus een query die eerst 20 sec duurde duurt nu 2 sec, dat geld natuurlijk niet voor alle queries, maar bij ons wel in ieders geval...

[Arjen]

MySQL ondersteunt geen stored procedures. Verder was het probleem niet echt de snelheid maar het maximum aantal simultane verbindingen. Na verhogen hiervan heb ik geen errors meer gezien.

[avatar]

idd, stored procedures werken echt een stuk sneller. vooral als je wat ingewikkeldere queries hebt scheelt het seconden met zo'n mooie pre-compiled sp.
Misschien toch ook best wel een id voor t.net om is over te stappen op een echt database-server. Volgens mij zou het heel wat moeten schelen in de serverload

(sybase voor linux is ook gratis hoor)

[Arjen]

Queries van seconden?

[witchdoc]

arjen: wrom zet je die dan niet meteen veel hoger? dat max verbindingen tegelijk dan

[Verwijderd]

het lijkt mij voor t.net idd een performance boost, ik weet geen cijfers van t.net maar het lijkt mij dat als er een nieuw nieuws bericht is, het eerste half uur errug veel requests komen naar die record, als je hem dan stored kan dat veel schelen, immers veeeel (hits) * weinig (tijdverbetering per querie) = winst
Alleen moet je wel overstappen op een peperdure licentie van Oracle, MS, IBM of whatever.

[Femme]

We hebben een hele mooi PIII-733 die al 1,5 maand uit z'n neus staat te vreten, dus daar moet eerst een oplossing voor bedacht worden (Linux, Solaris).

[CTVirus]

Wat is er met die PIII aan de hand is ie niet aangesloten of heeft ie geen load?, maar dan concludeer jij dus dat die stored procedures ook niet uitmaken

(We zijn wel tweakers he, dus als het harder kan, moeten we het doen, al heeft het net zo weinig zin)

en moet die PIII geeen koetje draaien Femme????

[Femme]

FreeBSD4 en MySQL blijkt een kutcombinatie te zijn op een SMP bak.

Aangezien MySQL geen stored procedures kent, kan ik er onmogelijk voor optimaliseren. 'ff overstappen' naar een andere database is ook niet iets dat een mens iedere dag doet.

Als die tweede CPU gewoon netjes had mee mogen doen dan was er geen load probleem geweest.

[CTVirus]

Dit is geen kwestie van een betere kernel configureren en compilen?? Tweakers moet in elk geval down als je het wil fixen.

Veel succes,

met een lastig probleem,

wat is dat RSI gedoe trouwens??

[mavink]

Op donderdag 25 januari 2001 17:55 schreef Arjen het volgende:
MySQL ondersteunt geen stored procedures. Verder was het probleem niet echt de snelheid maar het maximum aantal simultane verbindingen. Na verhogen hiervan heb ik geen errors meer gezien.

Hoe hebben jullie dat nu staan dan? Het lijkt mij: 2 webservers met respectievelijk X en Y als maximum aantal apache-processen, dus mysql heeft X+Y maximum aantal verbindingen. Maak ik nu een denkfout?

[mavink]

Op donderdag 25 januari 2001 22:39 schreef Femme het volgende:
We hebben een hele mooi PIII-733 die al 1,5 maand uit z'n neus staat te vreten, dus daar moet eerst een oplossing voor bedacht worden (Linux, Solaris).

Kan er niet gewoon weer een grote Vuurwerk-dag georganiseerd worden? Als er echt alleen een database opstaat is het volgens mij niet eens zo veel werk. Even kopieren naar een andere server, linux-cdtje er in, DB terugkopieren, en dan terug naar huis en rustig een beetje gaan zitten tweaken aan de rest van de configuratie.

[Verwijderd]

Op vrijdag 26 januari 2001 10:31 schreef vink het volgende:

[..]
Kan er niet gewoon weer een grote Vuurwerk-dag georganiseerd worden? Als er echt alleen een database opstaat is het volgens mij niet eens zo veel werk. Even kopieren naar een andere server, linux-cdtje er in, DB terugkopieren, en dan terug naar huis en rustig een beetje gaan zitten tweaken aan de rest van de configuratie.

Da's niet moeilijk, maar hoe wil je dat doen zonder downtime? Dan moet je even een andere server het op laten vangen. En dat is volgens mij het probleem.. ?

[Wouter Tinus]

Probleem is dat de site dynamisch is, dus als je een kopie van de database maakt en die een dag later terug zet zijn alle forumposts, alle reacties, al het nieuws enzovoorts van die dag weer verdwenen. Als er aan de database gesleuteld wordt moet de site dus down zijn ja.

Je zou wel een databaseserver alvast helemaal klaar kunnen maken, waardoor alleen tijdens het overpompen van de data van de oude naar de nieuwe server de site down moet.

[mavink]

Hoor ik hier iemand server replication zeggen? Mysql 3.23 heeft het, en aangezien die net "stable" verklaard is... Maar anders moet er maar wat downtime zijn denk ik. Dat is met de plaatsing van deze server toch ook gebeurd?

Als de servers trouwens zoveel hits als gisteren kunnen hebben zou je het zo kunnen doen dat 1 van de 2 webservers tijdelijk even de database draait, en de andere alle webpagina's doet. Dan is het allemaal misschien wat trager, maar volgens mij moet dat nog wel even kunnen.

[Arjen]

Op donderdag 25 januari 2001 19:09 schreef poohbeer het volgende:
arjen: wrom zet je die dan niet meteen veel hoger? dat max verbindingen tegelijk dan

Op donderdag 25 januari 2001 17:55 schreef Arjen het volgende:
[..]
Na verhogen hiervan heb ik geen errors meer gezien.

Op vrijdag 26 januari 2001 10:24 schreef vink het volgende:

[..]

Hoe hebben jullie dat nu staan dan? Het lijkt mij: 2 webservers met respectievelijk X en Y als maximum aantal apache-processen, dus mysql heeft X+Y maximum aantal verbindingen. Maak ik nu een denkfout?

Nu: maximum aantal MySQL verbindingen > maximum aantal apache processen.

Maar aangezien dat eerst minder was onstonden er dus problemen toen er opeens heel veel requests kwamen. Nadat het maximum aantal mogelijke verbinding was verhoogd waren de errors dus weg.

[Femme]

Kan er niet gewoon weer een grote Vuurwerk-dag georganiseerd worden? Als er echt alleen een database opstaat is het volgens mij niet eens zo veel werk. Even kopieren naar een andere server, linux-cdtje er in, DB terugkopieren, en dan terug naar huis en rustig een beetje gaan zitten tweaken aan de rest van de configuratie.

We kunnen niet ff een hele dag de site plat gooien. De beste oplossing is ws om s'nachts de database naar athena terug te zetten en dan de volgende dag Artemis op te knappen. Dan is de overlast zo beperkt mogelijk. Dit kan echter alleen als de derde webserver er staat omdat Appie anders de load niet kan trekken.

Het probleem met FreeBSD is niet zo maar een config filetje. De enige oplossing om MySQL de beide procs te laten gebruiken is het draaien van twee mysqld's, maar die twee mysqld's kunnen dus niet van elkaars databases gebruik maken. Dit is geen bruikbare oplossing.

[Wouter Tinus]

De database van GoT en T.net apart houden? Fok!(forum) kan misschien ook op een aparte server/MySQLd, zo kun je het wel verdelen lijkt me.

[Femme]

Dat is dus geen handige oplossing. Fok! heeft minder bezoekers dan t.net. Het zou ook meteen onmogelijk worden om de userbases van Fok! en t.net te migreren.