Firebird optimal einstellen

[csaeum]

Hallo Leute ich hätte da gerne mal ein Problem :-D

Wir nutzen hier in der Firma seit einigen Wochen Vario7 als ERP was mit Firebird läuft.

Leider kann mir der Dienstleister in Bezug auf optimierung der Datenbank nicht helfen oder erst in 4-5 Wochen.

Wir haben hier folgendes im Einsatz:
Fujitsu Server mit
Intel XEON E3-1220 V2 3.10 GHz
24GB RAM
Windows 2008 R2

Auf den Rechner ist nur Windows und ein paar Freigaben und dazu der Firebird.

Ich habe über 4 Festplatten ein RAID 10 aufgebaut auf diesen ist der Firebird am laufen. Es sind zwar auch die Freigaben dort aber die sollten hier nichts das Problem sein.

Die Schattenkopien sind seit heute aus.

Zum Firebird:

Ich habe schonmal mit der DefaultDbCachePages = 131072 gespielt.

Mit auskommentieren und erhöhung auf 1024 konnte ich die erstellung der Varianten im ERP von 5-6 Stunden auf 1 Stunde reduzieren (2078 komninationen und wer weiß wie viele abfragen)

Meien Frage an euch:

Wie kann ich diesen ausreizen und optimieren? Was sind eure Tipps und Tricks?

Ist es unbedingt erforderlich nach der veränderung der DefaultDbCachePages die Datenbank zu sichern und zurückzuspielen um die Caches zu verbessern?

Danke für eure Hilfe!!

[mquadrat]

Ich meine hier gab es letzt mal einen passenden Thread. Schon die Foren-Suche verwendet? Ansonsten kannst auch mal auf den Seiten von HK schauen (Hersteller IBExpert). Aber ich denke mal, Holger wird sich hier eh noch melden. ;)

[Nersgatt]

Was für Festplatten hast Du verbaut?
SSD-Platten bewirken bei einer Firebirddatenbank Wunder.

[hoika]

Hallo,

Schau dir mal den RAM-Verbrauch des Servers an.
Für Win-Server 2008 gibt es einem Patch, falls der RAM kontinuierlich ansteigt.
Die Endung der DB sollte nicht GDB sein.
Was läuft überhaupt für eine DB-Variante (Superserver, Classic).
Es gibt noch einen DB-Monitor von HK-Software,
der jeden SQL-Befehl mitprotokolliert?


Heiko

[hoika]

Hallo,

hier noch ein paar Infos zum Patch

http://dyemanov.blogspot.com.br/2012...m-caching.html

Heiko

[hstreicher]

ein paar mehr Infos wären nutzlich

welcher Server: Superserver Superclassic Classic ?

Pagesize der Datenbank

Anzahl der Benutzer

Größe des Stripesets des Raids

Größe der DB

Sie Schreiben :
DefaultDbCachePages = 131072 gespielt.
Mit auskommentieren und erhöhung auf 1024

1024 ist weniger wie 131072 , was wurde hier erhöht ?

mfg H Streicher

[csaeum]

Also ich versuch mal hier die Infos die ihr noch braucht bereitzustellen:

RAID 10 aus 4 SATA Festplatten, welche genau kann ich leider jetzt nicht sagen. Aber ich habe darauf geachtet das diese 24/7 sind und viel Cache haben.

Anzahl der Benutzer derzeit nur ich, weil so wie es gerade vorsich geht, kann ich noch nicht produktiv gehen. Später sind es dann ca 15 User.

Der Firebird ist derzeit als superclassic als Dienst installiert.

Zu den DefaultDbCachePages:

Zuerst war es kommentiert als deaktiv bzw Standard, hier hat es 5-6 Stunden gedauert. Nach ein paar Recherchen auch hier im Forum habe ich es auskommentiert und auf 1024 erhöht. Da wurde es besser. Leider kann ich nicht mehr sagen als welcher Server der Dienst installiert war.

An SSD Platten habe ich auch schon gedacht. Aber ich denke und vermute mal das man das auch mit den Platten schonmal schneller hinbekommt.

Wie bekomme ich die Pagesize der Datenbank raus?

[mkinzler]

Zitat:

Wie bekomme ich die Pagesize der Datenbank raus?

Code:

gstat <Datenbank> -header

oder

Code:

SHOW Database

in isql

[csaeum]

Anbei die Infos von gstat
Database header page information:
Flags 0
Checksum 12345
Generation 31061
Page size 16384
ODS version 11.2
Oldest transaction 25894
Oldest active 25901
Oldest snapshot 25899
Next transaction 31038
Bumped transaction 1
Sequence number 0
Next attachment ID 17
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Oct 2, 2014 10:05:37

Variable header data:
Sweep interval: 20000
*END*

[mkinzler]

Es scheinen die Transaktionen nicht richtig abgeschlossen zu werden. Es besteht mindestens eine langlaufenden offene Tranaktion, wahrscheinlich noch viel mehr.

Btw.: Warum Dialect 1? Der besteht nur aus Kompatibilitätsgründen zu alten Interbaseversionen.

[csaeum]

Wieso weshalb warum Dialect1 darfst du mich nicht fragen. Das hat die Firma Vario zu verantworten?

Das langlaufende offene Tranaktion waren kann ich bestätigen.

Nach fast 24h hat er einen Job immernoch nicht fertig gemacht gehabt und ich habe dann abgebrochen.

Darum nun auch der Thread hier. Laut meinen Recherchen denke ich mal das ihr mir helfen könnt. Die Firma Vario meinte ja ich sollte bis November warten erst dann hätte der "Firebird Spezialist" Zeit für uns.

[mkinzler]

Zwischen der nächsten gestarteten und der ältesten Transaktion liegen 6000 Transaktionen. Da ist wirklich etwas faul. Bei einem Vorgang sollten keine 6000 Tranaktionen gestartet werden. Zudem sieht es aus, als ob diese nicht abgeschlossen werden. Viele offene Transkationen sind Gift für Firebird. Man solte sich die Abfragen mal ansehen.

[tsteinmaurer]

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

[csaeum]

Danke tsteinmaurer

du sprichst mir aus der Seele, ich bin ja im IT Bereich nicht unerfahren aber mit Firebird steck ich in den Kinderschuhen.

Das man mit SSD erstmal verschleiert unterschreibe ich dir.

Wie würdet ihr nun vorgehen. Die Tools sagen mir erstmal alle nichts und auch nicht wie man diese handhabt. Wie sollte man die Caches einstellen usw damit man erstmal mit den Teil wirklich weiterarbeien kann. Da es eine ERP ist und wir derzeit 2 Artikel mit jeweils 2078 Kinderartikeln haben sollten die erstmal in den Shop hochgeladen werden. Dazu hat er zuletzt in 24h es nicht geschafft.

Wir sind hier am Anfang und wenn wir es so durchziehen muss er später auch mal 100 Artikel mit jeweils 2078 Kinder hochladen können. Ich denke hier müssen die Caches noch besser werden damit er schneller wird. Beim erstellen dieser konnte ich ja auch schonmal was rausholen wie im 1. Post.

Was sollte man erstmal nehmen Super - Classic oder SuperClassic?

Was empfiehlt ihr? Weil dann kann ich die Caches mal optimieren. Falls ihr hier eine empfehlung habt wäre ich auch dankbar.

Gruß und Danke schonmal an allen hier in der Runde

chris

[Blup]

Die Ursache der Geschwindigkeitsprobleme scheinen mir eher auf Seite der Anwendung zu liegen. Das kann verschiedenste Ursachen haben. Von der Struktur in der die Daten erfasst sind (z.B. in welche Kategorie bestimmte Artikel gehören, Einstellungen wie diese bei der Kalkulation zu berücksichtigen sind, usw.) bis zu Schwächen beim Entwurf der Datenbankstruktur. Letzlich kann nur der Hersteller der Software den Support liefern. Wenn schon jetzt in der Einführungsphase kein ausreichender Support geliefert werden kann, wie soll das erst bei Störungen im laufenden Betrieb funktionieren? ERP-Systeme gibt es reichlich am Markt, da sollte man sich die Frage stellen, ob man die richtige Entscheidung getroffen hat und welche Alternativen zu diesem Zeitpunkt noch bleiben.

[tsteinmaurer]

@csaeum: Ich kenn das ERP nicht, noch was eine "Variante" in diesem ERP ist. Solange man das Problem nicht eingrenzen bzw. genauer beschreiben kann, werden wir hier in einem öffentlichen Forum keine Chance haben dir zu helfen. Wie ich vorher schon geschrieben habe liegt es meistens an der Anwendung, einem schlechten physischen Datenmodell (fehlende Indizes ...) etc.

Aus meiner Sicht kannst du ohne der Unterstützung des Herstellers folgendes machen:

• Benchmarking deiner Storage, ob vielleicht was mit dem RAID (Controller) ist.
• Sofern du Firebird 64-bit verwendest, bei SuperClassic bleiben. Wenn Firebird 32-bit (z.b. durch Limitierung einer Third-Party UDF Library), dann Classic.
• Page Buffers auf Datenbankebene auf 2048 setzen. Geht mit dem gfix tool.
• LockMemSize und LockHashSlots in firebird.conf um einen Faktor 10 erhöhen. LockHashSlots sollte eine Primzahl sein, d.h. entsprechend geringfügig auf/abrunden. TempCacheLimit in firebird.conf auskommentieren, damit die ca. 64MB greifen. => Danach ist ein Restart des Firebird Dienstes notwendig.
• FB TraceManager runterladen (http://www.upscene.com/fb_tracemanager/) und via Monitoring Tables und der Trace API schaun, welche Statements wieviel brauchen. Mit der Trace API bekommt man dann auch ev. ein Gefühl wie so der Ablauf im ERP für einen "Geschäftsprozess" Firebird-seitig ist

Sofern die ersten 4 Punkte nicht den erwarteten Erfolg bringen, dann läufts im Prinzip darauf raus, dass man mit dem Monitoring dem Hersteller die Hotspots/Probleme aufzeigt. Spreche hier aus Erfahrung ...

Ich hoffe, dass dir das jetzt konkret genug war. :thumb:

[csaeum]

Danke tsteinmaurer

das ist mehr wie ich gedacht habe:
Ich habe nun die DefaultDbCachePages = 2048 gesetzt.
Nun muss ich noch die Buffers auf 2048 setzen. Kann ich das im laufenden Betrieb machen?

Code:

gfix.exe -buffers 2048 DB

Werde mal berichten wie es läuft.

[tsteinmaurer]

DefaultDbCachePages = 2048 in firebird.conf wird nur dann verwendet, wenn auf Datenbankebene Page Buffers = 0 ist. Wenn du aber den Wert auf Datenbankebene mit gfix setzt, dann kommt der Default in firebird.conf nicht zum Zuge. Aber da du beide Werte gleich setzt ist es egal. ;-)

Ja, du kannst den Page Buffers mit gfix während des Betriebs setzen, aber diese Änderung wird erst für neue Connections wirksam, d.h. bestehende Connections bleiben davon unbetroffen.

[IBExpert]

Moin,

kleine Anmerkungen aus meiner Sicht:

SSDs bringen gerade bei Firebird immer Vorteile, die man auch durch optimierte Programmierung nicht aufholen kann. Wir gehen aber eh davon aus, das man nicht irgendwelche sinnlosen SQLs auf die Datenbank loslässt, wobei das natürlich in erster Linie in der Verantwortung des Softwareherstellers liegt. Man sollte aber zuverlässige Enterprise SSD Hersteller setzen, die auf eine Schreibleistung und Haltbarkeit garantieren, dann aber trotzdem regelmäßig die SSD gegen neue austauschen. So ähnlich wie ein Ölwechsel beim Motor.

Wir bekommen regelmäßig Rückmeldungen durch den Benchmark in der IBExpert Vollversion, die einen realen Firebird Datenbanktest abbildet mit 10 parallelen
Threads. Man bekommt am Ende 2 Messwerte, einen für Firebird mit extrem kleinem Cachebuffer=50 und einen für normale Einstellung =5000
Den mit 50 Buffers nennen wir Drive Index, weil dabei hundertausende Pages von der Platte gelesen oder wieder zurückgeschrieben werden, bei der größeren Einstellung
passiert kaum was auf der Platte, daher ist da in erster Linie Anbindung CPU/Mainboard/Ram wichtig, den Wert nennen wir CPU Index.

Aktuelle Standardwerte liegen bei den Kunden zwischen 5 % und 40 % der Leistung, die unser IFS Referenzserver vor 4 Jahren hatte und die wir daher auf 100% referenziert haben. Der aktuelle IFS Basic Referenzserver hat einen Driveindex von mindestens 250% und einen CPU Index von mindestens 150%, Kostenpunkt dafür bei uns ab ca. 1500 €, ausgelegt für bis zu 100 User und bis 50GB Datenbankgröße.

Oder mit anderen Worten: Der gleiche Test, der auf der Maschine mit 5% Leistung 1000 Sekunden braucht, läuft auf dem aktuellen Server in 20 Sekunden durch.

Wenn du das auch mal testen willst und schon eine aktuelle IBExpert Vollversion hast, findest du das unter services - Benchmark

Wir schalten dir ggf auch gerne mal eine Tageslizenz kostenlos frei, damit kannst du den Wert auch ohne aktuelle IBExpert Vollversion ermitteln (Anfrage dafür gerne an [e-mail], Ihr braucht dafür aber einen kostenlosen Account in unserem Downloadcenter).

Sehr wichtig: im Benchmark als Connectionstring immer einen Remotestring angeben, also mit servername: davor, ggf auch localhost: , sonst verfälscht der Test das Ergebnis.
Ale angezeigten Ergebnisse, neben denen nicht Drive Index oder CPU Index steht, sind Zeiten in Sekunden.

Wichtige Erkenntnisse aus dem Benchmark:

Der Classic bzw Superclassic Server ist meistens langsamer. Ursache: Firebird Datenbankoperationen sind 99% reine Byteschubserei und die CPU Berechnungen sind relativ lächerlich, so das mehrere Kerne kaum vorteile bringen, sondern meistens Nachteile, denn der Benchmark verursacht auf dem Superserver ca. 14 GB Lese und Schreib Operationen und auf dem Classic bzw Superclassic ca. 37 GB Lese und Schreib Operationen. Da der Test 100% reproduzierbar ist ist das auch überall nachvollziehbar und man sieht im Taskmanager, wie schnell die Bytes gelesen und geschrieben werden.

Wenn du nun auf einer Festplatte 100MB Lese und Schreibleistung pro Sekunde hast, wirst du dir einfach ausrechnen können, warum die SSDs mit bis zu 600MB pro Sekunde schneller sind. Da auch noch die Datenträgerlatenz dazu kommt (schnelle Festplatten haben 5ms durchschnittliche Zugriffszeit=200 IOPS, brauchbare Enterprise SSDs haben 50000 IOPS oder noch mehr) und die aufgrund der Schreibweise des Firebird Systems extrem wichtig ist, wirst du auch hier eine wichtige Unterscheidung feststellen. Und lass dich nicht täuschen, RAID Controller (auch mit SSDs dahinter) sind für Firebird meistens deutliche Bremsklötze, externe Storagesystem machen das ganz noch schlimmer (viel mehr Details gibt es dazu auch bei uns in der Profiworkshops).

Wenn du den Benchmark ausführst und in der CPU nahezu keinerlei Last sehen wirst, ist der Grund sehr einfach: Die CPU wartet auf den lahmen Datenträger.

Sehr interessant dagegen: Der IBExpert Benchmark mit Firebird 3.0 ist ca. 25% schneller als der benchmark mit Firebird 2.5. Es ist bei FB3 also wirklich noch mal ein Leistungsschub zu erwarten, wenn man Multiusermessungen macht. Im Singleuserbetrieb wird das aber kaum feststellbar sein, ist aber eigentlich auch unter fb25 schon schnell genug, wenn man nicht unsinnige SQLs ausführt oder bescheuerte Datenbankstrukturen hat.

[tsteinmaurer]

Hallo Holger,

Kurze Anmerkung zu:

Zitat:

Den mit 50 Buffers nennen wir Drive Index, weil dabei hundertausende Pages von der Platte gelesen oder wieder zurückgeschrieben werden

Der Filesystem Cache vom Betriebssystem ist auch noch da, d.h. ein Read/Write in der Firebird Statement I/O Statistik bedeutet nicht notwendigerweise ein echtes lesen/durchschreiben von/auf die (rotierende) Disk.

Man kann aber Firebird mitteilen, dass man keinen Filesystem Cache verwenden möchte, was bei vergleichbaren Benchmarks wo man sich mit dem PageBuffers Wert spielt, durchaus ratsam ist.

LG

[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.