Lotus Notes 8.5.2 Skript Verarbeitung ehrheblich langsamer als 7.0.2

[rabdos]

Hallo Leute,

nach fast 7 jähriger Forumszugehörigkeit ohne eigenen Post, muss ich nun meinen ersten aufmachen.  Bisher konnte ich immer alles über die Suche finden

Aufgrund der erweiterten Nutzung von Webservice steigen wir von 7.0.2 auf 8.5.2 um. Ich habe natürlich viele alte Skripte in meiner Datenbank und eines davon wird zur Erarbeitung von mehreren Dateien benutzt. Dieses Skript erzeugt intern mehrere Listen, die groesste hat ca. 20000 Segmente und verarbeitet diese entsprechend.
Unter Notes 7 dauerte dieses Skript ca. 1 Std und unter 8.5.2 benötigt es ca. 8 Stunden. Ich werde hier fast verrückt, weil ich das Problem nicht finde, warum das so ist. Das Skript ist objektorientiert mit verschiedenen Klassen programmiert. Hat ca. 1900 (inkl. Leerzeilen) Zeilen und macht halt ne Menge.
Aufgefallen ist mir, dass das Skript mit der Zeit immer langsamer wird. Laut meiner Fortschrittsanzeige benötigen die ersten 10% ca 15 Minuten und danach wird es exponentiell immer langsamer in der Verarbeitung.

Kennt einer von euch dieses Problem mit der Verarbeitung von Arrays unter 8.5.2 ? Das ist das einzige was ich mir vorstellen kann, dass hier ein Problem mit den Listen vorliegt.

Ich habe das Skript vorhin auf einem PC das Skript unter Notes 7 gestartet und es ist nach einer Laufzeit von 30 Minuten bei 76%. Es muss an irgendwas unter 8.5 liegen.

Danke
Torsten

[eknori]

Der einzige Weg, das zuverlässig herauszufinden dürfte das Profiling des Codes sein. Schlage vor, du setzt dich mit Teamstudio in Verbindung und holst dir eine Testlizenz für den Profiler. Dann siehst du, wo die Zeit verbraten wird.

[Peter Klett]

Arbeitest Du mit Arrays (Redim meinArray (20000)) oder mit Listen (Dim meineListe List As ...)?

Hast Du mal die Ressourcen auf den Maschinen verglichen? Kann es sein, dass unter 8.5.2 weniger freier Arbeitsspeicher bereit steht und das Swappen Zeit kostet (falls das überhaupt genutzt werden kann, nur eine "aus-dem-Bauch"-Idee)?

[rabdos]

das Format meiner Listen sieht so aus

Public Artikel List As Artikel

und dann hat z.b. die Klasse Artikel

Sub New(inDoc As NotesDocument, inNr As Integer, inMonBack As Integer, inLogFile As LogFile, profil As notesdocument)
      Set logFile = inLogFile
      Call GetAttribs(inDoc, inNr, inMonBack, profil)
End Sub

Alles eigentlich kein Hexenwerk. Hab das Ding grad ja unter Notes 7 laufen lassen und der Durchlauf hat unter einer Stunde gedauert. Das Skript lasse ich auch lokal in einer Kopie laufen, daher kann es kein Ressourcenproblem sein.

Teamstudio hab ich sogar drauf, aber mit dem Profiler noch nie gearbeitet. Mal sehen ob ich den zum laufen bekomm. Nutz immer nur den Configurator wenn ich was suche.

[ghostmw]

Moin,

was steckt denn da für ein Betriebssystem drunter, habe grade bei einem Kunden ein ähnliches Verhalten.

Der Kunde ist bei seinen Clients von XP nach Win7 gewechselt, und bei einigen Buttons hinter denen Lotusscript Klassen und Funktionen stecken, laufen auch schrecklich langsam und man muss 2-3 mal klicken, bis es reagiert.

Könnte das damit in Zusammenhang stehen ?

Grüsse
Marco

[rabdos]

in Verbindung mit Win 7 habe ich da auch etwas gelesen. Wir nutzen noch XP.

[Peter Klett]

Das Skript lasse ich auch lokal in einer Kopie laufen, daher kann es kein Ressourcenproblem sein.

Deine Artikel-Klasse beinhaltet zwei Notesdokumente. Wenn Du eine Liste mit 20.000 Elementen füllst, sind das 40.000 Dokumente. Unter XP sind m.W. 2 GB Arbeitsspeicher direkt adressierbar. Wenn ich mich jetzt nicht total verrechnet habe, sind 40.000 Dokumente zu 50 KB 2 GB. Das ist Dein komplett adressierbarer Arbeitsspeicher, ohne, dass irgendein anderes Programm auch nur ein einziges Bit Speicher verwenden darf. 8.5. mit Eclipse wird aber sicherlich auch das eine oder andere Byte mehr haben wollen, als 7.

Wenn Du mehrere dieser Listen hast und nicht nach dem Verarbeiten alles sauber aufräumst, wird der freie Platz nicht gerade üppiger. Also, ich verstehe Deine Antwort nicht ...

[pedsola]

FullTrimFix=0
setz den mal Dir auf dem Server.
Du wirst sehen, das hilft Wunder.

Hatten genau das gleiche Problem nach dem Sprung auf 8.5.x

Hier noch die Quelle dazu:
http://www-10.lotus.com/ldd/r5fixlist.nsf/Public/D731C9471F4FD93A85257638006DFA7C?OpenDocument

[Thomas Schulte]

Fortschrittsanzeige???

Doch nicht mit Print Befehlen. Oder? Wenn ja. Klemm die mal ab. Das Verhalten gab es schon unter V4, 5 und 6. Wenn man in Agenten excessiv mit Print Statements gearbeitet hat konnte man dem System beim einschlafen zuschauen.

[rabdos]

Deine Artikel-Klasse beinhaltet zwei Notesdokumente. Wenn Du eine Liste mit 20.000 Elementen füllst, sind das 40.000 Dokumente. Unter XP sind m.W. 2 GB Arbeitsspeicher direkt adressierbar. Wenn ich mich jetzt nicht total verrechnet habe, sind 40.000 Dokumente zu 50 KB 2 GB. Das ist Dein komplett adressierbarer Arbeitsspeicher, ohne, dass irgendein anderes Programm auch nur ein einziges Bit Speicher verwenden darf. 8.5. mit Eclipse wird aber sicherlich auch das eine oder andere Byte mehr haben wollen, als 7.

Wenn Du mehrere dieser Listen hast und nicht nach dem Verarbeiten alles sauber aufräumst, wird der freie Platz nicht gerade üppiger. Also, ich verstehe Deine Antwort nicht ...

Wie beschreibe ich das jetzt mal vernünftig. Also das Skript dient zur Abrechnung von Artikeln.
Ich lese ca. 12000 Dokumente ein und baue daraus eine Liste aus verschiedenen Feldern, z.b. Institutsnummer, Endstelle, usw. Diese Liste verarbeite ich dann in einer weiteren Liste bis ich zuletzt 6 Dateien rausschiebe. Eine dieser Dateien ist z.b. für einen SAP-Import.
Artikel werden es zum Schluss knapp 19000. Wie kommst du auf 40000 Dokumente? Oder habe ich einen Logikfehler. Sollte ich wirklich jedes Dokument von Hand aus dem Speicher löschen, wenn alle Felder ausgelesen wurden ?

Ich habe das Skript nun einmal im Hintergrund laufen. Speicherauslastung liegt bei 1,5GB. Habe gleich nen Meeting, mal sehen ob der sich verändert.


@Batped
Das Skript läuft ja lokal. Oder kann ich da auch den Wert einstellen ?

@Thomas
Wie weisst du denn dann wie weit das Skript ist? Habe auch schon Popup-Statusfenster gebaut, aber von denen habe ich wieder Abstand genommen, weil man die nicht richtig Debuggen kann.

@eknori
Ich warte noch auf meine Serial für den Profiler


Danke für eure Hilfe

[Thomas Schulte]

Wenn ich grundsätzlich weiss das das Script läuft, dann bau ich das so um, das es nur noch jedes 1000 ste oder 5000 ste Mal piep sagt. Vor allem dann, wenn ich da Massen von Dokumenten verarbeite. Jeder Print auf dem Server läuft nämlich ins Log und initiiert damit einen Schreibzyklus. Vollkommen egal wie performant das IBM gestaltet hat, das bremst. Und zwar erheblich.

[pedsola]

@Batped
Das Skript läuft ja lokal. Oder kann ich da auch den Wert einstellen ?

jep, probiers einfach aus, dann ist die ganze Diskussion vorbei.

[Peter Klett]

Auf die 40.000 komme ich, weil Du geschrieben hast, dass Du 1. bis zu 20.000 Elemente hast und 2. Deine Listenelemente von einer Klasse sind, die beim "New" zwei Dokumente als Parameter übergeben bekommen. 2 x 20.000 = 40.000 (so meine vielleicht etwas naive Rechenmethode).

Wenn ich massenhaft Daten von Dokumenten im Speicher halten muss (ich mache das auch mit Listen, ist mein Lieblingskonstrukt in Script), nehme ich Dokumente nur, wenn es nicht anders geht. Meist beschränkt sich das ganze ja auf ein paar Felder pro Dokument. Dann deklariere ich einen eigenen Datentyp

Type meinDatentyp
   Datum1 As ...
   Datum2 As ...
   Datum3 As ...
End Type

und definiere darüber die Liste

Dim meineListe List As MeinDatentyp

Der Zugriff erfolgt dann genauso, als wenn es ein Dokument wäre (evtl. ohne (0), wenn die einzelnen Daten z.B. als String deklariert sind).

rein:
meineListe ("Test").Datum1 = "1"
meineListe ("Test").Datum2 = "2"
meineListe ("Test").Datum3 = "3"

raus:
return = meineListe ("Test").Datum1

Im Ergebnis habe ich die gleichen Daten im Speicher, muss beim Schreiben in den Speicher zwar etwas mehr tun als nur Set meineDokumente ("Test") = doc, verbrauche aber wesentlich weniger Platz. Ist vielleicht nicht wirklich die Ursache Deines Problems, es kann aber nie schaden, auch mit den scheinbar unendlich vorhandenen Ressourcen heutiger Rechner etwas sparsamer umzugehen.

Gespannt bin ich auf das Ergebnis Deines Versuches mit FullTrimFix ...

[rabdos]

so komme gerade aus meinem Meeting. Skript war nach 80 Minuten bei 39% und die Speicherauslastung war bei 1,6GB. Also keine wirkliche Veränderung.

@Peter
Dieses Abrechnungsskript ist schon nen paar Jahre alt und funktioniert einwandfrei. Mit der einen Stunde Laufzeit konnte ich immer Leben. Nur mit viel mehr halt nicht. Daher habe ich noch nicht das Bedürfnis gehabt, hier viele Veränderungen vorzunehmen. Immer nur ein paar Erweiterungen halt.
In vielen anderen Skripten die ich so baue, nehme ich auch die Deklaration von eigenen Datentypen vor. Dieses Skript müsste ich halt komplett neu schreiben und das ist schon extrem aufwändig. Wenns nicht anders zu lösen ist, mache ich das auch. Aber ich hoffe das bringt dann auch etwas...wer weiss

Ich habe nu erst einmal den FullTrimFix=0 in die notes.ini eingetragen und das Skript neu gestartet. Das rauswerfen der Fortschrittsanzeige ist dann der nächste Punkt.

Das Problem tritt auch nur bei dieser grossen Anzahl auf. Ich habe noch einen weiteren Lauf für Sonstige Abrechnungen mit ca 1000 Dokumenten, der läuft annähernd so schnell wie vorher -.-

[rabdos]

Leider brachte sowohl die Aufnahme von FulltrimFix = 0 als auch das entfernen meiner Fortschrittsanzeige absolut keinen Performanceschub. Das Skript benötigt ziemlich genau 8 Stunden für den Durchlauf unter 8.5.2. Unter Notes 7 benötigt es nicht einmal mehr 1 Stunde. Gleiches Skript auf dem selben Arbeitsgerät...ich verstehe das nicht.
Leider habe ich noch keine Serial vom Teamstudio Profiler bekommen

[pram]

hast du denn schon mal gesucht wo der Flaschenhals ist (Stichwort Teamstudio Profiler)

Könnte evtl das schuld sein:
http://www-10.lotus.com/ldd/r5fixlist.nsf/8ed1b46cfdba8957852570c90054623b/14a71cc8d7d547198525783000736f77?OpenDocument

Gruß
Roland

[rabdos]

Ich nutze im Skript kein GetDocumentByKey.

Ich habe gerade die Serial und den Key für den Profiler bekommen und der ackert gerade meine DB durch.

Was mich an der ganzen Sache irritiert ist, dass das Skript mit der Zeit immer langsamer wird. Die ersten 10% laufen in 15 Minuten. Von 10-20% benötigt er dann 25 Minuten und von 90-100% fast 2 Stunden. Obwohl die ganze Zeit die gleichen Berechnungen innerhalb meiner Listen laufen. Genau dieses hat das Skript unter Notes 7 eben nicht. Da brauchen die Prozentsprünge immer die gleiche Laufzeit.
Deshalb dachte ich auch an ein Speicherauslastungsproblem. Aber laut Windows Task Manager braucht der nur minimal mehr mit der Zeit und bleibt auch unter 2GB.

Gruss
Torsten

[koehlerbv]

Du verwendest aber nicht irgendwo ein Set NotesDocument = NotesView.GetNthDocument ?

Bernhard

[Peter Klett]

Du verwendest aber nicht irgendwo ein Set NotesDocument = NotesView.GetNthDocument ?

Bernhard

Vermutlich nicht, denn das führte schon in älteren Versionen zu solchen Effekten (ich war ein Verfechter dieser Methode, bis ich Jahre später das Unheil erkannte)

[eknori]

Du verwendest aber nicht irgendwo ein Set NotesDocument = NotesView.GetNthDocument ?

Bernhard

Hatte zu diesem Thema auf dem letzten EntwicklerCamp parliert. Da sehe ich nun wirklich nicht das Problem.