Dauer von Arbeitsabläufen, mal schnell, mal ewig
Author: aVogt
Publication Date: 6/18/2015 9:14
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:
- Überprüfung der Eingaben
- Archivierung des bisher verlinkten Mediums (bisheriges Medium wird in ein anderen Medienordner kopiert)
- Änderung der Daten (bisheriges medium wird mit dem neu angegebenen Medium überschrieben, an dem Datensatz werden noch Daten gesetzt (Datum) und der Datensatz freigegeben)
- Ä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:
- 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?
- 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)?
- Muss etwas in der Session nach einem Arbeitsablauf aufgeräumt werden?
- 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.
-
Author: aVogt - 7/22/2015 12:54
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 gaf 461,22 MB Intranet 3,709 GB sab.sachsen 1,009 GB sfo 26,875 GB sn-cz 43,386 MB sn-pl 807,062 MB ziel3-cil3 659,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_HEAP 128 MB 48,963 MB 128 MB 128 MB Par Eden Space HEAP 1,333 GB 348,101 MB 1,333 GB 1,333 GB Par Survivor Space HEAP 1,333 GB 50,318 MB 1,333 GB 1,333 GB CMS Old Gen HEAP 6 GB 2,851 GB 6 GB 6 GB CMS Perm Gen NON_HEAP 512 MB 121,743 MB 512 MB 512 MB Total TOTAL 9,292 GB 3,407 GB 9,292 GB 9,292 GB edit:
Ich verwende doch schon einen StringBuilder ...
Grüße
Andreas
0 -
Author: thmarx - 7/23/2015 8:46
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 -
Author: aVogt - 8/5/2015 8:47
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 -
Author: aVogt - 8/5/2015 11:37
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 -
Author: bIT_sosswald - 8/7/2015 8:13
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 -
Author: MichaelaReydt - 8/25/2015 9:07
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 -
Author: aVogt - 9/2/2015 8:42
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
Please sign in to leave a comment.
Comments
7 comments