Firebird Geschwindigkeit

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

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