Firebird optimal einstellen

[tsteinmaurer]

PS: Ich bin nach wie vor der Meinung, dass für das Klientel von Firebird, das sich hier bewegt, eine SSD das eigentliche Problem verschleiert. Aber das ist Ansichtssache. :-D

Ein Problem hier ist nämlich, dass Entwicklungsmaschinen in der Regel bereits immer mit Consumer-SSDs ausgerüstet sind, d.h. der Entwickler wird nie so wirklich in Versuchung zu kommen etwas zu optimieren, weil es eh immer schnell ist, vor allem auch wenn nur mit 1% Datenvolumen getestet wird.

[IBExpert]

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.

[lowmax_5]

Zitat:

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.

Das kommt aus der Praxis! ...man muss halt die Prioritäten schon richtig setzen... :roll:

[hstreicher]

hier noch ein Link auf einen etwas älteren Thread

http://www.delphipraxis.net/180125-w...-firebird.html

[zeras]

Zitat:

Zitat von IBExpert (Beitrag 1275551)

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.

Wo hast du solche Zahlen her? Bei uns läuft SAP und da warten wir schon mal 10 Sekunden für eine Transaktion.
Auch andere Sachen sind nicht performant. Da könnte ich mal zusammenrechnen, was so alles "verpulvert" wird.
Hat jetzt nichts direkt mit Firebird zu tun, ist aber trotzdem interessant.

[IBExpert]

Zitat:

Zitat von zeras (Beitrag 1275598)

Zitat:

Zitat von IBExpert (Beitrag 1275551)

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.

Wo hast du solche Zahlen her? Bei uns läuft SAP und da warten wir schon mal 10 Sekunden für eine Transaktion.
Auch andere Sachen sind nicht performant. Da könnte ich mal zusammenrechnen, was so alles "verpulvert" wird.
Hat jetzt nichts direkt mit Firebird zu tun, ist aber trotzdem interessant.

Simple mathematik, die mal in Zusammenarbeit mit einem Projekt für einen Großkunden berechnet wurden.

Gehen wir mal von einem bruttolohn inkl Arbeitgebernebenkosten von 3500 € pro Monat für
20 Arbeitstage mit je 8 Stunden aus. Dann bist du bei einem Stundenlohn von ca. 22 €
Eine Stunde hat 3600 Sekunden, also ist die Sekunde mit 22/3600 zu bewerten, also ca. 0,6 ct.

Das stellt aber keinesfalls die Vollkostenrechnung dar, weil der Mitarbeiter ja während der Zeit
auch noch meistens in einem geheizten Büro sitzt und der Computer noch Strom verbraucht und
an vielen Tagen im Jahr auch sicherlich auch noch Licht an ist, man gerade mit dem Kunden
telefoniert, der auf die Auskunft wartet, usw.

Bei dem Projekt ging es darum, den Vorteil zu berechnen, wenn ein Vorgang, der im Unternehmen
ca. 800000 mal pro Jahr durchgeführt wird, nicht mehr 120 Sekunden dauert, sondern nur noch
30 Sekunden. Das kommt reichlich zusammen, nämlich ca 430000 € pro Jahr.

Am Ende wurde die Berechnung auch dafür benutzt, das eine neue (nicht von uns stammende)
Software nicht eingeführt wurde, weil man dadurch für einen anderen Vorgang, der 300000 mal
pro Jahr ausgeführt wird, in der alten (Delphi basierenden) Software ca. 20 Sekunden dauerte
und in der neuen (Webbasierend) auch nach mehrfachen Versuche nicht in weniger als 600 Sekunden
durchführbar war. 300000*580 Sekunden, man hätte also dafür ca. 30 neue Mitarbeiter
einstellen müssen, um die gleiche Arbeit erledigen zu können. Wollte man dann aber auch
nicht ...

Wenn man zum Beispiel bei eine PKW Hersteller merkt, das man durch eine unsinnige
Einbaureihenfolge mehr Zeit braucht als in einer sinnvollen Reihenfolge, stößt das dort
sofort auf offene Ohren und die gesamten Prozesse werden hinterfragt.

Im Softwareumfeld ist das leider keineswegs der Fall. Gerade bei SAP ist das eben so, die
umständlichen Vorgänge und langen Reaktionszeiten dort zu hinterfragen gilt ja fast als
Gotteslästerung, zumindest bei der IT Leitung, die für die SAP Einführung verantwortlich
ist.

Bei inhabergeführten Unternehmen oder einer weniger ignoranten Geschäftsführung ist das
oft ein Argument, mal gewisse Prozesse zu hinterfragen, insbesondere wenn das mit konkreten
Zahlen hinterlegt ist und nicht einfach nur Meckerei über die lahme Software ist.

p.s.: Wir haben in dem o.a. Projekt auch noch mit dem Tool von http://www.mousometer.de/
auch gleich gemessen, wie viel Weg man während der Eingabe mit der Maus abklappern muss,
man wundert sich da, wie viel Meter da bei blöden Benutzerinterfaces zusammenkommen.

[zeras]

Danke erst mal für die ausführliche Info.

[Neumann]

Von performanten Rechnern kann ich leider nur träumen, oft muss ich die Firebird-Datenbank und auch das dazugehörige Delphi-Programm auf Rechnern mit älteren Atom-Prozessoren und normaler Festplatte installieren.

Die Datenbanken können bis zu 1 Mio Artikel und noch mehr Buchungen enthalten (100-500 MB); dauert die Berechnung eines Monatzumsatzes (mit vielen Details) dann auf so einer Kiste mehr als 15 sec werden die Kunden schon ungehalten.