MSSQL/ADO ... speed is everything !!!

[Dejan Vu]

Zitat von mkinzler:

Zudem wäre zu Überlegen, ob man PROC als SP oder UDF auf den Server verlagern kann.

Oder als .NET-DLL, was der Performance zuträglich wäre. Allerdings ist das nur in Verbindung mit einem ETL-Prozess sinnvoll, d.h. eine kontinuierliche Verarbeitung.

Die Datenmenge ist zwar noch nicht sonderlich hoch, aber vermutlich wäre das auch etwas für BigData, zumindest, um sich damit mal zu beschäftigen.

[mkinzler]

Zitat:

Oder als .NET-DLL, was der Performance zuträglich wäre.

Was ja nur eine Implementationsform einer SP wäre

[Dejan Vu]

Zitat von mkinzler:

Zitat:

Oder als .NET-DLL, was der Performance zuträglich wäre.

Was ja nur eine Implementationsform einer SP wäre

Eine Stored Procedure ist in SQL geschrieben (und hat limitierte Möglichkeiten zur Auswertung). Eine .NET-DLL nicht. Also ist es nicht 'nur eine Implementationsform einer SP', sondern viel viel mehr.

[bernhard_LA]

Mein Pseudocode geht wie folgt :

Delphi-Quellcode:

    procedure complete_Process(...);     

           mytimer := 0;   ///  hier beginnt  die Zeitmessung

           someInit ();

           MakeSQLStr();

           query.sql.add();
           query.open;

           myTimer.result(1)    //  hier messe ich die Zeit bis zum laden der Daten in die Query

           query.first;
           for i := 0  to maxrecords  do
                begin   
                proc (query, ......);
                query.next;
                end;
           ....
            myTimer.result(2);    //  hier ist die Zeitmessung wie im Graphen ganz oben gezeigt

           finalize



          
           end;

die Zeit an Messpunkt1 ist gegenüber Messpunkt 2 zu vernachlässigen

[Sir Rufo]

@bernhard_LA

Und der Ansatz ist eben von der Performance her schlecht.

Code:

Daten lesen ---> Queue -+-> Verarbeitungs-Thread 1 -+-> Queue ---> Daten schreiben
                        +-> Verarbeitungs-Thread 2 -+
                        :                            :
                        +-> Verarbeitungs-Thread n -+

Bei der Implementierung ist natürlich darauf zu achten, dass man den Queues eine Maximal-Größe mitgibt, die nicht überschritten werden darf.

[Dejan Vu]

Hier ist der Aufwand (LadeZeit + VerarbeitungsZeit/AnzahlDerThreads). Überlappe LadeZeit und Verarbeitungszeit, dann bist Du bei der optimalen Lösung. Siehe auch Post #2 ( die jetzt nicht unbedingt optimal ist).

Ich würde hierfür einen Workerthreadpool einsetzen und die parallelen Ladejobs von der Serverkonfiguration (output-pipes) abhängig machen.


Jeder der L Lade-Thread lädt N Datensätze und überführt sie in Queue.
Jeder der V Verarbeitungs-Thread nimmt sich 1-M Datensätze und verarbeitet sie.

Der Ladethread wartet, wenn die Queue 'zu voll' ist, d.h. mehr als Q Einträge hat und fängt an, wenn die Queue weniger als P Einträge hat (P<Q).

Nun hat man 6 Stellschrauben (L,V, N,M,P und Q) mit denen sich trefflich optimieren lässt.
Vermutlich ist V die Anzahl der Cores und L die Anzahl der Outputpipes des SQL-Servers (4 waren das, glaube ich).

Je nachdem, wie der Server bzw. die Datenbank konfiguriert ist (Stichwort: Partioning) sind parallele Ladethreads auch überflüssig, weil der Server das eh parallelisiert. Bei 100 Mio DS kann man schon über Tablepartitioning nachdenken.

[arnof]

Mal ein Tipp:

nicht alle Datensätze laden!!!!!

Wenn Du was sehen willst, dann suche genau diese Datensätze raus -> WHERE ist hier eine tolle Sache, wenn ein Where da ist dann schränke die Sache mal mit TOP Anweisung ein.

Ich habe in den letzten Jahren die Erfahrung gemacht, das ich mit TOP 100 am besten leben kann, d.h. der Enduser sieht schon mal was und legt mir aber nicht den Server lahm. Wenn die User zahl steigt 10,50 > 100 legen solche SQL Anweisung den Server lahm ....

Die Zeiten von BDE sind halt vorbei!

[Jumpy]

Was wird denn inhaltlich in

proc (query, ......);

gemacht?

Vielleicht ist ja da schon Optimierungspotential, indem man das (teilweise) die Datenbank machen läßt?