Leistungsfaktoren

Wenn Probleme mit der Leistung bei LiveCycle auftreten, prüfen Sie Folgendes:

  • Synchronisationsprobleme: Wenn viele Threads gleichzeitig im selben Teil des Codes warten, geben Sie einen Thread Dump (eine Auflistung aller Threads) aus, sobald die Überlastung vorbei ist.

    Wichtig: Thread Dumps können die JVM deaktivieren.
  • Langsame externe Ressourcen: Wenn viele Threads auf eine Antwortnachricht einer externen Quelle warten, geben Sie einen Thread Dump aus, um Threads zu finden, die auf Quellen wie Datenbanken oder LDAP-Server warten.

  • Langsame GC-Sammlung: Wenn verbosegc häufig eine Verdichtung durchführt, verringern Sie die Menge an „Garbage“, der von der Anwendung generiert wird, indem Sie einen Objektpool oder -cache einführen. Wenn im Protokoll lange Garbage Collection-Zyklen in verbosegc angezeigt werden, verringern Sie die maximale Größe.

  • Hohe CPU-Auslastung: Wenn Ihre CPU zu 75 % oder höher ausgelastet ist, ziehen Sie diese Optionen in Betracht:

    • Reduzieren Sie die Poolgröße des Webcontainers oder der ORB-Threads.

    • Verringern Sie die Anzahl der Datenbankverbindungen auf dem Datenbankserver.

    • Fügen Sie ggf. weitere Verarbeitungsressourcen hinzu, wenn die CPU ständig stark ausgelastet ist.

    • Wenn sich die CPU auf dem Datenbankserver befindet, reduzieren Sie die maximale Verbindungseinstellung der Datenquelle.

  • Umfangreiche Datenspeicher-Respository-Größe Einige Vorgänge in LiveCycle können eine eine beträchtliche Zunahme der Größe des Datenspeicher-Repositorys verursachen. In der Correspondence Management Solution kann dies zum Beispiel auftreten, wenn Sie einen Batchprozess ausführen, bei dem eine große Anzahl an Elementen veröffentlicht wird. Sie können den Datenspeicher-Garbage Collector verwenden, um alle temporären Daten aus dem Repository zu löschen.

    So führen Sie den Garbage Collector aus:

    1. Navigieren Sie zu http://<hostname>:<port>/lc/system/console/jmx und melden Sie sich mit Administratorberechtigungen an.

    2. Suchen Sie nach „com.adobe.granite (Typ Repository) und klicken Sie darauf.

    3. Suchen Sie nach runDataStoreGarbageCollection(java.lang.Boolean delete) und klicken Sie darauf.

    4. Setzen Sie „java.lang.Boolean delete“ auf „Wahr“.

    5. Klicken Sie auf „Aufrufen“, um den Garbage Collector ausführen.

  • Importieren von Paketen mit großer Anzahl von Elementen: Wenn Sie ein Paket importieren, das viele Elemente enthält, treten möglicherweise folgende Probleme auf:

    • Java-Heap-Speicherfehler

      Um dieses Problem zu beheben, müssen Sie den Java-Heap-Bereich auf 4 GB erhöhen.

    • Der Zugriff auf Correpondence-Management- und CRX-Benutzeroberflächen ist nicht mehr möglich.

      Es wird empfohlen, dass umfangreiche Importvorgänge als Batchvorgang ausgeführt werden.

Geringe Leistungs oder Ausnahme wegen Transaktionszeitlimit bei Verwendung von Administration Console

* Neu für 10*

Wenn Sie mehrere Vorgänge für eine große Anzahl von Dateien mithilfe von Administration Console ausführen, wird der Vorgang möglicherweise nur langsam verarbeitet oder es tritt eine Zeitlimitausnahme auf.

Um dieses Problem zu beheben, müssen Sie den Zeitüberschreitungswert für Transaktionen für den Anwendungsserver erhöhen. Wie Sie den Zeitüberschreitungswert für Transaktionen konfigurieren, fiinden Sie in der Produktdokumentation Ihres Anwendungsservers.

Verbessern der Leistung bei asynchronen Dienstaufrufen

Legen Sie die folgenden JVM-Argumente fest, um die Leistung bei asynchronen Aufrufen von Diensten zu verbessern:

  • -Dadobe.work-manager.queue-refill-interval=1

  • -Dadobe.workmanager.memory-control.enabled=false

Fügen Sie für JBoss diese Argumente hinzu:
  • (Windows) Die Datei „run.conf.bat“ oder die Datei „run.conf.bat“ entsprechend Ihrer JBoss-Installation.

  • (UNIX) Die Datei „run.sh“ oder die Datei „run.conf“ entsprechend Ihrer JBoss-Installation.

Informationen zum Festlegen von JVM-Argumenten für WebSphere finden Sie unter „Konfigurieren der JVM-Argumente“ im Handbuch Installieren und Bereitstellen von LiveCycle für WebSphere.

Informationen zum Festlegen von JVM-Argumenten für WebSphere finden Sie unter „Konfigurieren der JVM-Argumente“ im Handbuch Installieren und Bereitstellen von LiveCycle für WebLogic.

Remoteaufruf schlägt bei Anwendungsservern in einer reinen IPv6-Umgebung fehl

Wenn Sie den LiveCycle-Server in einer reinen IPv6-Umgebung verwenden, schlägt der Remoteaufruf von Diensten auf dem LiveCycle-Server möglicherweise fehl. Dieses Problem tritt auf, wenn für die Clients das SUN JDK verwendet wird. Um diesen Fehler zu vermeiden, verwenden Sie für Clients das IBM JDK, wenn LiveCycle auf Anwendungsservern in einer reinen IPv6-Umgebung bereitgestellt wird.

Process Management-Leistungsproblem bei Oracle

Der Process Management-Durchsatz verschlechtert sich bei Oracle-Datenbanken gelegentlich im Laufe der Zeit. Das LiveCycle-Entwicklungsteam verfügt über einige SQL*Plus-Skripte, mit denen dieses Problem behoben werden kann. Diese Skripte verbessern die Leistung in Anwendungsszenarien mit einer großen Benutzerzahl.

Sie können sich an den Adobe Enterprise-Support wenden und die Skripte, die sich auf die TechNote mit dem Titel „Process Management performance issue on Oracle“ (Dokument-ID cpsid_85089) beziehen, anfordern.

Verbessern der Windows Server-Leistung mit LDAP

Durch die Verwendung von Verbindungspools bei der Suchverbindung kann die Anzahl der benötigten Anschlüsse um bis zu 50 % verringert werden, da diese Verbindung immer dieselben Berechtigungen für eine bestimmte Domäne verwendet und darüber hinaus der Kontext und die entsprechenden Objekte ausdrücklich geschlossen sind.

Konfigurieren von Windows Server für die Verwendung von Verbindungspools

  1. Starten Sie den Registrierungseditor, indem Sie Start > Ausführen wählen. Geben Sie in das Feld Öffnen den Befehl regedit ein und klicken Sie auf OK.

  2. Wechseln Sie zum Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

  3. Suchen Sie im rechten Fenster des Registrierungs-Editors den Wertnamen TcpTimedWaitDelay. Falls der Name fehlt, wählen Sie Bearbeiten > Neu > DWORD-Wert aus, um ihn hinzuzufügen.

  4. Geben Sie in das Feld „Name“ die Bezeichnung TcpTimedWaitDelay ein.

  5. Wenn in dem Feld weder eine Einfügemarke noch der Text Neuer Wert # angezeigt wird, klicken Sie mit der rechten Maustaste in das rechte Fenster, wählen im Menü die Option Umbenennen aus und geben unter Name die Bezeichnung TcpTimedWaitDelay ein.

  6. Wiederholen Sie die Schritte 4 und 5 für die folgenden Wertenamen: MaxUserPort, MaxHashTableSize und MaxFreeTcbs.

  7. Doppelklicken Sie in den rechten Bereich, um den TcpTimedWaitDelay-Wert festzulegen. Wählen Sie unter „Basis“ die Option Dezimal und geben Sie in das Feld Wert den Wert 30 ein.

  8. Doppelklicken Sie in den rechten Bereich, um den MaxUserPort-Wert festzulegen. Wählen Sie unter „Basis“ die Option Dezimal und geben Sie in das Feld Wert den Wert 65534 ein.

  9. Doppelklicken Sie in den rechten Bereich, um den MaxHashTableSize-Wert festzulegen. Wählen Sie unter „Basis“ die Option Dezimal und geben Sie in das Feld Wert den Wert 65536 ein.

  10. Doppelklicken Sie in den rechten Bereich, um den MaxFreeTcbs-Wert festzulegen. Wählen Sie unter „Basis“ die Option Dezimal und geben Sie in das Feld Wert den Wert 16000 ein.

Wichtig: Wenn Sie mit dem Registrierungs-Editor oder einer anderen Methode fehlerhafte Änderungen an der Registrierung vornehmen, kann dies schwerwiegende Folgen haben. Im Extremfall müssen Sie eventuell das Betriebssystem neu installieren. Alle Änderungen an der Registrierung erfolgen auf eigenes Risiko.

Konfigurieren des Scheduler-Dienstes für nicht standardmäßige JNDI-URLs

(Nur Umgebungen ohne Cluster)

Eventuell benötigt der Scheduler-Dienst zusätzliche Konfigurationseinstellungen, um richtig zu funktionieren.

JBoss

Falls sich die JNDI-URL unter JBoss von der standardmäßigen JNDI-URL für den Anwendungsserver unterscheidet (z. B. bei JBoss: jnp://localhost:1099), benötigen Sie die folgende JNDI-URL für den IDP_DS, der von Ihrem Anwendungsserver verwaltet wird:

    org.quartz.dataSource.idp.java.naming.provider.url
  1. Erstellen Sie eine neue Datei namens „dscscheduler.properties“.

  2. Legen Sie die Werte der oben genannten Eigenschaften entsprechend den Anforderungen für den Knoten des Anwendungsservers fest, wie beispielsweise:

            org.quartz.dataSource.idp.java.naming.provider.url =  
                jnp://localhost:1099/ 
            org.quartz.jobstore.isClustered = true 
            org.quartz.scheduler.instanceId = AUTO
  3. Fügen Sie das JVM-Argument -Dadobe.idp.scheduler.properties=[Pfad zu dieser Datei]/dscscheduler.properties zu den Startskriptdateien bzw. der Konfiguration des Anwendungsservers hinzu.

WebSphere

Falls sich der JNDI-URL unter WebSphere vom standardmäßigen JNDI-URL für den Anwendungsserver unterscheidet (z. B. bei WebSphere: iiop://localhost:2809), benötigen Sie den folgenden JNDI-URL für den IDP_DS, der von Ihrem Anwendungsserver verwaltet wird:

    org.quartz.dataSource.idp.java.naming.provider.url
  1. Erstellen Sie eine neue Datei namens „dscscheduler.properties“.

  2. Legen Sie die Werte der oben genannten Eigenschaften entsprechend den Anforderungen für den Knoten des Anwendungsservers fest, wie beispielsweise:

            org.quartz.dataSource.idp.java.naming.provider.url =  
                iop://localhost:2809/ 
            org.quartz.jobstore.isClustered = true 
            org.quartz.scheduler.instanceId = AUTO
  3. Fügen Sie das JVM-Argument -Dadobe.idp.scheduler.properties=[Pfad zu dieser Datei]/dscscheduler.properties zu den Startskriptdateien bzw. der Konfiguration des Anwendungsservers hinzu.

WebLogic

Falls sich die JNDI-URL unter WebLogic von der standardmäßigen JNDI-URL für den Anwendungsserver unterscheidet (z. B. bei WebLogic: t3://localhost:7001), benötigen Sie die folgende JNDI-URL für den IDP_DS, der von Ihrem Anwendungsserver verwaltet wird:

    org.quartz.dataSource.idp.java.naming.provider.url
  1. Erstellen Sie eine neue Datei namens „dscscheduler.properties“.

  2. Legen Sie die Werte der oben genannten Eigenschaften entsprechend den Anforderungen für den Knoten des Anwendungsservers fest, wie beispielsweise:

            org.quartz.dataSource.idp.java.naming.provider.url =  
                t3://localhost:7001/ 
            org.quartz.jobstore.isClustered = true 
            org.quartz.scheduler.instanceId = AUTO
  3. Fügen Sie das JVM-Argument -Dadobe.idp.scheduler.properties=[Pfad zu dieser Datei]/dscscheduler.properties zu den Startskriptdateien bzw. der Konfiguration des Anwendungsservers hinzu.

Übermäßige FileNet-API-Protokollierung und Leistungsprobleme bei WebLogic

Ist LiveCycle auf einem WebLogic-Server installiert, können bei IBM® FileNet-APIs aufgrund der übermäßigen Protokollierung Leistungsprobleme auftreten. Um die Leistung in solchen Fällen zu verbessern, sollten Sie die Protokollierungsstufe von „debug“ in „Fatal“ ändern.

  1. Navigieren Sie auf FileNet Content Server zum Ordner „C:\Programme\FileNet\ContentEngine\config\samples“.

  2. Kopieren Sie die Datei „log4j.properties.client“ auf den LiveCycle-Server und benennen Sie die Datei in log4j.properties um.

  3. Öffnen Sie die Datei „log4j.properties“ und kommentieren Sie die Einträge für die Appender FileNetTraceAppender und FileNetTraceRollingAppender aus:
    #=== FileNetTraceAppender 
    log4j.appender.FileNetTraceAppender=org.apache.log4j.FileAppender log4j.appender.FileNetTraceAppender.File=/p8_api_trace.log # This is the layout that the TraceLoggingConfiguration framework on the server uses. 
    # To use this layout , jace.jar must be present in the classpath. #log4j.appender.FileNetTraceAppender.layout=com.filenet.apiimpl.util.TraceLayout # Comment out the following lines if using the FileNet TraceLayout log4j.appender.FileNetTraceAppender.layout=org.apache.log4j.PatternLayout log4j.appender.FileNetTraceAppender.layout.ConversionPattern=%d %5p [%t] - %m\r\n #=== FileNetTraceRollingAppender log4j.appender.FileNetTraceRollingAppender=org.apache.log4j.RollingFileAppender log4j.appender.FileNetTraceRollingAppender.File=/p8_api_trace.log log4j.appender.FileNetTraceRollingAppender.MaxFileSize=100MB log4j.appender.FileNetTraceRollingAppender.MaxBackupIndex=1 
    # This is the layout that the TraceLoggingConfiguration framework on the server uses. 
    # To use this layout , jace.jar must be present in the classpath. 
    #log4j.appender.FileNetTraceRollingAppender.layout=com.filenet.apiimpl.util.TraceLayout 
    # Comment out the following lines if using the FileNet TraceLayout 
    log4j.appender.FileNetTraceRollingAppender.layout=org.apache.log4j.PatternLayout 
    log4j.appender.FileNetTraceRollingAppender.layout.ConversionPattern=%d %5p [%t] - %m\r\n
    • Setzen Sie den FileNet-Logger auf „FATAL“ und entfernen Sie FileNetTraceAppender und FileNetTraceRollingAppender aus dem Logger:

      Ersetzen Sie
      log4j.logger.filenet_error = error, FileNetConsoleAppender, 
      FileNetErrorRollingAppender, FileNetTraceRollingAppender 

      durch

      log4j.logger.filenet_error = fatal, FileNetErrorRollingAppender
    • Setzen Sie den FileNet-API-Logger auf „FATAL“:

      Ersetzen Sie

      #log4j.logger.filenet_error.api = warn

      durch

      log4j.logger.filenet_error.api = fatal
  4. Speichern Sie die Datei „log4j.properties“.

  5. Fügen Sie den Pfad des Ordners, der die Datei „log4j.properties“ enthält, dem FileNet Component ID-Eintrag in der Datei adobe-component-ext.properties hinzu, die auf dem LiveCycle-Anwendungsserver abgelegt ist. Auf dem WebLogic-Anwendungsserver befindet sich diese Datei unter [WL_HOME]/user_projects/domains/<Domänenname>.

    Wenn die Datei „log4j.properties“ zum Beispiel unter „C:/log4j_file/log4j.properties“ gespeichert ist, fügen Sie „C:/log4j_file“ zur Datei „adobe-component-ext.properties“ hinzu.

  6. Starten Sie den Anwendungsserver neu.

Ablaufwarnung für Cache-Element, wenn viele Benutzer gleichzeitig auf Content Services (nicht mehr unterstützt) zugreifen

Hinweis: Adobe migriert Kunden, die Adobe® LiveCycle® Content Services ES verwenden, zu Inhalts-Repository, das basierend auf der modernen, modularen CRX-Architektur erstellt wurde, die durch die Übernahme von Day Software durch Adobe erhalten wurde. Das Inhalts-Repository wird mit LiveCycle Foundation bereitgestellt und ist als Teil der LiveCycle ES4-Version verfügbar.

Die folgende Warnung wird in den Anwendungsserverprotokollen angezeigt, wenn viele Benutzer gleichzeitig auf Content Services zugreifen:

ReadWriteCach W org.hibernate.cache.ReadWriteCache handleLockExpiry An item was expired by the cache while it was locked (increase your cache timeout): org.alfresco.repo.domain.hibernate.NodeImpl.properties

Um dieses Problem zu lösen, legen Sie in den Anwendungsserver-Startskripten fest, dass das folgende JVM-Argument zum Aktualisieren von ehcache den Least Recently Used-(LRU-)Algorithmus statt des heuristischen Standardalgorithmus verwenden soll:

-Dnet.sf.ehcache.use.classic.lru=true