AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Fragen bezüglich Performance von Firebird in einer Anwendung
Thema durchsuchen
Ansicht
Themen-Optionen

Fragen bezüglich Performance von Firebird in einer Anwendung

Ein Thema von TK8782 · begonnen am 8. Aug 2019 · letzter Beitrag vom 15. Aug 2019
 
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#4

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 06:22
Ich würde das etwas differenzieren.

Hardware
Einfache Rechenbeispiele: Wenn ich eine quad core CPU gegen eine octa core austausche, wie viel schneller wird dann mein Programm (unter Idealbedingungen)? Doppelt so schnell. Umgerechnet auf Wartezeiten: Aus 10 Sekunden Warten, werden 5 Sekunden.
Das kann man für alle Hardwarebestandteile durchexerzieren. Die Rechnung ist immer die gleiche.

Software
Algorithmen können gut oder schlecht, passend oder unpassend sein. Das gilt für SQL, für Floating Point Arithmetik aber auch für Units und Komponenten (in Delphi). Optimierungen sind hier oft viel weitreichender möglich und bringen Faktoren, die Du mit (bezahlbarer) Hardware nicht ohne weiteres erreichen kannst.

Also ja, man muss sich die Anwendung anschauen. Auch wenn Du es nicht beschrieben hast, Du wirst wissen, wo der Schuh drückt. Eine generelle Sache oder bestimmte "unangenehme" Ecken der Anwendung...
Bei einer Client Server Anwendung spielen natürlich auch Netztopologie und Auslastung, -Konfiguration eine Rolle.
Ich hatte noch nie den Bedarf eine Delphianwendung an den Paketscanner zu hängen, aber ja, sie arbeitet (im Datenbankverkehr) vollkommen anders als eine Webanwendung. Es wird viel hin und her geschickt. "Früher" war die Herausforderung, eine Anwendung notfalls über ISDN laufen zu lassen. Klingt vielleicht bescheuert, aber es geht und in solche Richtungen muss man immer denken, wenn man evtl. unbekannte/fremde Komponenten einsetzt oder ein koplexes Datenmodell anlegt bzw. abfragt. Was auf dem Entwicklerrechner geht, ist in der "Wildbahn", also z.B. Firmennetz mit 100en Clients und "Konkurrenzprogrammen" dann halt doch was anderes.

Anwendung
Oft sind es einfach noch relikte aus BDE Zeiten. Da wurden Tabellen einfach geöffnet. Geht anfangs immer prima, wenn sie so gut wie leer sind. Aber das bleibt ja im Normalfall nicht so. Auch wenn sich nur ein paar Tausend Datensätze ansammeln, das kann man hochrechnen mit der Anzahl der Clients. Jedes Schließen/Öffnen zieht dann eben immer wieder ein paar Tausend Datensätze.
Auch wenn man einen SQL Server einsetzt, bedeutet das nicht, dass SQL als Abfragesprache zweckmäßig und Ressourcen schonend eingesetzt wird.


P.S.:
Datenbank
Es ist sicher hilfreich, die aktuellste Version einzusetzen (Stichwort Sprachfeatures). Um die dann zu nutzen, muss man natürlich trotzdem an die Anwendung ran. Außerdem ist es so, dass natürlich der Hauptspeicher als Buffer eingesetzt werden sollte, soweit wie möglich (wenn nicht ständig nur Updates gefahren werden und nie ein Stein auf dem anderen bleibt)
Bei heutigen RAM Ausstattungen ist die DB ja manchmal kleiner als der Hauptspeicher. Hat man in der Konstellation Performance Probleme, würd ich eher auf Netzauslastung bzw. unnötige (unnötig große,~undifferenzierte) Datenabfrage tippen.
Gruß, Jo

Geändert von jobo ( 8. Aug 2019 um 06:40 Uhr)
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:07 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz