Wo soll ich da jetzt am Besten anfangen, was man normal über private Kanäle versucht zu erklären ...
Grundsätzlich bin ich der Meinung, dass man heutzutage viel zu schnell mal in Richtung SSD geht, was in der Regel dann das echte Problem halt verschleiert. Man kann mit rotierenten Platten locker Umgebungen mit > 100 Benutzer bedienen, vorausgesetzt:
- Grundlegende Firebird-Settings sind berücksichtigt
- Das (physische) Datenmodell passt
- Der/die Entwickler haben schon mal was von Transaktionssteuerung in der Client-Anwendung gehört
- SQLs sind optimiert (SQL Performance)
- Verarbeitung am Client vs. am Server mit Stored Procedures/Trigger
- Etwas Server-Hardware
Server-Hardware ist meistens da. Da läßt man sich nicht lumpen, ist ja Ehrensache.
Aus meiner Erfahrung haperts
immer, na vielleicht zu 90%, an den anderen Sachen. Ein Steckenpferd ist
SQL Performance. Es gibt nicht grundlos Bücher die sich rein mit diesem Thema beschäftigen. Firebird ist hier keine Ausnahme. Warum auch. Ich hab schon Umgebungen gesehen, die mit < 10 Usern eine potente Umgebung in die Knie bekommen haben.
Zurück zum Problem des Thread-Erstellers: Da er 2.5 einsetzt, hat er bzgl. dem Monitoring jegliche Möglichkeiten, ohne dabei den Softwarehersteller zu brauchen, da das schön transparent mit den Monitoring-Tabellen und der Trace
API möglich ist. Es gibt auch Tools dafür, die hier einem den Einstieg enorm erleichtern. Ich mach jetzt keine Werbung ...
Mit diesen Mitteln hat man sehr, sehr oft in 15 Minuten die Top-Hitters auf
SQL Ebene identifiziert, sofern man in diesem Zeitraum eine repräsentative Last erzeugen kann. Die langlaufende Transaktion (OAT) sollte in MON$TRANSACTIONS auftauchen. Oft ist das "Problem" mit der OAT einfach die Verwendung von AutoCommit in der Client-Anwendung, die in der Regel im Hintergrund mit einem COMMIT RETAINING abgeschlossen wird, was die Transaktion physisch so richtig nicht beendet. Wo wir wieder beim Thema "Transaktionsteuerung" wären.
Auf der Settings-Ebene gibts dann halt noch Themen wie: Erhöhung von PageBuffers, In-Memory Sort Space, HashSlots (vor allem wichtig für Classic/SuperClassic) etc. Bei allen diesen Themen darf man nicht vergessen, dass auch noch der
OS Filesystem Cache da ist ...
Ach ja, eine Transaktion-ID Differenz von 6000 ist Kindergarten. Das merkt man an der Performance rein gar nicht. Spannend wirds im 6 oder 7-stelligen Bereich