> bei einer Website ergeben sich zunehmend
Leistungsprobleme, die ich nicht richtig zuordnen
kann.
Als ersten Schritt
w�rde ich mir die Querys anzeigen lassen, die am meisten ben�tigt
werden und die im Query Analyzer ausf�hren und mir dabei den
Ausf�hrungsplan anzeigen lassen. Findest Du in diesem Plan irgendwo 'Table
Scan', dann fehlt an dieser Stelle ein Index.
Indizes sollten
immer die Reihenfolge der WHERE-Klausel beinhalten. Bei Programmieren achtet
man nicht immer darauf. WHERE A = x AND B = Y oder WHERE B = Y AND A = x AND
ist nicht dasselbe - also Code �berpr�fen und die selbe Abfragereihenfolge
einhalten. Zwei Indizes dort anzulegen macht keinen Sinn, das geht beim
Schreiben dann wieder zu Lasten der Geschwindigkeit.
Bei so vielen
gleichzeitigen Usern w�rde ich auf Dauer auf jeden Fall Stored Procedures
verwenden. Das bringt einen enormen Schub - aber auch nur, wenn die o.g.
M�glichkeiten ausgesch�pft sind.
Eine weitere Ursache
k�nnte eine nicht explizit geschlossene Connection in einem Script sein, dann
wird n�mlich der Speicher knapp, weil die Connection f�r die Zeit des
Session-Timeouts offengehalten wird.
Zur Frage mit der
Tabelle f�r die Benutzer. Der gruppierte Index auf die BenutzerID sorgt daf�r,
da� die Tabelle bei jedem neuen Eintrag umgeschrieben wird, denn die Datens�tze
werden beim Eintragen in der Reihenfolge der BenutzerID geschrieben. Bei der
Gr��enordnung der Tabelle dauert das nat�rlich eine ganze Weile. Wenn sich
gleichzeitig viele Benutzer neu anmelden, k�nnte das schon ein entscheidender
Faktor f�r die Verz�gerung sein.
Bei alten SQL
Server-Version machte es schon Sinn, den gruppierten Index anders als f�r den
Primary Key zu verwenden. Meiner Erfahrung nach, ist das mittlerweile nicht mehr
erforderlich, zumal es das Schreiben stark beeintr�chtigt.
Tsch��, Joachim
Uersfeld
