aVogt
Returning Creator

Dauer von Arbeitsabläufen, mal schnell, mal ewig

Hallo,

ich bin dabei unsere Arbeitsabläufe etwas zu optimieren, damit sie etwas schneller laufen.

Unsere Arbeitsabläufe bestehen aus mehreren Schritten. An den Schritten hängen Scripte. In den Scripten werden Methoden aus einem eigenen geschriebenem Modul aufgerufen (da die Methoden in unterschiedlichen Scripten in unterschiedlichen Projekten verwendet werden).

Zu dem Arbeitsablauf (siehe scree_arbeitsablauf.png) auf denen ich mich im folgenenden beziehe:

Dieser wird auf einer Datenquelle ausgeführt und besteht aus 4 Schritten:

  1. Überprüfung der Eingaben
  2. Archivierung des bisher verlinkten Mediums (bisheriges Medium wird in ein anderen Medienordner kopiert)
  3. Änderung der Daten (bisheriges medium wird mit dem neu angegebenen Medium überschrieben, an dem Datensatz werden noch Daten gesetzt (Datum) und der Datensatz freigegeben)
  4. Änderung wird in einer speziellen Tabelle eingetragen

Um zu analysieren, wo Zeit „verbraten“ wird, habe ich einige Logausgaben eingefügt (was wird wann gestartet usw.).

Da die Logausgaben aller Schritte am Ende des Arbeitsablauf per Mail mir zugesandt werden, schreibe ich die Ausgaben in die Session (entsprechende Methode befinden sich ebenfalls in dem eigenen Modul):

...

((WorkflowScriptContext) this.projectContext).getSession().put(this.idetWfLog, this.logSB.toString());

HashMap<Object, Object> wfMap = (HashMap<Object, Object>) ((WorkflowScriptContext) this.projectContext).getSession();

...

Am Anfang eines Schrittes hole ich mir die bisherigen Ausgaben (falls vorhanden)

HashMap<Object, Object> wfMap = (HashMap<Object, Object>) ((WorkflowScriptContext) context).getSession();

try {

   if (wfMap.get(this.idetWfLog) != null) {

      this.logSB.append(wfMap.get(this.idetWfLog));

   }

(lobSB ist ein StrinngBuffer)

Durch dieses Loggen habe ich herausbekommen, dass die Statusübergänge zwischen den einzelnen Schritten manchmal über 4 Sekunden (siehe Log2.txt – zwischen Archierung und ändern) dauern und manchmal deutlich unter einer Sekunde (siehe Log1). Die Logmenge, die dabei geschrieben wird, ist eigentlich jedes Mal die gleiche, also sollte es nicht wirklich daran liegen, dass die Loginformationen in die Session geschrieben werden.

Auch wird manchmal viel Zeit beim kopieren von Medien gebraucht und manchmal nicht.

An der Auslastung des Systems kann es nicht liegen. Arbeitsspeicher steht genug zur Verfügung und die CPU-Last ist nicht der rede wert.

Ich habe ehrlich gesagt, keine Ahnung, an was das liegen könnte, dass die Arbeitsabläufe manchmal schnell und manchmal ewig brauchen.

Auch wenn mir bewusst ist, dass eine Analyse von fernen schwer möglich ist:


  1. An was könnte es liegen, dass die Statusübergänge manchmal flutschen (manchmal alle zusammen unter einer Sekunde) und manchmal ewig (bis zu 10, machmal sogar über 10 Sekunden) brauchen? Wird irgendetwas automatisch angestoßen, wenn in einem Arbeitsablauf ein Statusübergang erfolgt?
  2. Gibt es Tipps, was man beim arbeiten im MediaStore tun oder lassen sollte? Gibt es eine Anzahl von Medien in einem Ordner, ab dem es unperfomant wird, wenn man über die Api zugreift und dann Aktionen ausführt (neuanlegen, löschen, Inhalt aktualisieren)?
  3. Muss etwas in der Session nach einem Arbeitsablauf aufgeräumt werden?
  4. Könnte es auch am Client liegen?

Für Hinweise bin ich sehr dankbar.

Grüße

Andreas

Achja: FS4.1R3 bei ausschließlicher Verwendung des SiteArchitect.


0 Kudos
9 Replies
aVogt
Returning Creator

Noch eine kleine Ergänzung:

in der fs-server.conf steht der Eintrag indexing.maxNoOfAssociations auf 1. Damit sollte nur der geänderte Datensatz neu indexiert werden und nicht auch die abhängigen (die datensätze sind untereinander stark verlinkt).

0 Kudos

Hallo Andreas,

ich habe noch ein paar Rückfragen:

1. Läuft FirstSpirit auf einem Desktop-System oder einem Server (mit RAID 1 oder 5)?

2. Werden immer, wenn es länger läuft, Medien kopiert? Oder sind die Wartezeiten davon unabhängig?

3. Wie viel Arbeitspeicher hat FirstSpirit denn zugewiesen bekommen und wie viele Projekte befinden sich auf dem Server? Wie groß ist das größte Projekt?

4. Wie viel freien Heap hat denn die JVM zur Verfügung? (Dazu braucht man die VisualVM von Oracle welche bei jedem JDK dabei ist)

Ich kenne natürlich auch nicht euren Java-Code, aber seit Java 5 bzw. 6 gibt es den Executor-Service mit dem man unter Java relativ einfach bestimmte Operationen parallelisieren kann. Wenn man x von einander unabhängige Operationen (Kopieren von Dateien) sequentiell ausführt kann das theoretisch ziemlich bremsen. Man kann z.B. dem Executor-Service einen Thread-Pool mit der Anzahl der zur Verfügung stehenden Kerne geben. Java verteilt dann die Threads schön gleichmässig auf die CPUs bzw. Kerne. So skaliert dann ein Java-Programm abhängig von der Hardware-Umgebung.

Grüße

Marian Zaplatynski

P.S. Noch ein Tipp: Ein StringBuffer ist in Java synchronized. Wenn dieser nicht in verschiedenen Threads benutzt wird, sollte dieser mit einem StringBuilder ersetzt werden, da dieser die nicht synchronisierte Variante des StringBuffer ist. Synchronisierte Methoden können die Performance von Java-Programmen unter Umständen ziemlich ausbremsen.

0 Kudos
aVogt
Returning Creator

Hallo Marian,

1. FirstSpirit läuft auf einem Virtualem Server

2. Es werden bei dem Arebitsablauf immer medien kopiert.

3. Das sollten 10 GB sein (wrapper.java.maxmemory=10240), 7 Projekte

Projektname Festplattenspeicher
gaf461,22 MB
Intranet3,709 GB
sab.sachsen1,009 GB
sfo26,875 GB
sn-cz43,386 MB
sn-pl807,062 MB
ziel3-cil3659,367 MB

Das betreffende Projekt, mit den unterschiedlichen zeiten ist auch das größte (wir haben nur in einem weiteren Projekt Arbeitsabläufe und da ist es noch nicht zu dem problem gekommen)

In dem großen Projekt gibt es 22.414 Medien, davon 43 Bilder, in 338 Ordnern

4.Ist das nicht auch das, was im Monitoring zu sehen ist?

Code Cache


NON_HEAP128 MB48,963 MB128 MB128 MB
Par Eden Space


HEAP1,333 GB348,101 MB1,333 GB1,333 GB
Par Survivor Space


HEAP1,333 GB50,318 MB1,333 GB1,333 GB
CMS Old Gen


HEAP6 GB2,851 GB6 GB6 GB
CMS Perm Gen


NON_HEAP512 MB121,743 MB512 MB512 MB
Total


TOTAL9,292 GB3,407 GB9,292 GB9,292 GB

edit:

Ich verwende doch schon einen StringBuilder ...

Grüße

Andreas

0 Kudos

Hallo Andreas,

bei virtuellen Servern hast du ja immer das Problem, dass du dir die Resourcen mit anderen virtuellen Servern teils. Es könnte durchaus sein, dass gerade auf einem oder mehreren anderer Server irgendetwas läuft, was deinen Server beeinträchtigt.

Du könntest auch mal mit vmstat prüfen, ob dein System schon am swappen ist, dass könnte ebenfalls ein Grund für diese unterschiedlichen Zeiten sein.

Viele Grüße

thorsten

0 Kudos
aVogt
Returning Creator

Hallo Thorsten,

unsere Systemer meinen, dass der virtuelleServer 4CPU und 12GB Arbeitsspoeicher zugesichert hat und diese nichtmit anderen teilen muss.

Wegen den vmstat habe ich leider keine rechte und unsere Systemer keine Zeit ...

Was mich nur wundert: Die einzelnen WF-Schritte (4 Stück) laufen annähernd gleichlang. Allerdings zwischen den einzelnen Übergängen liegen mal 100ms und mal 3Sec (bei 3 Statusübergängen sind das schon mal 9 Sekunden).

Mir ist schon klar, dass eine Analsys da sehr schwer ist, gibt ja noch das FileSystem, die Datenbank ... aber alles immer ständig überwachen ist auch sher aufwendig und da ich es nicht unter Kontrolle habe, bin ich immer auf andere angewiesen.

Grüße

Andreas

0 Kudos
aVogt
Returning Creator

Gibt es event. Performance Unterschiede, wenn der gesamte Code in dem Workflowscript steht, oder wenn Teile davon (z.B. Änderungen/Löschen an dem Datensatz; Verschieben/Löschen von Medien) in ein eigenes Modul ausgelagert werden (als Klasse/Methode) und nicht als Executable?

0 Kudos

Hallo Andreas,

ohne jetzt all deinen Code zu kennen, oder die Logs etc. analysiert zu haben, gebe ich trotzdem mal eine Antwort auf deine letzte Frage.

Wenn das Workflowskript von einem User im lokalen Client ausgeführt wird, dann läuft dies meines Wissens nach auch auf dem Client und damit auf der lokalen Maschine des Users. D.h. du hast evtl. Netzwerklatenzen beim Übertragen der Objekte vom Server zum Client und zurück, du hast keinen Einfluss ob das Skript auf einem alten Pentium2 oder einem neuen I7 läuft, du hast keinen Einfluss darauf was der User auf seinem CLient noch so alles macht, usw.

(Skripte und Publik-Komponenten, werden meines Wissens nach dort ausgeführt wo sie aufgerufen werden.)

Wenn du die Logik in ein eigenes Modul (Service) auslagerst, läuft es meines Wissens auf dem Server und du hast damit deutlich mehr Kontrolle über die Hardware, zusätzlich fallen Netzweklatenzen weg, etc.

Ich persönlich versuche möglichst viel aus auf den Server auszulagern und möglichst wenig im Client laufen zu lassen.

Eine einfache Public-Komponente reicht dazu allerdings nicht aus. Wenn diese aus dem Client aufgerufen wird, so wird sie auch auf dem Client ausgeführt. Es braucht also einen Service um dies zu erreichen.

Ich verwende dann meistens ein Executable (welches noch auf dem Client ausgeführt wird) in dem ich mir dann den Service hole und anstoße, so dass die eigenltiche Arbeit auf dem Server gemacht wird.

Meiner Meinung nach kann es also durchaus einen Unterschied machen ob der gesamte Code im Workflowskript (Client) ausgeführt wird oder in einem Service (Server)

Grüße

Sandro

0 Kudos

Hallo Andreas,

ist dieses Posting noch aktuell? Benötigst du noch weitere Hilfe oder haben dir die gegebenen Antworten bereits geholfen? In diesem Fall wäre es super, wenn du die "richtige Antwort" entsprechend markierst.

Solltest du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es toll, wenn du sie hier bereitstellst.

Viele Grüße

Michaela

0 Kudos

Der Post von Sandro lohnt sich sicher verfolgt zu werden.

Dazu werde ich aber vorerst leider nicht kommen (habe bisher mit noch keinen Services gearbeitet).

Ich werde es wohl intern so kommunizieren, dass an vielen Stellen "geschraubt" werden könnte, um die Arbeitsabläufe zu optimieren. Hardwareseitig ist das natülich schwerer durchzusetzen und ob es wirlich am Netz und der Datenbank liegt, müsste  auch erst bewiesen werden, was sicher nicht so einfach ist.

0 Kudos