Firebird Geschwindigkeit

[Delix]

Hallo zusammen!

Ich habe ein Problem mit Firebird (1.5.5). Um die Geschindigkeit zu optimieren, haben wir ein kleines Testprogramm geschrieben, welches 1000 Select-Anweisungen ( ca. 50 Spalten, jeweils eine Zeile ) durchführt.

Auf einem Rechner benötigt das System 48 Sec., auf einem anderen, etwas leistungsstärkeren, dauert es 2 Min. 6 Sec. Beide Rechner greifen über das selbe Netz auf die selbe Datenbank zu. Der schnellere Rechner hat eine Netzwerkauslastung von ca. 10 %, der langsamere ca. 5 %. Das ist sogar logisch, aber was kann die Ursache sein. bzw. was ist zu tum?

Schöne Grüße

[neo4a]

Versuche die einzelnen Komponenten zu separieren und dadurch herauszufinden, an welchen Prozess es überhaupt liegt.

Dazu würde ich als erstes auf die DB lokal per embedded Firebird zugreifen. Damit eleminierst Du den ganzen Netzwerk-Teil (Switch, priorierte Netze, Serverauslastung durch andere Prozesse etc.). Als nächstes würde ich mit einem Profiling- oder Monitoring- Tool die einzelnen Abfragen verfolgen. Nun kenne ich Zeos nicht, benutze bei IBO dafür die mitgelieferte Monitor- Komponente.

--
Andreas

[alzaimar]

Nach jedem SELECT ein 'rollback' sollte die Performance drastisch steigern, auch wenn es sinnlos klingt.

[neo4a]

Zitat:

Zitat von alzaimar

Nach jedem SELECT ein 'rollback' sollte die Performance drastisch steigern, auch wenn es sinnlos klingt.

Wenn das ernst gemeint war, interessiert mich der Hintergrund. Auch dann, wenn es nicht die Antwort auf die Frage ist, warum bei 2 Rechnern eine Aktion/Abfrage unterschiedlich lange dauert.

--
Andreas

[borwin]

Sind die Statistiken in beiden Datenbanken identisch? Ggf. mal neu erstellen.

Gruß Borwin

[alzaimar]

Zitat:

Zitat von neo4a

Wenn das ernst gemeint war, interessiert mich der Hintergrund. Auch dann, wenn es nicht die Antwort auf die Frage ist, warum bei 2 Rechnern eine Aktion/Abfrage unterschiedlich lange dauert.

Firbeird arbeitet so (soweit ich das verstanden habe), dass jede Aktion in einer eigenen TRansaktion gestartet wird. Jeder sieht einen 'Snapshot' des jeweiligen Datenbankzustandes. Wenn ich *kein* Rollback (nach einem SELECT!) ausführe, wird Firebird immer langsamer, weil es mit jedem SELECT eine neue Transaktionsumgebung mitpflegen muss.

Es könnte wirklich sein, das der 2.Test deshalb langsamer ist (Wenn Du ihn nach dem ersten Test ausführst). Du greifst doch immer auf den selben DB-Server zu, oder? Treiberversion ist auch die Gleiche?

Wenn Du Rollbacks einbaust und gleiche Treiber dein Eigen nennst, wird's schwierig. Wenn es viele Daten sind, könnte aber die CPU/RAM-Architektur eine Rolle spielen. Aber das ist wirklich unseriöses 'ins Blaue raten'.

[tsteinmaurer]

Hallo,

bzgl. Rollback vs. Commit ist es genau umgekehrt. :-D

Lieber ein Commit als ein Rollback, wenn man es sich aussuchen kann (d.h. z.B. bei SELECTs, wo nichts geändert wird), da der OIT Counter per Definition die älteste nicht committete Transaktion ist. Die Engine ist zwar so clever, dass genau deswegen ein Rollback zu einem Commit gemacht wird, wenn das sicher ist.

An den Originalposter: Die DBs befinden sich auf einem Server oder (versehentlich) auf dem lokalen Rechner? Wie siehts mit Anzahl CPUs/Cores auf den Rechnern aus?

[Delix]

Es geht hier rein um ein Testprogramm zum Ermitteln des Geschwindigkeitsverhaltens der einzelnen Komponenten PC, Netzwerk, Server. Hier muss also nichts optimiert werden. Es ist tatsächlich die selbe Datenbank auf dem selben Server. In der Datenbank wird eigens für den Test eine Tabelle neu angelegt und gefüllt. Alle haben immer die selben Bedingungen. Die SQL-Anweisungen sind so aufgebaut, das ohne schwierige Suche jeweils die Daten gefunden werden ( SELECT * FROM TABELLE WHERE ID=x ). Der Flaschenhals dürfte hier das Netz sein. Es geht tatsächlich rein um die Frage, wie kann der Test auf einem PC 3 mal schneller laufen als auf dem anderen?

Bin für jeden Tipp dankbar

Schöne Grüsse

[fkerber]

Hi!

Gibt es vllt. Unterschiede in der Anbindung der Rechner?
100Mbit vs. 1000MBit?
Switch mehr dazwischen o.ä.?


Grüße, Frederic

[Delix]

Hallo!

Nein, kein Unterschied. Beide mit 100 MBit mit dem selben Umfeld. Auffällig ist halt, das ein Rechner 10% Netzlast hat, der andere nur 5 %. Beim Kopieren großer Dateien geht die Last voll hoch. Die Anzeige der Netzwerkauslastung wirkt wie gedeckelt - schön flach bei bei 5 %. Alle anderen Zugriffe gehen hoch.

Schöne Grüße
Hubert

[TeronG]

Haben die beiden Rechner auch den gleichen OS-Software-Stand? (SP's?)
Bei uns in der Firma ist das bei "Testrechnern" nicht immer der Fall. :roll:

[Delix]

Kein Unterschied, beide XP Prof. SP2.

Schöne Grüße

[neo4a]

Du charakterisierst die beiden Rechner mit unterschiedlichen Hardwareausstattungen und unterschiedlichen Zugriffsgeschwindigkeiten. Warum befolgst Du nicht den Tipp, und eleminierst erst einmal das Netzgedöns, indem Due den Zugriff und rein lokalen Bedingungen testest. Hast Du erst einmal sicher gestellt, dass Dein schnellerer Rechner lokal auch der schnellere ist, kannst Du Dich um den Netzwerkzugriff kümmern, wobei bereits hier die Netzwerkkartentreiber ein erster Ansatz sind. Das aber hat nun rein gar nichts mit Firebird zu tun.

--
Andreas

[Delix]

Zitat:

Warum befolgst Du nicht den Tipp, und eleminierst erst einmal das Netzgedöns, indem Due den Zugriff und rein lokalen Bedingungen testest.

Zur Erinnerung: Es geht um einen Test der Netzwerkgeschwindigkeit in Verbindung mit Firebird. Ob es da so hilfreich ist, den Netzzugriff zu eliminieren?

Schönen Gruß auch.

[fkerber]

Hast du mal die Netzgeschwindigkeit an sich überprüft mit diversen Tools?
Vllt. hat die Netzwerkkarte nen Knacks?

[Delix]

Klar, hab ich überprüft. Liegt alles im normalen Bereich. Wenn ich große Dateien hin und her schaufele, bekomme ich konstant eine Auslastung von 80%. Ich denke, das ist ok. Der Firebird Datentransfer wird auf 5 % begrenzt. Mich interessiert, warum das so ist.

Schönen Gruß

[neo4a]

Zitat:

Zitat von Delix

Zitat:

Warum befolgst Du nicht den Tipp, und eleminierst erst einmal das Netzgedöns, indem Due den Zugriff und rein lokalen Bedingungen testest.

Zur Erinnerung: Es geht um einen Test der Netzwerkgeschwindigkeit in Verbindung mit Firebird. Ob es da so hilfreich ist, den Netzzugriff zu eliminieren?

Du gehst davon aus, dass es so ist. Wenn aber der Client die Abfragen langsam produziert, kann der Server nicht schneller liefern.

Systematische Fehlereingrenzung würde ich so betreiben. Du dagegen hoffst wohl auf einen Treffer ins Schwarze beim Schuß ins Blaue...

--
Andreas

[hoika]

Hallo,

check mal den Traffic

1


Heiko

[mschaefer]

Möglicherweise ein suboptimal konfigurierten Router:

Status:
a.: große Dateien werden ausreichend schnell kopiert
b.: kleine Pakete, wie Firebird sie schickt werden sehr langsam übertragen.

mögliche Ursache:
Der Übertragungssaufbau dauert länger, was bei großen Dateien nicht ins Gewicht fällt. Ursache kann sein, dass ein Gateway
schlecht erreicht wird. Erst nach Übertragungssaufbau der Datenübertragung startet der Datenverkehr direkt zwischen den Rechnern.

Abhilfe bei obiger Ursache
Ein intensives Gespräch mit Eurem Admin bezüglich der Gateway- und Routerkonfiguration. Oft hilft bei sowas auch das Nachinstallieren
von NetBios als Netzwerkprotokoll von der XP-CD als AddOn. Nach einiger Zeit haben die Rechner dann die MAC-Adressen der Gegenstelle
auf dem am besten erreichbaren Rechner zwischengepuffert, was den Übertragungsaufbau deutlich beschleunigt. Ein zusaätzliches Protokoll
belgegt aber immer auch LAN-Volumen, daher sollte dies der Weg sein, wenn aus anderen Gründen die Gatewayerreichbarkeit nicht verbessert
werden kann.


Grüße in die Runde // Martin

[Delix]

Netbios installieren hat nichts gebracht, ausser, dass der Test geringfügig länger dauert.

Allerdings wird es langsam unübersichtlich! Wir haben mit verschiedenen Rechner getestet und festgestellt, das die Netzwerkkarte offensichtlich starken Einfluss hat. Wir haben einen Uralt-Rechner mit Win2000, welcher die Selects aus der DB deutlich schneller abhandelt als ein aktueller AMD X2.
In einen Rechner mit Onboard Netzwerk-Anschluss, der für den Test 2 Minuten benötigt, haben wir eine separate Netzwerkkarte eingebaut. Benchmarktests weisen für diese Karte einen ca. 10% höheren Datendurchsatz aus als für den Onboard-Anschluss. Die Zeit für den Firebird Select-Test hat sich auch verändert: Mit der externen Karte ist sie doppelt so lang, nämlich 4 Minuten.

Vor dem Einbau der externen Karte wurde die Netzlast während des Tests mit ca 5% angezeigt, nachdem die externe Karte wieder entfernt ist, zeigt das System eine Netzlast von 11% an. Der Test ist aber trotzdem nicht schneller. Ich kann mir nicht helfen, aber irgendwie fehlt mir da die Logik.

Viele Grüße
Hubert

[mschaefer]

Moin, moin,

Wenn NetBios da nichts bringt ist das Gateway-Problem ausgeschlossen. Am besten wieder Deinstallieten.

Habe mehrere kleine Netzwerke mit Firebird als Datenbank am laufen und hier hat sich gezeigt, das 1-GBit-Karten bei kleinen Paketen deutlich flotter waren. Bei großen Datenmengen brach das seltsamerweise dann öfters ein. Richtig spannend wird es wenn man Karten verschiedener Hersteller mischt. So ganz genormt ist das dann doch nicht. Am besten einen Satz eines Herstellers. Und alle 10MBit-Karten aus dem Netz verschwinden lassen, die bremsen auch wenn Sie nur im Netz mithören.

Am Kartentreiber kann man kontrollieren ob die im -Duplexmode- alle auf "Full autonegotation" stehen. Manchmal haben die Treiber auch eine Einstellung -Optimze for- sollte auf "Througput" stehen. Ist nur eine anders konfiguriert, dann wird es prinzipbedingt langsamer.

Aber Deine Zeiten sind so unterschiedlich, dass hier auch noch was anderes mit im Busch liegen kann.
Es gibt für Firebird den FBConfigManager. Mit dem kann man die TCPRemoteBuffBufferSize am Firebird-Server einstellen.

Es bleibt jedenfalls spannend. Grüße // Martin

[DelphiBandit]

Wir haben im Prinzip das gleiche Problem, wie es hier bisher beschrieben wurde. Deshalb habe ich den Thread mal wieder nach oben geholt, in der Hoffnung es hat hierzu jemand vielleicht neue Erkenntnisse gewonnen.

Wir haben zwei fast baugleiche Maschinen, E8400 Core2Duo. DB ist Firebird SuperServer 1.56, eine mit XP, die andere mit Server 2008R2 x64. Die Datenbank ist ca. 500 MByte gross, gecached werden 10000 Pages a 8192 Byte, also fast 1/5 der gesamten DB.

Alle Queries sind prepared und werden innerhalb der Schleifen-Abfragen mit Parametern versorgt. DB-Zugriff über IBObjects.

Lassen wir den einen Programmpunkt zum Zusammensuchen von Daten lokal, egal auf welcher Maschine laufen dauert das ca. 1 Sekunde. Geht der Zugriff über Netzwerk, dann dauert es ca. 17 Sekunden (100 MBit, 2% Netzwerklast). Umstellung auf GBit ca. 9 Sekunden bei 0,58% Netzwerklast. Grosse Dateien zwischen den Rechnern hin- und herkopieren - ca. 40 MByte / Sekunde bei 80% Netzlast

Was ich bisher schon alles probiert habe:
- Diverse Parameter in der firebird.conf (Cache / PageSize / Affinity etc.)
- Datenbank auf dem Server auf eine RAM-Disk packen, kein Unterschied!
- Umstellung der gesamten DB mit Backup/Restore auf Firebird 2.5 RC2 SuperClassic x64, genauso langsam
- Switch rausnehmen und beide Rechner per Crosslink direkt verbunden
- Langsameren Server (Notebook mit Pentium M760), dauert es ca. 20 Sekunden
- Beide Karten hart auf 1GB Fullduplex umgestellt
- google bis zum Abwinken befragt, aber nichts Stichhaltiges dazu gefunden

Was mich daran erschreckt ist das dümpelnde Netzwerk, warum kann der FBServer-Prozess die Daten nicht schneller an den Client schicken? Lokal schnellt die CPU-Last auf dem einen Kern auf fast 100% hoch und die Antwort der Daten erfolgt fast verzugslos.

Ich habe so den Eindruck als kann/will/darf der DB-Prozess die Daten nicht schneller bei der Netzwerkkarte abliefern? Der FBServer-Prozess dümpelt übrigens genauso vor sich hin und kommt nicht über 5% CPU-Last hinaus.

Hat jemand von Euch dazu etwas herausgefunden oder ggf. noch einen Tipp was ich übersehen haben könnte?

[mkinzler]

Tunnele mal den Zugriff mit Zebedee oder stunnel

[Blup]

Netzwerklast hat nicht unbedingt etwas mit der Latenzzeit zu tun, die zwischen Absenden eines Datenblocks und dem Empfang dieser Daten auf der Gegenseite vergehen.

Bei einer reinen Dateiübertragung werden die Datenblöcke hintereinander abgesendet, ohne auf eine Bestätigung zu warten.
Erfolgt nach einiger Zeit keine Empfangsbestätigung für einen Block, wird dieser noch einmal gesendet.

Code:

Zeitlinie ----------------------------->

Sender    -1-2-3-4-5-6-7-8-9-----------

Empfänger ------1-2-3-4-5-6-7-8-9------

Antwort   -----------1-2-3-4-5-6-7-8-9-
beim Sender

Bei einer Datenbankabfrage wird die Anfrage abgesendet und auf die Antwort des Servers gewartet, erst danach erfolgt die nächste Abfrage. Entsprechend gering ist die Netzauslastung.

Code:

Zeitlinie ----------------------------->

Sender    -1-----------2---------------

Empfänger ------1-----------2----------

Antwort   -----------1-----------2-----
beim Sender

[DelphiBandit]

Hab ich gerade mal ausprobiert. Bis ich dann mal drauf kam, dass ich am Client für den Connect localhost/PortFürZeBeDee eingeben muß - hat einen Moment gedauert :D

Genauso langsam - über GBit ca. 10 Sekunden für das Zusammensuchen. zebedee hat ca. 4-5% CPU Last. Der FBServer als Spitzenwert 7%. Das Netzwerk dann jetzt noch weniger - so ca. 0,36% - welch wahnsinnige Belastung!

OK, Blup - das leuchtet mir ein. Zum Teil. Weil eigentlich könnten sie sich das bestimmt viel schneller bestätigen. So haben sowohl das Netzwerk, als auch der FBServer, als auch die Anwendung die ganze Zeit nichts zu tun - alle deutlich im einstelligen CPU-Bereich. Während er lokal abgeht wie eine Rakete. Irgend woran muß es da doch haken?

[Alfredo]

Also Wireshark ist in solchen Fällen immer eine gute Hilfe.

Onboard-Netzwerkkarten bestimmter Hersteller sind auch eine bliebte
Fehlerquelle.

Die Festplatten des Servers können ebenfalls ein Flaschenhals sein.

100 Mbit und Geschwindigkeitstest bei den heutigen Hardwarepreisen?
Die zentralen Switche sollten zumindest 1000 Mbit sein.

Ich lese gerade SuperServer.
Man sollte klären ob nicht der CS sinnvoller wäre.

Upgrade auf 2.xx schon in Erwägung gezogen?

Gruß
Alfred

[juergen]

Hallo zusammen,

bei unseren Kunden haben wir auch oft Probleme bezüglich Geschwindigkeit (allerdings bei einem anderen DBMS).
Hauptproblem waren bis jetzt fast immer die Virenscanner.
Leider reicht ein "abschalten" der Virescanner i.d.R. oft nicht aus, da irgendwelche Dienste weiterlaufen.
Wir weisen unsere Kunden meistens nach, dass es am Virenscanner liegt.
Der Kunde entscheidet dann selbst über Ausnahmen beim Scannprozess...
(Ich hatte in diesem Thread noch nichts über Virenscanner gelesen, daher mein Post. Wenn ich etwas überlesen habe... :arrow: :oops:)

Weiterhin hatten wir bei einer bestimmten Benutzergruppe ("authentifizierte Benutzer" o.ä.) in den NTFS-Freigaben Zeitprobleme., wenn bei der Freigabe unter dem Reiter "Sicherheit" diese Benutzergruppe hinterlegt war.
Hat man dann direkt den Benutzer mit hinterlegt, waren bestimmte Zugriffe wesentlich schneller. Das war allerdings ein Einzelfall...

[mkinzler]

Hast du be Zebedee Kompression aktiviert?
Wie ist die Endung der Datenbankdatei?

[DelphiBandit]

@Alfredo

Leider haben unsere Kunden aber teilweise nicht die Netzwerk-Infrastruktur für GBit-LAN, weil uralte Verkabelung in den Wänden :( Somit gehe ich bei meinen Tests hier vom "Worst-Case" aus. Wie mein Test zeigt wird es zwar mit GBit auch schneller, aber die Netzwerklast geht von 2% auf ~0.58% zurück. Rechnerisch dann aber immer noch schneller.

Firebird 2 habe ich ebenfalls getestet (s.o. 2.5 RC2) als SuperClassic. Kein Geschwindigkeitzuwachs, keine schnelleren Antworten. Bei meiner Single-Client Testreihe hier sollte der SuperServer wegen der grösseren CacheSize deutlich die Nase vorne haben.

Netzwerkkarten sind in beiden Rechnern Intel 82567 GBit Onboard in Fujitsu-Rechnern.

@juergen

Guter Tipp: Habe den Virenscanner-Dienst zu Testzwecken mal abgeschaltet. Win-Firewalls sind aus, Desktop-Fw ist nicht installiert.
Die Abarbeitung der gesamten Abfrage beschleunigt sich von vorher 9 Sekunden auf jetzt 5 Sekunden. Ich will aber mal schauen, wie sich das im Laufe des Tages entwickelt, da im Moment es hier im Hausnetzwerk noch relativ ruhig ist. Kann allerdings der einen Sekunde lokal noch nicht das Wasser reichen.

@mkinzler
Ja, Komprimierung war mit -z bzip2:9 volle Pulle eingeschaltet. Die Rechner sollten hoffentlich genug Power haben die kleinen Pakete in Echtzeit zu packen. Dauert annähernd genauso lange ~9 Sekunden.

Und Endung ist .gdb - historisch gewachsen, da vorher mal Interbase-DB. Allerdings ist es nicht das *.GDB Restore-Problem. Die filelist.xml ist von <GDB> befreit und auch die Systemwiederherstellung ist auf beiden Maschinen ausgeschaltet.

[Alfredo]

Wenn zumindest Cat5e installiert ist, kann man mit Spezialswitche(Kupfer) die 1000 MBit
fahren.

Ich würde mal einen anderen Servertyp ausprobieren(Linux_32 mit Samba).
Der 2008 scheint so einige Macken zu haben.

Der Firebird 2.5 hat eine neuere Technik die angeblich schneller sein soll.
Er hat wohl aber auch so seine Probleme.
Bin mit meinem 2.03CS mehr als zufrieden.

Schon mal mit Wireshark den gesamten Netzverkehr angeschaut und alle Quatscher
eliminiert? Du wirst staunen was da alles rumsaust.

Ich würde dein Problem mal in der Firebird Mailingliste absetzen.
Dort sind die absoluten Firebird-Gurus(Helen Borrie oder Dimitry Sibiryakov) unterwegs.

Gruß
Alfred

[Blup]

Wie lange dauert ein Ping und wie viele Anfragen werden insgesamt nacheinaneder an den Server gesendet?
Bei 1000 Anfragen summiert sich auch eine Millisekunde.

Ich würde Netzwerkkarten von IBM verwenden (wenn ich mir die leisten könnte).
Billige insbesondere OnBoard-Karten sind wahrscheinlich nur für große Datenmengen, aber nicht für schnelle Antwortzeiten optimiert.
Ob 100 oder 1000 Mbit ist dann schon fast egal.

[DelphiBandit]

Zitat:

Zitat von Blup

Wie lange dauert ein Ping und wie viele Anfragen werden insgesamt nacheinaneder an den Server gesendet?

Also ein "ping Rechnername -l 65500", also 64 kByte Buffer, dauert ca. 1 ms. Alle kleineren Pakete < 1ms und durch DOS-Ping nicht genauer zu bestimmen.

Überschlagen werden zum Zusammensuchen der Daten folgende SQL's und Datenmengen abgesetzt:

Grundmenge suchen - Rückgabe 350 Integer
Obertabelle - 350 Datensätze (ca. 15 Felder) mit prepartem SQL
2 x Untertabelle hiervon mit Indizes, einmal mit SP, einmal als SQL, also nochmals ca. 700 Abfragen, Anzahl ~2000 Treffer

Ich habe mal den Wireshark angeschmissen und geschaut, wieviel da so pro Datensatz über das Netz fliesst (Port 3050). Waren auf jeder der vier Ebenen so um die 10-15 kByte pro Abfrage. Hab erst den Fehler gemacht das mit IBExpert zu testen, der braucht 250 kByte weil er jede Menge Systemtabellen ausliest, danach dann mit Flamerobin getestet.

Das summiert sich auf - komme alleine bei den Untertabellen auf ~30 MByte, wäre bei optimalem GBit LAN ca. 1/2 Sekunde. Aber anscheinend ist es der Paket-Overhead und die kleinen Pakete. Aber die Netzwerkschnittstelle wird ja überhaupt nicht ausgenutzt, das ist das was ich daran nicht verstehe - sie könnte ja viel mehr Daten, bzw. schneller, da rein übertragen.

[Blup]

So einfach kann man aus 700 Abfragen 2 machen:

SQL-Code:

select *
from   master
where  (bedingung = :bedingung)


select    d.*
from      master m
left join detail d on d.master_id = m.id
where     (m.bedingung = :bedingung)

[Alfredo]

Die Switche sind von welchem Hersteller?

Festplatten von welchem Hersteller?

IDE oder SATA?

RAID auf dem Server mit onbard-Controller?

Feste IP-Adressen?

Mit dem Wireshark solltest du auch im Leerlauf prüfen,
was da auf deinem Netzwerk passiert.
Nicht dass da z.B. Netbui, Netwerkdrucker, Printerserver ihr Unwesen treiben.


Gruß
Alfred

[DelphiBandit]

Zitat:

Zitat von Blup

So einfach kann man aus 700 Abfragen 2 machen:

SQL-Code:

select *
from   master
where  (bedingung = :bedingung)


select    d.*
from      master m
left join detail d on d.master_id = m.id
where     (m.bedingung = :bedingung)

Das weiss ich wohl :) Ich habe vorhin auch überlegt, wie ich das ganze Zusammensuchen in eine - z.B. grosse SP - auslagern kann. Problem daran ist momentan nur, dass ich dann auch den ganzen Hintergrund wozu die Daten im Endeffekt benötigt werden, auf diesen Gruppenwechsel umprogrammieren muss. So ergibt er sich momentan durch die Datensätze in der Haupttabelle von alleine und in den inneren Schleifen werden die Detaildaten gesucht.

Ich werde morgen auf jeden Fall mal versuchen, wie lange es dauert die Daten in einem Rutsch über's Netz abzurufen und so zu tun als arbeite ich sie ab. Wenn das ein absolutes Plus bringt, muß wohl der Ablauf angepasst und mit Hilfsvariablen der Gruppenwechsel durchgeführt werden.

Switch ist von Netgear / Karten wiegesagt mit Intel OnBoard Chip. Auf dem Netz ist jede Menge los bei uns, aber es wurde ja auch mit einem Cross-Link-Kabel und den beiden PC's direkt aneinander gestöpselt nicht schneller! Also denke ich eher nicht an Fremdeinwirkung durch das Netz. Platte ist Hitachi 160GB SATA ohne Raid, die lokal von Platte auf Platte ca. auf 50 MB/Sekunde kommt. Feste IP's im Netz.

[Alfredo]

Normaler Weise würde ich sagen Hardware ok.

Folgende Hinweise noch:

Ich hatte mir die Intel-NIC gegönnt und die sind zwischenzeitlich alle
den Hitzetod gestorben. Keine Ahnung warum. Angeblich steht da Intel
drauf und es handelt sich trotzdem um B-Ware.

Auch auf Netgear-Switche habe ich viele Jahre geschwört.
In letzter Zeit legt jedoch immer wieder einer die Ohren an.

Mein Arbeitsrechner hat derzeit eine PCIE von Allnet und einen Allnet Switch
und Ruhe ist im Laden.

Es schadet auch nicht, in der Computerverwaltung einen Blick in die Ereignisanzeige
beim Start zu werfen. Ein W32Time Fehler würde auf NIC-Probleme deuten.

In Bezug auf Firebird würde ich den select erst mal auf ein Feld beschränken
um zu sehen ob sich was ändert.

Gruß
Alfred

[DelphiBandit]

Erste Tests - eine grosse Stored-Procedure, welche die Daten aus allen vier Tabellen raussucht und in einer riesigen Ergebnismenge zurückliefert ~ 2 Sekunden für die 10fache Menge an Daten. Nach der alten Logik wären das ca. 10000 Mal Query öffnen/schliessen. Wireshark zeigt grosse Blöcke mit "continuation data". Insgesamt werden für die 10fache Menge ca. 14 MByte an Rohdaten übers Netz geschubst! Wie überschlagen gerechnet waren es bei der kleineren Datenmenge schon über 30 MByte! Nicht benötigte Ausgabefelder, sind jetzt insgesamt 70 Stück, werden zusätzlich in der SP auch nach SUSPEND alle auf NULL gesetzt, damit man weiß welcher Datenblock gerade der notwendige ist.

Ausgabe wie folgt

SQL-Code:

AUSSENTABELLE mit Keys.... SUBTABLE1-FELDER... SUBTABLE2-FELDER... SUBTABLE3-FELDER
KEY..DATEN
KEY..NULL                       DATEN
KEY..NULL                       DATEN
KEY..NULL                       NULL                DATEN
KEY..NULL                       NULL                NULL                DATEN
Nächster Datensatz

Hier ist allerdings noch nicht der Overhead in der Anwendung berücksichtigt die Daten in das Ausgabeformat zu verwandeln. Aber das stelle ich mir nicht mehr als so zeitkritisch vor, weil am Ende eine ca. 2 MByte grosse ASCII-Datei dabei herauskommt.

Die Netzlast geht bei dieser Abfrage übrigens von vorher ~0.5% auf jetzt ca. 7-8% hoch!

Das scheint hier tatsächlich die Lösung zu sein, statt vieler kleiner Abfragen - auch wenn sie prepared und parametrisiert sind - eine grosse Ergebnismenge! Das ständige Öffnen/Schliessen der inneren Queries resultiert in vielen, kleinen Netzpaketen. Jetzt mache ich mich mal dran und setze die Logik für die Ausgabe um.

Vielen Dank für Eure Geduld mit mir und für die Ideen und hilfreichen Tipps :-D

Carsten

[hoika]

Hallo,

Zitat:

Netzwerkkarten sind in beiden Rechnern Intel 82567 GBit Onboard in Fujitsu-Rechnern.

Ja, so einen Rechner habe ich auch hier mit Windows 7.
Das Netzwerk ist extrem lahm !!!

Allerdings ist der Treiber auch von 6/2009.

Eine "Aktualisieren" bringt lapidar die Meldung "Neuester Stand".

Direkt bei Intel gibt es aber einen neueren Treiber 2/2010.

Den werde ich jetzt mal installieren.

Hoffentlich bis bald ;)



#Update:#
Da bin ich wieder.
Es lag am Stecker, einmal kurz aus der Dose, wieder rein und es läuft schön schnell.


Heiko

[daddy]

Nachträgliche Anmerkung zum Thema:

Meine Erfahrung ist auch, dass viele kleine Selects sehr kontraproduktiv sind. Ich hatte ein Firebird-Projekt in Bearbeitung, dass sowohl lokal auf einem Rechner als auch im lokalen Netzwerk mit sehr guter Performance lief. Als ich dann aber eine erste Anbindung üner VPN/DSL installieren musste, ging das Ganze fürchterlich in die Knie. Und das nicht bei Abfragen großer Datenmengen - da war der Unterschied sogar eher zu vernachlässigen - sondern bei kleinen vorbereitenden Selects zum Beispiel beim Programmstart oder beim Aufruf neuer Module. Je nach DSL-Geschwindigkeit dauert jedes einzelne Select durch den Overhead ca. eine halbe Sekunde. Und wenn dann zum Programmstart erst einmal 10 oder 20 Selects ausgeführt werden, kann das ganz schön nerven. Lokal geschieht das ohne wahrnehmbare Zeitverzögerung, per VPN/DSL bedeutet es aber 5 oder 10 Sekunden Wartezeit.
Ich bin daraufhin dazu übergegangen insbesondere beim Programmstart Selects zu formulieren, die mir per UNION in einem einzigen Durchgang Informationen aus völlig unterschiedlichen Tabellen holen, die eigentlich nichts miteinander zu tun haben, nur um diesen Overhead zu minimieren und um für jeweils 2 eingesparte Selects 1 Sekunde Performance zu gewinnen. Ein Aufwand, der sich auf jeden Fall gelohnt hat.

Gruß
Daddy