Die Fakten, die ich hier aufführe, basieren auf den Erkenntnissen und Hardware, die ich bei den Kunden vorfinde.
Wer die Hardware und Software für Firebird auswählt, sollte eigentlich eine grobe Ahnung davon haben, was bei einer Datenbank und insbesondere bei einer Firebird Datenbank wichtig ist. Fakt ist leider, das die meisten Admins glauben, die Weisheit mit Löffeln gefressen zu haben und sich da von ihrem Hardware Fritzen alles andrehen lassen, was gut und teuer ist.
Wenn man vorher mal jemand wie Thomas oder mich fragt, würde so manch ein Hardwarefritze da enttäuscht sein. Einfacher ist oft besser ...
Beispiele aus der Praxis:
Test einer ganz aktuellen High End Schlag mich tot I/O PCIe Einsteckkarte mit ganzen tollen IOMeter Testwerten, worauf der Hardwarehersteller auf der Messe ganz stolz war. Auf meine Frage, ob ich das mal mit unserem Benchmark testen darf, hat der Hersteller das unerwartet gerne genehmigt. Hab ich dann auch gemacht, war aber am Ende nicht schneller als eine 200 € SSD in einer 08/15 Xeon Kiste, eher langsamer. Sollte aber alleine als SSD 8500 € kosten, mit der 24 Kern CPU usw. noch zusätzlich ca 10000 € ....
Noch ein Beispiel: Kunde sieht auf einer Messe ein Rack Storage System von einem US Start Up mit 12 TB SSDs als Raid mit diversen Schnick Schnack Technologien. Das sollte das schnellste, tollste und beste sein, was es auf der Welt gibt. Kostete so in der Konfiguration allerdings auch 250.000 US$. Kunde lässt sich überreden zu einer kostenlosen 30 Tage Leihstellung. Wir testen das gemeinsam und die Ergebnisse für Firebird sind unteridisch, mein Laptop war deutlich schneller. Im Multiusertest (unser Benchmark geht optional auch mit 100 threads und zehnfacher
DB Größe) brach die Performance total zusammen, weil wohl jeder Zugriff irgendwie serialisiert ist. Als Filesystem was das Ding aber irre schnell (Große Dateien kopieren mit 5GB pro Sekunde war schon ganz nett). Ist aber egal, weil das als backend für Firebird gedacht war und dafür komplette Geldverschwendung.
Das Problem ist aber, das du als Entwickler dir nicht erklären kannst, was da beim Kunden so seltsam ist, wenn du keinen reproduzierbaren Messwert hast und dem Kunden vorführen kannst, das seine angeblich so tolle Maschine für Firebird unbenutzbar ist.
Wenn dann der beste Freund vom Geschäftsführer des Endkunden ein Systemhaus hat und sich ja mit alles super auskennt, dann wird dein Endkunde dir nicht glauben, bis du reproduzierbar nachweisen kannst, das die von Ihm gewählte Hardware/Software Kombination für Firebird nicht geeignet ist, egal wie schnell man darauf Dateien von A nach B kopieren kann.
Bei einem unserer Kunden, wo unser Benchmark auf dem Server seines Endkunden über 2 Stunden brauchte (normal sind weniger als 2 Minuten, schnell ist weniger als eine Minute), hilft es auch nicht, deine Software noch weiter zu optimieren. Auf so einer Gurke (die vom besten Kumpel des Endkunden, seines zeichens Inhaber eines Systemhauses und Ahnung von alles habend, an Ihn verkauft wurde) wirst du niemals eine akzeptable Leistung haben. Ohne vergleichbaren Messwert kannst du aber nichts machen.
Wenn der Kunde geizig ist und es ihm völlig egal ist, ob die Mitarbeiter die meiste Zeit des Tages mit warten auf die Software verbringen, dann kann dein Kunde das ja gerne selbst entscheiden. Wenn du aber als Softwarehersteller irgendwas in die Leistungsbeschreibung reinschreibst wie xxx ghz, xxx GB
Ram und Raid o.ö, dann bist du vielleicht dafür verantwortlich, das es beim Kunden mehr Wartezeit als Arbeitszeit gibt, weil der einfach nur mit der Vorlage zum Hardwareheini geht und der dann was zusammenstellt, das deiner Beschreibung entspricht. Wenn es dann lahm ist, hinterfragt der zu Recht deine Software. Wir haben einige Kunden, die mittlerweile beim Server mindestens 100% Leistung beim IBExpert Benchmark fordern und das mit der Tageslizenz auch testen. Wenn die dann auf einen Rechner mit 50% treffen, sind die Fronten geklärt. Es ist dann Entscheidung des Kunden, den Rechner trotz mangelhafter Leistung zu nehmen und damit die Wartezeit der Anwender in Kauf zu nehmen. 1 Sekunde Wartezeit kostet im Schnitt ca. 0,6 ct an Arbeitskosten. Da kommt einiges zusammen, wenn in einer größeren Firma die Mitarbeiter bei jedem Prozess dauernd 10 Sekunden warten muß, weil der Admin einen ungeeigneten Server ausgewählt hat.
In der Kombination mit Virtualisierung vertrödelt man dann ggf noch mehr Leistung, aber Hauptsache der Admin kann die VM schnell mal eben von node a auf node b schubsen kann, falls node a mal ausfällt, obwohl das in der Vergangenheit noch nie der Fall war.