Hallo! > > Ja, aber wenn die Abfrage bei wenigen Benutzern nur 10 ms ben�tigt, > > liegt es ganz bestimmt nicht an den Indexen, oder? > > Bei 4 GB RAM kann es schon sein, weil der SQL Server ja die > Abfragen cacht.
Also je mehr User, desto schneller??? > > Das erkl�rt aber nicht die "Performance-Steigerung". Wenn > > Abfragen, die > > sonst 10 ms dauern, bei steigenden Benutzerzahlen dann bis > > zu 5600 ms > > ben�tigen, riecht das eher nach einem Lizenzproblem, zumal > > ja "nur" mit > > ADO und nicht mit komplexen Stored Procedures zugegriffen wird. > > Wie kommst Du auf das Lizenzproblem? Wegen "SQL Server 2000 Standard". Der SQL Server arbeitet mit Threads. Bei 25 Client-Lizenzen k�nnen also 25 Threads gleichzeitig bearbeitet werden. Das reicht sicherlich f�r 500 Benutzer einer Website v�llig aus. Wenn zu viele Clients auf den SQL Server zugreifen, geht der SQL Server per Programm in die Knie, auch wenn gen�gend Prozessorkapazit�t vorhanden ist. Aus diesem Grunde gibt es ja auch seit SQL Server 2000 eine Website-Lizenz, oder? Wenn das Problem allein durch Indizes verursacht wird, dann d�rften die Abfragen auch bei einem Benutzer recht langsam sein. Da hier jeder Benutzer seine eigenen Daten bearbeitet, gehe ich mal davon aus, dass zumindest die BenutzerID indiziert ist, und das Cachen nichts n�tzt. Schlechtes Design und unsachgem��er Einsatz von ADO (falsche oder nicht sachgerechte Cursor, pessimistic Locking, ...) w�rden die Leistung mit steigender Benutzerzahl kontinuierlich abnehmen lassen. Hoffentlich ist es also ein Lizenzproblem (sehr schnell zu l�sen!). Alle Abfragen auf Firehose-Cursor-Recordsets und alle Modifikationen auf Commands umstellen ist ja etwas aufwendig, oder? Freundliche Gr��e Joachim van de Bruck _______________________________________________ Database.asp mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/database.asp
