[SQL] SQL Server 2000 EP Performance

[Christiaan]

Ik ben bezig met de ontwikkeling van een gecombineerd forum-systeem. We spreken hier over een forum dat op heel veel sites tegelijk gedraaid kan worden en over 1 gezamelijk database beschikt.

Ik heb al ruime ervaring met normalisatie, optimalisatie, etc. Maar ik was benieuwd naar wat jullie voor tips hebben voor grote databases. Wat is verstandig qua performance en wat niet? Ik ben als de dood voor tablelocks waar, bijvoorbeeld, GoT ook door getijsterd wordt op momenten. Als ik normaliseer zou ik bijvoorbeeld alle posts in een tabel zetten en die koppelen aan een topics tabel. Vervolgens trek ik per topic alle gerelateerde posts uit de tabel en bepaal (voor een overzicht van topics) wat de datum van de laatste post is en wie die gepost heeft. Ook de topicstarter is dan interessant. Het probleem is dat dit steeds op run-time uitgevoerd wordt terwijl ik in feite best 4 redundante kolommen kan opnemen in de topicstabel waarin respect. de ID van de starter, de datum van de starter, de ID van de laatste poster en de datum van de laatste update staan. Dit is natuurlijk sneller, maar ook redundanter en daarnaast ben ik bang voor een grote hoeveelheid locks op de topics tabel omdat bij iedere post ook deze tabel (naast de posts-tabel) ge-update dient te worden.

Ik maak overigens gebruik van SQL Server 2000 Enterprise (zoals in de topic titel).

[ACM]

MSSQL doet bij mijn weten aan row-level locking van tabellen.

Dus een update op topic X, zorgt er ook voor dat alleen X wordt gelocked.

Zolang je met een rowlocking DB werkt heb je dus weinig last van locks in die Table op andere velden.

Mysql heeft in principe table-locking, dus als 1 veld gewijzigd wordt, wordt de hele table gelocked.

[Verwijderd]

Op Sunday 28 October 2001 22:42 schreef ACM het volgende:
MSSQL doet bij mijn weten aan row-level locking van tabellen.
Dus een update op topic X, zorgt er ook voor dat alleen X wordt gelocked.

Volgens mij locked ie per 4k page? dus als je X locked krijg je ook wat locks rondom X.

Disclamer:Dit is uiteraard gebaseerd op pure speculatie in combinatie van mijn ow zo rotte brein.

[ACM]

Op Sunday 28 October 2001 22:45 schreef Yarvieh het volgende:
Volgens mij locked ie per 4k page? dus als je X locked krijg je ook wat locks rondom X.

Disclamer:Dit is uiteraard gebaseerd op pure speculatie in combinatie van mijn ow zo rotte brein.

Ach, is iig al beter dan een complete table locken

[Christiaan]

Mja, eigenlijk had ik dat zelf wel kunnen weten....row locking is natuurlijk bij de meeste grote DBMS-en wel standaard. Ok, dat lost 1 probleem op.

Maar dan de volgende; in hoeverre is normalisatie goed of slecht bij echt grote databases? Ik denk toch dat ik hier een systeem moet opzetten dat qua complexiteit en grootte GoT voorbij gaat. Performance is dus echt van essentieel belang.

[PhoneTech]

Misschien kan je de DB structuur hier ff posten zodat we wat meer commentaar kunnen geven op de structuur.

[tomato]

Normaliseer gewoon zoals je dat altijd doet naar 1e 2e 3e normaalvorm en kijk dan eens naar hogere normaalvormen.

[Christiaan]

Alhoewel ik het een aardig aanbod vind om de structuur hier te posten, is het toch wat te groot. Het systeem omvat niet alleen het forum, maar ook een kerberos achtig beveiligingssysteem met gebruikers, groepen, memberships, domains, etc. Nogal complex dus. Maar goed, als je het ECHT wilt zien kan er altijd een mouw aan gepast worden natuurlij.

[raptorix]

Kijk eerst eens hoe het gaat met je performance, kom je in problemen dan zou je eens via je profiler kunnen kijken waar de pijn zit, je winst zou je kunnen behalen door bijvoorbeeld:

-Topicoverviews te cachen
-Oudere Topics naar een archiverings table te verplaatsen
-Zoek acties te cachen
-Veel client site afhandeling

Uiteraard alles via stored procedures doen, en ga niet te veel breien in je applicatie, in principe is je database leidend, en hou dat ook zo. Soms zie je dat er enorm veel gerotzooid wordt buiten de database om om een bepaald resultaat te krijgen, je ziet dat er dan allemaal dingetjes aan je database geplakt wordt en het overzicht vervaagt.

In principe moet na je release 80 a 90 procent van de applicatie klaar zijn, wil je meer, kijk dan eerst hoe je datamodel moet worden aangepast om dat meer effect te bereiken.


Maar het allerbelangrijkst is denk ik dat je een soort van prijs per gebruiker berekent, in het geval dat je meer gebruikers krijgt betekent dit ook meer load, je zou bijvoorbeeld kunnen stellen dat je voor elke 300 concurrent users 1 server rekent, dit getal is natuurlijk maar speculatief maar je zou het zelf redelijk goed kunnen berekenen.

[tomato]

En performance tweaken kun je voor een groot deel niet in ontwerpfase doen. Je zult voor veel dingen je systeem live moeten zien draaien.
Je kunt natuurlijk wel van te voren een hoop speculaties doen over mogelijke bottlenecks en daarmee rekening houden in je ontwerp zodat je hier later makkelijk wat aanpassingen kunt proberen. Maar er zijn dingen waarvan je van te voren niet met zekerheid kunt zeggen hoe het in de praktijk zal gaan uitvalen.

[tomato]

Op Sunday 28 October 2001 23:37 schreef raptorix het volgende:
-Topicoverviews te cachen

Caching kan erg belangrijk worden bij een groot systeem. Caching kan ook erg ingewikkeld zijn, zeker bij een dynamische applicatie als een forum. Maar het is zeker de moeite waard je eens te verdiepen in verschillende caching systemen en de implementatie ervan.
Is echter niet iets waar je mee begint. Je applicatie zou moeten staan als een huis zonder caching. Is dat het geval, dan ga je naar caching kijken.

-Oudere Topics naar een archiverings table te verplaatsen

Niet zo fraai, echt een noodoplossing imho, of iig iets wat je na een half jaar of langer gaat bekijken.

-Zoek acties te cachen

Zoeken kan een groot probleem worden. Je zult er ook veel aan hebben om je te verdiepen in verschillende zoeksystemen en eventueel in combinatie met caching.

-Veel client site afhandeling

Jammer dat XSL nog niet echt client-side werkt. Of kun je eisen stellen voor browsers?
Verder zou je een hoop met JavaScript kunnen doen, vooral dingen als XForms zijn dan leuk. Maar dit is allemaal nogal een gepriegel imho.

Uiteraard alles via stored procedures doen, en ga niet te veel breien in je applicatie, in principe is je database leidend, en hou dat ook zo. Soms zie je dat er enorm veel gerotzooid wordt buiten de database om om een bepaald resultaat te krijgen, je ziet dat er dan allemaal dingetjes aan je database geplakt wordt en het overzicht vervaagt.

Goed punt. Erg belangrijk, maar ik denk dat hij dat zelf ook wel zo'n beetje weet aangezien hij zegt dat hij ruime ervaring met databases heeft.
Wel iets waar veel mensen niet zo goed over nadenken en het gevolg is vaak een erg ranzige, onschaalbare, niet onderhoudbare, slappe (slechte integriteit) applicatie (iets wat je uiteraard wilt voorkomen).

[Christiaan]

Inderdaad, de meeste punten zijn me al bekend, maar dat maakt niks uit. Er zitten altijd dingen bij waar ik gewoon niet aan gedacht had (zoals 'views', ik had daar bij dit project nog niet aan gedacht).

Wat ik wel heb is een systeem dat mbv JScripts de pages op de client rendert (ligt het nu aan mij - of ziet 'rendert' er wat vreemd uit ). Anyways; de server plukt mbv ASP een rijtje records uit de database via een query en stuurt die naar de client. Daar kan vervolgens lekker ge-resort worden als dat nodig is (op postcount, postername, etc. standaard gewoon op datum van update gesort). Het werkt nu in IE5, Netscape 6.1 en de nieuwste Opera (versienummer ff vergeten). Ik weet niet hoe het met oudere versies werkt, want daarmee heb ik het nog niet geprobeert. Het grote voordeel hiervan is natuurlijk dat er minder bandbreedte nodig is voor data. De .js templates worden gecached op de client en verder is er ook geen ASP nodig om HTML-templates op te maken.

Maar voor zover mijn commentaar. Hoe meer tips hoe beter