SELECT + LOOP: Geschwindigkeit?

Getting started ... Alles für einen gelungenen Start.
36 Beiträge Vorherige Seite 3 von 3 (current)
36 Beiträge Vorherige Seite 3 von 3 (current)

Re: SELECT + LOOP: Geschwindigkeit?

Beitrag von black_adept (Top Expert / 3316 / 60 / 605 ) » 18. Nov 2019 22:37

Wie viel Laufzeit wird eigentlich in den Aufrufen zigtausend Aufrufen der

Code: Alles auswählen.

PERFORM whatever_you_wanna_duh
verbraten?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de


Re: SELECT + LOOP: Geschwindigkeit?

Beitrag von foxtrot (ForumUser / 28 / 1 / 0 ) » 19. Nov 2019 08:45

ewx hat geschrieben:
18. Nov 2019 16:45
was erwartest du denn als Laufzeit?
schneller als die Auswertung, die ich ablösen möchte, und die vor vielen Jahren ohne Bedacht auf Laufzeit (oder Speicher) geschrieben wurde... und, wie erwähnt, Probleme macht.
Im ersten Wurf war ich eben nicht wesentlich schneller (am Q-System), also hab ich mich auf die Suche gemacht.
DeathAndPain hat geschrieben:
18. Nov 2019 16:47
Irgendwas haut da nicht hin. So ein LOOP darf keine so langen Laufzeiten erzeugen. Habt ihr möglicherweise ein sehr stark abgespecktes Entwicklungssystem,
natürlich, aber auch sehr abgespeckte Daten. Bei 10.000 Zeilen sollte noch lange nichts swappen.
Das unterdimensionierte System bei uns ist das Q-System, das alle Daten von P hat, aber nicht dieselbe Hardware-Dimensionierung, weil...

Auf dem Produktivsystem wird das aber sicherlich nicht so sein.
Fahre gerade einen Vergleich auf P über Belege eines Monats (ca. 25000 Zeilen im Ergebnis) und bin in der "Urversion" doch schon etwa doppelt so schnell wie das alte Programm. Wobei ich gerade gesehen habe, dass das alte Programm da schon wieder was dazuliest, was ich gar nicht ausgewählt habe... ich glaube, ich will das gar nicht verstehen...
Ich kann Dir nur raten, möglichst viel im Hauptspeicher zu rechnen und die Zahl Deiner SELECTs auf ein Minimum zu beschränken.
Das war auch meine Idee, und deshalb war ich ja verwundert. Nämlich gerade bei einem Umfang von ca. 10.000 Zeilen, wo man schon Laufzeiten ablesen kann (und ich nicht ewig auf das Ergebnis warten muss), aber keine Speicherprobleme haben sollte.
Was Du machen kannst und was ich Dir empfehlen würde, auch wenn es anfangs etwas mehr Tipparbeit für Dich bedeutet, ist, Dich von dem SELECT * zu verabschieden und Dir zu überlegen, welche Spalten aus der VBPA Du tatsächlich benötigst. Deklarier am Anfang Deines Programms einen lokalen Typ mit genau diesen Feldern, dann deklariere Deine lokale Tabelle lt_vbpa über diesen Typ (aber natürlich trotzdem sortiert mit gescheitem Schlüssel). Damit reduzierst Du vermutlich (je nachdem, wie viele der Spalten Du wirklich brauchst) ganz erheblich den Hauptspeicherbedarf,
Das überlege ich mir wirklich noch...
und zugleich wird Dein Code im Debugger für Dich und für andere viel besser verständlich, weil man dann in der internen Tabelle nur Werte sieht, die im Zusammenhang Deines Programms tatsächlich bedeutsam sind, statt lauter irrelevantem Datenmüll.
Was bei der VBPA kein echtes Thema ist.
Was habt ihr überhaupt für eine Datenbank?
Welche Rolle spielt das? Sollte Oracle sein.
ewx hat geschrieben:
18. Nov 2019 18:34
JHM hat geschrieben:
18. Nov 2019 09:28
Du ließt im allgemeinen sehr viele Daten (SELECT *), verwendest du alle?
Benötigst du wirklich alle PARVW aus der VBPA?
Datensparsamkeit kommt der Laufzeit immer zu Gute.
Das kann ich bei diesem Beispiel NICHT bestätigen!
Ich bei meinem Programm schon - die Reduktion auf die nötigen Partner hat eine Beschleunigung gebracht.

Irgendwoher kam noch die Frage, wieso es das LOOP sein soll, das so bremst:
Ganz einfach, das Programm wurde langsamer, wie ich das select VBPA aus dem äußeren loop herausgezogen habe und im loop kein select, aber ein loop über die große lt_vbpa gemacht habe. Alles andere habe ich gleich gelassen.
Das ist ja das irritierende: nicht die absolute Laufzeit (die kommt auch aus anderen Programmteilen), sondern dass die Verlagerung in den Hauptspeicher langsamer wäre.

Jedenfalls zwischendurch wieder einmal danke für die diversen Ratschläge!

Re: SELECT + LOOP: Geschwindigkeit?

Beitrag von DeathAndPain (Top Expert / 1184 / 132 / 256 ) » 19. Nov 2019 13:00

Bei 10.000 Zeilen sollte noch lange nichts swappen.
"Sollte" oder hast Du es nachgeprüft? Vielleicht swappt die Kiste ja schon dadurch, dass SAP läuft? Dann rechnet jedes zusätzliche Byte auf der Festplatte (na gut, ist etwas übertrieben, aber Du verstehst, was ich meine).
Welche Rolle spielt das? Sollte Oracle sein.
Hätte ja sein können, dass es HANA ist. Das hätte schon einen nicht unerheblichen Unterschied gemacht.

Ich würde an Deiner Stelle weniger theoretisieren und doch mal mit GET RUN TIME ermitteln, ob die Laufzeit wirklich aus dem LOOP kommt oder vielleicht doch an anderer Stelle entsteht. Wenn Du Dir keine Arbeit machen willst, wirst Du auch zu keinem Ergebnis gelangen.

Re: SELECT + LOOP: Geschwindigkeit?

Beitrag von JHM (Top Expert / 1138 / 0 / 179 ) » 22. Nov 2019 13:20

foxtrot hat geschrieben:
19. Nov 2019 08:45
Das ist ja das irritierende: nicht die absolute Laufzeit (die kommt auch aus anderen Programmteilen), sondern dass die Verlagerung in den Hauptspeicher langsamer wäre.
Das kommt ja auf die dahinterstehende Hardware bzw. der Auslastung. Wenn der Hauptspeicher des Application-Server immer swopped, da alle die DB-Daten zuerst einmal dort ablegen, dafür der DB-Server sich die meiste Zeit langweilt, ist das Ergbnis der Verlagerung ja klar.

Wenn der DB Server bei euch am stärksten ist, dann könnte man die Kopfpartner auch per JOIN ermitteln lassen (4 mal die VBPA mit unterschiedlichen ALIAS). Dann nur noch die Positionspartner per SELECT&LOOP im Nachgang ermitteln.

Um die Partnerdatenzugriffe zu reduzieren könnte man auch noch mit Gruppenstufen arbeiten und die Kopfpartner nur dann neu lesen, wenn es auch einen neuen Kopf gibt. Dann könnte man auch noch mit der FROM INDEX Angabe für die Positionspartnerermittlung arbeiten, damit der Positionspartner nicht immer vom Anfang der IT_VBPA gesucht werden muss.

Folgende Benutzer bedankten sich beim Autor JHM für den Beitrag:
Legxis (25. Nov 2019 09:35)

Gruß Hendrik

Re: SELECT + LOOP: Geschwindigkeit?

Beitrag von DeathAndPain (Top Expert / 1184 / 132 / 256 ) » 22. Nov 2019 15:32

Wenn der Hauptspeicher des Application-Server immer swopped, da alle die DB-Daten zuerst einmal dort ablegen, dafür der DB-Server sich die meiste Zeit langweilt, ist das Ergbnis der Verlagerung ja klar.
Dann ist die Lösung aber nicht, auf teure Datenbankzugriffe umzustellen, sondern den Application-Server in Ordnung zu bringen. Ein paar - auch größere - Tabellen in den Hauptspeicher zu laden mag vor 20 Jahren noch ein Thema gewesen sein. Bei heutigen Speichergrößenordnungen darf das aber nicht mehr der Fall sein. Entweder da laufen Programme drauf, die ganz katastrophal programmiert sind und z.B. erst mal im ganz großen Stil große, komplette Datenbanktabellen in den Hauptspeicher laden (und davon dann eine Kopie pro gestarteter Instanz des Programms), oder der Application Server ist zu knapp dimensioniert und braucht ein paar zusätzliche Speicherriegel. Stattdessen bei der Programmierung zu pfuschen ist nicht die Lösung. Man sucht und rechnet so weit wie möglich in internen Tabellen und greift so wenig wie möglich auf die Datenbank zu.

Re: SELECT + LOOP: Geschwindigkeit?

Beitrag von foxtrot (ForumUser / 28 / 1 / 0 ) » 26. Nov 2019 13:15

Nur zwischendurch eine Info, falls sich wer wundert, dass ich nichts mehr schreibe: momentan warte ich auf ein paar Erfahrungswerte von Anwendern (die aber momentan ziemlich unter Stress stehen), und ansonsten hab ich hier ja auch noch ein paar andere "Hobbies"...

lg

Vorherige Seite 3 von 3 (current)

Aktuelle Forenbeiträge

PopUp bei Fakturaerstellung
vor 13 Minuten von jocoder 2 / 20
Generische Objekte in der Massenverarbeitung
vor 53 Minuten von TravellingEntwickler 2 / 585
Unterschiedliche Konditionen AB und Rechnungdruck
vor 6 Stunden von Sebastian82 1 / 34
Anzahlungsrechnung drucken
vor 7 Stunden von Sebastian82 1 / 30

Unbeantwortete Forenbeiträge

Unterschiedliche Konditionen AB und Rechnungdruck
vor 6 Stunden von Sebastian82 1 / 34
Anzahlungsrechnung drucken
vor 7 Stunden von Sebastian82 1 / 30
Änderungsbelege für Kundenfelder im BP
vor 4 Tagen von GerryRe 1 / 1990
Transaktionen MEIS / VE01
vor einer Woche von SAP_ENTWICKLER 1 / 2462