Also wenn man die Changelogs zu
FB 4.0 liest merkt man schon, dass die Entwickler eine Flaschenhälse im Netzwerkinterface von
FB angegangen sind. Speziell bei vielen kleinen Anfragen trennt
FB sehr früh die
TCP-Verbindung, sodass die neu ausgehandelt werden muss. Insofern würde ich sagen, schaukeln sich hier die Eigenarten von
FB und Delphi gegenseitig zu einem Problem hoch.
Aus den o.g. Gründen bewirken Einstellungen am
DB-Cache auch verhältnismäßig wenig. Und umso stärker wirkt sich das Problem aus, je mehr Clients am Server hängen und je schlechter das Netzwerk konstruiert ist (z.B. billige Switches mit minimalem ARP-Cache, Mesh-WLAN etc.).
In der Konsequenz müssen Delphientwickler die
FB nutzen, einen erhöhten Aufwand betreiben, performante Clients zu schreiben. Damit wird der Gedanke, der hinter
RAD mal stand, ad absurdum geführt. Die Tatsache, dass es Spezialisten (neudeutsch "Berater") braucht, die Delphientwickler coachen, bestätigt das ja ein Stück weit. Klar kann man mit
FB performante Anwendungen schreiben. Kann man wohl mit jedem aktuellen, auf heutige Multicore-CPUs optimierten
DBMS.
Die entscheidende Frage ist: Mit welchem
DBMS kann man mit Delphi am schnellsten das
RAD-Konzept umsetzen? Intuitiv so, wie es mal von Borland gedacht war. Die Antwort möge jeder sich selbst geben...