Monitoraggio e manutenzione dell’istanza di Adobe Experience Manager monitoring-and-maintaining-your-aem-instance

Dopo aver implementato le istanze AEM, è necessario monitorarne e mantenerne il funzionamento, le prestazioni e l'integrità.

Un fattore chiave in questo caso è che per riconoscere potenziali problemi è necessario conoscere l'aspetto e il funzionamento del sistema in condizioni normali. Questa capacità è resa possibile al meglio monitorando il sistema e raccogliendo informazioni nel tempo.

Verifica
Considerazioni
Commento/Azioni
Piano di backup.
Scopri come Eseguire il backup dell'istanza.
Piano di disaster recovery.
Linee guida aziendali per il disaster recovery.
È disponibile un sistema di tracciamento degli errori per la segnalazione dei problemi.
Ad esempio, Bugzilla, Jira o uno dei tanti altri.
Monitoraggio dei file system.
L’archivio CRX si "blocca" se lo spazio disponibile su disco è insufficiente. Riprende quando lo spazio diventa disponibile.
"È possibile visualizzare i messaggi "*ERROR* LowDiskSpaceBlocker" nel file di registro quando lo spazio disponibile è insufficiente.
Monitoraggio dei file di registro in corso.
Il monitoraggio del sistema è (costantemente) in esecuzione in background.
Compreso l'utilizzo di CPU, memoria, disco e rete. Ad esempio, utilizzando iostat / vmstat / perfmon.
I dati registrati vengono visualizzati e possono essere utilizzati per monitorare i problemi di prestazioni. Anche i dati non elaborati sono accessibili.
Monitoraggio delle prestazioni dell'AEM in corso.
Inclusione di contatori di richieste per monitorare i livelli di traffico.
Se si osserva una perdita significativa, o a lungo termine, di rendimento, è necessario effettuare un'indagine dettagliata.
Stai monitorando i tuoi agenti di replica.
Eliminare regolarmente le istanze del flusso di lavoro.
Dimensioni dell’archivio e prestazioni del flusso di lavoro.
Vedi Rimozione regolare delle istanze del flusso di lavoro.

Backup backups

È buona prassi eseguire il backup di:

  • Installazione del software - prima/dopo modifiche significative alla configurazione
  • Contenuto contenuto all’interno dell’archivio, regolarmente

È probabile che l'azienda disponga di una politica di backup da seguire. Considerazioni aggiuntive su cosa e quando eseguire il backup sono le seguenti:

  • la criticità del sistema e dei dati.
  • la frequenza con cui vengono apportate modifiche al software o ai dati.
  • volume di dati; la capacità può occasionalmente rappresentare un problema, così come il tempo per eseguire il backup.
  • se è possibile eseguire il backup mentre gli utenti sono online e, se possibile, qual è l'impatto sulle prestazioni.
  • la distribuzione geografica degli utenti; ovvero, quando è il momento migliore per eseguire il backup (per ridurre al minimo l'impatto)?
  • criteri di ripristino di emergenza; esistono linee guida sulla posizione in cui devono essere archiviati i dati di backup (ad esempio, fuori sede e supporto specifico).

Spesso viene eseguito un backup completo a intervalli regolari (ad esempio, giornaliero, settimanale o mensile), con backup incrementali compresi tra (ad esempio, ogni ora, ogni giorno o ogni settimana).

CAUTION
Durante l'implementazione dei backup delle istanze di produzione, è necessario eseguire i test 1} per verificare che sia possibile ripristinare correttamente il backup.
Senza questo test, il backup è potenzialmente inutile (scenario peggiore).
NOTE
Per ulteriori informazioni sulle prestazioni di backup, leggere la sezione Backup delle prestazioni.

Backup dell'installazione del software backing-up-your-software-installation

Dopo l'installazione o modifiche significative nella configurazione, creare un backup dell'installazione del software.

Per eseguire questa operazione, eseguire il backup dell'intero archivio e quindi:

  1. Interruzione AEM.
  2. Eseguire il backup dell'intero <cq-installation-dir> dal file system.
CAUTION
Se si utilizza un server applicazioni di terze parti, è possibile che altre cartelle si trovino in una posizione diversa e che sia necessario eseguirne il backup. Per informazioni sull'installazione dei server applicazioni, vedere Come installare AEM con un server applicazioni.
CAUTION
È supportato il backup incrementale dell’archivio dati dei file; quando utilizzi il backup incrementale per altri componenti (come l’indice Lucene), assicurati che anche i file eliminati siano contrassegnati come eliminati nel backup.
NOTE
Il mirroring del disco può essere utilizzato anche come meccanismo di backup.

Backup dell’archivio backing-up-your-repository

Nella sezione Backup e ripristino della documentazione di CRX sono descritti tutti i problemi relativi ai backup dell'archivio CRX.

Per informazioni dettagliate sull'esecuzione di un backup "a caldo" online, vedere Creazione di un backup online.

Rimozione versione version-purging

Lo strumento Rimuovi versioni è progettato per eliminare le versioni di un nodo o di una gerarchia di nodi nell'archivio. Il suo scopo principale è quello di aiutare a ridurre le dimensioni dell’archivio rimuovendo le versioni precedenti dei nodi.

Questa sezione tratta le operazioni di manutenzione relative alla funzione di controllo delle versioni dell’AEM. Lo strumento Rimuovi versione è destinato all'eliminazione delle versioni di un nodo o di una gerarchia di nodi nell'archivio. Il suo scopo principale è quello di aiutarti a ridurre le dimensioni del tuo archivio rimuovendo le vecchie versioni dei tuoi nodi.

Panoramica overview

Lo strumento Rimuovi versioni è disponibile come attività di manutenzione settimanale. Prima di utilizzare per la prima volta, è necessario aggiungerlo e configurarlo. Successivamente può essere eseguito su richiesta o settimanalmente.

Rimozione delle versioni di un sito Web purging-versions-of-a-web-site

Per eliminare le versioni di un sito Web, procedere come segue:

  1. Passa alla Strumenti console, seleziona Operazione, Manutenzione, quindi Finestra manutenzione settimanale.

  2. Seleziona + Aggiungi dalla barra degli strumenti superiore.

    Aggiungi eliminazione versione

  3. Selezionare Rimozione versione dall'elenco a discesa nella finestra di dialogo Aggiungi nuova attività. Quindi Salva.

    Aggiungi eliminazione versione

  4. L'attività Pulizia versione è stata aggiunta. Utilizza le azioni della scheda per:

    • Seleziona: mostra ulteriori azioni nella barra degli strumenti superiore
    • Esegui: per eseguire immediatamente l’eliminazione configurata
    • Configura: per configurare l’attività di eliminazione settimanale

    Azioni di eliminazione versione

  5. Selezionare l'azione Configura per aprire la console Web per l'attività di eliminazione versione di CQ WCM, in cui è possibile configurare:

    Configurazione eliminazione versione

    • Percorsi di eliminazione
      Impostare il percorso iniziale del contenuto da eliminare, ad esempio /content/wknd.

      note caution
      CAUTION
      L’Adobe consiglia di definire più percorsi per ciascuno dei siti web.
      La definizione di un percorso con troppi elementi figlio può allungare notevolmente il tempo necessario per eseguire l'eliminazione.
    • Rimuovi versioni in modo ricorsivo

      • Deseleziona questa opzione se desideri eliminare solo il nodo definito dal percorso.
      • Seleziona questa opzione per rimuovere il nodo definito dal percorso e dai relativi discendenti.
    • Numero massimo di versioni
      Imposta il numero massimo di versioni (per ogni nodo) che desideri mantenere. Lascia vuoto per non usare questa impostazione.

    • Numero minimo di versioni
      Imposta il numero minimo di versioni (per ogni nodo) che desideri mantenere. Lascia vuoto per non usare questa impostazione.

    • Versione massima
      Imposta la validità massima della versione in giorni (per ogni nodo) che desideri mantenere. Lascia vuoto per non usare questa impostazione.

    Quindi Salva.

  6. Passa/torna alla finestra Finestra manutenzione settimanale e seleziona Esegui per avviare il processo immediatamente.

CAUTION
Puoi utilizzare la finestra di dialogo dell'interfaccia classica per eseguire una Dry Run della configurazione:
  • http://localhost:4502/etc/versioning/purge.html
I nodi eliminati non possono essere ripristinati senza ripristinare l’archivio. Assicurati di eseguire sempre un'esecuzione di prova prima di eseguire l'eliminazione.

Dry Run: analisi della console analyzing-the-console

L'interfaccia utente classica fornisce un'opzione Dry Run da:

  • http://localhost:4502/etc/versioning/purge.html

Il processo elenca tutti i nodi che sono stati elaborati. Durante il processo, un nodo può avere uno dei seguenti stati:

  • ignore (not versionnable): il nodo non supporta il controllo delle versioni e viene ignorato durante il processo.

  • ignore (no version): il nodo non ha alcuna versione e viene ignorato durante il processo.

  • retained: nodo non eliminato.

  • purged: nodo eliminato.

Inoltre, la console fornisce informazioni utili sulle versioni:

  • V 1.0: numero di versione.

  • V 1.0.1*: la stella indica che la versione è la versione corrente (di base) e non può essere eliminata.

  • Thu Mar 15 2012 08:37:32 GMT+0100: la data della versione.

Nel prossimo esempio:

  • Le Shirts versioni vengono eliminate perché la loro versione è superiore a due giorni.
  • Le versioni Tonga Fashions! vengono eliminate perché il numero di versioni è maggiore di 5.

global_version_screenshot

Utilizzo dei record di controllo e dei file di registro working-with-audit-records-and-log-files

I record di controllo e i file di registro relativi a Adobe Experience Manager (AEM) sono disponibili in varie posizioni. Di seguito viene fornita una panoramica di ciò che è possibile trovare e dove è possibile trovarlo.

Utilizzo dei registri working-with-logs

WCM AEM registra registri dettagliati. Dopo aver decompresso e avviato Quickstart, puoi trovare i registri in:

  • <cq-installation-dir>/crx-quickstart/logs/

  • <cq-installation-dir>/crx-quickstart/repository/

Rotazione del file di registro log-file-rotation

La rotazione del file di registro si riferisce al processo che limita la crescita del file creando periodicamente un file. In AEM, un file di registro denominato error.log viene ruotato una volta al giorno in base alle regole specificate:

  • Il file error.log è stato rinominato in base al pattern {original_filename}.yyyy-MM-dd. Ad esempio, l'11 luglio 2010 il file di registro corrente viene rinominato error.log-2010-07-10, quindi viene creato un nuovo error.log.

  • Precedente file di registro non vengono eliminati, pertanto è responsabilità dell'utente pulire periodicamente i vecchi file di registro per limitare l'utilizzo del disco.

NOTE
Se si aggiorna l'installazione dell'AEM, tutti i file di registro esistenti non più utilizzati dall'AEM rimangono sul disco. È possibile rimuoverli senza rischi. Tutte le nuove voci di registro vengono scritte nei nuovi file di registro.

Ricerca dei file di registro finding-the-log-files

Nel file server in cui è stato installato AEM sono presenti diversi file di registro:

  • <cq-installation-dir>/crx-quickstart/logs

    • access.log
      Tutte le richieste di accesso a AEM WCM e all’archivio sono registrate qui.

    • audit.log
      Le azioni di moderazione sono registrate qui.

    • error.log
      I messaggi di errore (di diversi livelli di gravità) sono registrati qui.

    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
      Questo registro viene utilizzato solo se Dynamic Media è abilitato. Fornisce statistiche e informazioni analitiche utilizzate per analizzare il comportamento del processo interno ImageServer.

    • request.log
      Ogni richiesta di accesso viene registrata qui insieme alla risposta.

    • s7access-<yyyy>-<mm>-<dd>.log
      Questo registro viene utilizzato solo se Dynamic Media è abilitato. Il registro s7access registra ogni richiesta effettuata a Dynamic Media tramite /is/image e /is/content.

    • stderr.log
      Contiene i messaggi di errore, di diverso livello di gravità, generati durante l'avvio. Per impostazione predefinita, il livello di registro è impostato su Warning ( WARN)

    • stdout.log
      Contiene i messaggi di registrazione che indicano gli eventi durante l'avvio.

    • upgrade.log
      Fornisce un registro di tutte le operazioni di aggiornamento eseguite dai pacchetti com.day.compat.codeupgrade e com.adobe.cq.upgradesexecutor.

  • <cq-installation-dir>/crx-quickstart/repository/segmentstore

    • journal.log
      Revisione delle informazioni del giornale di registrazione.
NOTE
I registri di ImageServer e s7access non sono inclusi nel pacchetto Download Full ​ generato dalla pagina ​ system/console/status-Bundlelist". Per assistenza, se hai Dynamic Media problemi, aggiungi i registri di accesso ImageServer e s7access quando contatti l'Assistenza clienti.

Attivazione del livello di registro DEBUG activating-the-debug-log-level

Il livello di registro predefinito (Configurazione registrazione Sling di Apache) è Information, pertanto i messaggi di debug non vengono registrati.

Per attivare il livello di registro di debug per un logger, impostare la proprietà org.apache.sling.commons.log.level per eseguire il debug nell'archivio. Ad esempio, il /libs/sling/config/org.apache.sling.commons.log.LogManager per configurare la registrazione Apache Sling globale.

CAUTION
Non lasciare il registro a livello di registro di debug più a lungo del necessario, perché genera numerose voci di registro, con un consumo di risorse.

Una riga nel file di debug in genere inizia con DEBUG, quindi fornisce il livello del registro, l'azione del programma di installazione e il messaggio del registro. Ad esempio:

DEBUG 3 WebApp Panel: WebApp successfully deployed

I livelli del registro sono i seguenti:

0
Errore irreversibile
Azione non riuscita. Impossibile continuare l'installazione.
1
Errore
Azione non riuscita. L'installazione procede, ma una parte di WCM AEM non è stata installata correttamente e non funziona.
2
Avvertenza
L'azione è stata completata ma si sono verificati problemi. Il WCM dell’AEM può funzionare correttamente o meno.
3
Informazioni
Azione completata.

Creare un file di registro personalizzato create-a-custom-log-file

NOTE
Quando si lavora con Adobe Experience Manager, sono disponibili diversi metodi di gestione delle impostazioni di configurazione per tali servizi. Per ulteriori dettagli e procedure consigliate, vedere Configurazione di OSGi.

In determinate circostanze, può essere opportuno creare un file di registro personalizzato con un livello di registro diverso. Nell’archivio, effettua le seguenti operazioni:

  1. Se non esiste, creare una cartella di configurazione ( sling:Folder) per il progetto /apps/<project-name>/config.

  2. In /apps/<project-name>/config, crea un nodo per la nuova configurazione del logger di registrazione Apache Sling:

    • Nome: org.apache.sling.commons.log.LogManager.factory.config-<identifier>

      Dove <identifier> è sostituito da testo libero che è necessario immettere per identificare l'istanza (non è possibile omettere queste informazioni).

      Ad esempio org.apache.sling.commons.log.LogManager.factory.config-MINE

    • Digitare: sling:OsgiConfig

    note note
    NOTE
    Sebbene non sia un requisito tecnico, è consigliabile rendere <identifier> unico.
  3. Impostare le seguenti proprietà su questo nodo:

    • Nome: org.apache.sling.commons.log.file

      Tipo: String

      Valore: specificare il file di log, ad esempio logs/myLogFile.log

    • Nome: org.apache.sling.commons.log.names

      Tipo: String[] (String + Multi)

      Valore: specifica i servizi OSGi per i quali il logger deve registrare i messaggi; ad esempio, tutti i seguenti:

      • org.apache.sling
      • org.apache.felix
      • com.day
    • Nome: org.apache.sling.commons.log.level

      Tipo: String

      Valore: specificare il livello di log richiesto ( debug, info, warn o error); ad esempio, debug

    • Configura gli altri parametri come richiesto:

      • Nome: org.apache.sling.commons.log.pattern

        Digitare: String

        Valore: specifica il pattern del messaggio di registro come richiesto; ad esempio,

        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    note note
    NOTE
    org.apache.sling.commons.log.pattern supporta fino a sei argomenti.
    {0} Timestamp di tipo java.util.Date
    {1} indicatore del registro
    {2} nome del thread corrente
    {3} nome del logger
    {4} livello di registro
    {5} il messaggio di registro
    Se la chiamata di registro include Throwable, la traccia dello stack viene aggiunta al messaggio.
    note caution
    CAUTION
    org.apache.sling.commons.log.names deve avere un valore.
    note note
    NOTE
    I percorsi del writer di log sono relativi al percorso crx-quickstart.
    Pertanto, un file di registro specificato come:
    logs/thelog.log
    scrive in:
    <cq-installation-dir>/crx-quickstart/logs/thelog.log.
    E un file di registro specificato come:
    ../logs/thelog.log
    scrive in una directory:
    <cq-installation-dir>/logs/
    (ovvero, accanto a <cq-installation-dir>/crx-quickstart/)
  4. Questo passaggio è necessario solo quando è necessario un nuovo processo di scrittura, ovvero con una configurazione diversa da quella predefinita.

    note caution
    CAUTION
    È necessaria una nuova configurazione di Logging Writer solo se il valore predefinito esistente non è adatto.
    Se non è configurato alcun processo di scrittura esplicito, il sistema genera automaticamente un processo di scrittura implicito in base all'impostazione predefinita.

    In /apps/<project-name>/config, crea un nodo per la nuova configurazione di Apache Sling Logging Writer:

    • Nome: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (autore)

      Come per il Logger, <identifier> è sostituito dal testo libero che è necessario immettere per identificare l'istanza (non è possibile omettere queste informazioni). Ad esempio org.apache.sling.commons.log.LogManager.factory.writer-MINE

    • Tipo: sling:OsgiConfig

    note note
    NOTE
    Sebbene non si tratti di un requisito tecnico, è consigliabile rendere <identifier> univoco.

    Imposta le seguenti proprietà su questo nodo:

    • Nome: org.apache.sling.commons.log.file

      Tipo: String

      Valore: specifica il file di registro in modo che corrisponda al file specificato nel logger;

      per questo esempio, ../logs/myLogFile.log.

    • Configura gli altri parametri come richiesto:

      • Nome: org.apache.sling.commons.log.file.number

        Tipo: Long

        Valore: specificare il numero di file di log che si desidera mantenere, ad esempio 5

      • Nome: org.apache.sling.commons.log.file.size

        Tipo: String

        Valore: specifica come necessario per controllare la rotazione del file in base a dimensione/data; ad esempio, '.'yyyy-MM-dd

    note note
    NOTE
    org.apache.sling.commons.log.file.size controlla la rotazione del file di log impostando:
    • una dimensione file massima
    • una pianificazione data/ora
    per indicare quando viene creato un nuovo file (e il file esistente viene rinominato in base al pattern del nome).
    • È possibile specificare un limite di dimensione con un numero. Se non viene fornito alcun indicatore di dimensione, verrà considerato come il numero di byte oppure sarà possibile aggiungere uno degli indicatori di dimensione: KB, MB o GB (il case verrà ignorato).
    • È possibile specificare una pianificazione di data/ora come modello java.util.SimpleDateFormat. Definisce il periodo di tempo dopo il quale il file viene ruotato. Inoltre, il suffisso aggiunto al file ruotato (per l’identificazione).
    Il valore predefinito è '.'yyyy-MM-dd (per la rotazione giornaliera dei log).
    Ad esempio, alla mezzanotte del 20 gennaio 2010 (o quando il primo messaggio di log dopo questa data si verifica per essere precisi), … /logs/error.log viene rinominato in … /logs/error.log.2010-01-20. La registrazione per il 21 gennaio è l'output a (un nuovo e vuoto) … /logs/error.log finché non viene eseguito il rollover al successivo cambio di giornata.
    table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2
    '.'yyyy-MM Rotazione all'inizio di ogni mese
    '.'yyyy-ww Rotazione al primo giorno di ogni settimana (a seconda delle impostazioni internazionali).
    '.'yyyy-MM-dd Rotazione ogni giorno a mezzanotte.
    '.'yyyy-MM-dd-a Rotazione a mezzanotte e a mezzogiorno di ogni giorno.
    '.'yyyy-MM-dd-HH Rotazione all’inizio di ogni ora.
    '.'yyyy-MM-dd-HH-mm Rotazione all'inizio di ogni minuto.
    Nota: quando si specifica un'ora/data:
    1. È necessario "sfuggire" al testo letterale all'interno di una coppia di virgolette singole (' ');

      Evita che alcuni caratteri vengano interpretati come lettere pattern.

    2. Utilizza solo i caratteri consentiti per un nome file valido in qualsiasi punto dell’opzione.

  5. Leggi il nuovo file di registro con lo strumento scelto.

    Il file di log creato da questo esempio è ../crx-quickstart/logs/myLogFile.log.

La console Felix fornisce anche informazioni sul supporto del registro Sling in ../system/console/slinglog; ad esempio, https://localhost:4502/system/console/slinglog.

Ricerca dei record di audit finding-the-audit-records

I registri di audit sono tenuti per fornire una registrazione di chi ha fatto cosa e quando. Vengono generati record di audit diversi per entrambi gli eventi AEM WCM e OSGi.

Record di audit WCM AEM visualizzati durante l’authoring delle pagine aem-wcm-audit-records-shown-when-page-authoring

  1. Apri una pagina.

  2. Dalla barra laterale puoi selezionare la scheda con l'icona del lucchetto, quindi fai doppio clic su Registro di controllo…

  3. Viene visualizzata una nuova finestra che mostra l’elenco dei record di audit per la pagina corrente.

    schermata_shot_2012-02-02at43601pm

  4. Fare clic su OK per chiudere la finestra.

Record di controllo WCM AEM nell’archivio aem-wcm-auditing-records-within-the-repository

All'interno della cartella /var/audit, i record di controllo vengono mantenuti in base alla risorsa. È possibile espandere la visualizzazione fino a visualizzare i singoli record e le informazioni in essi contenute.

Queste voci contengono le stesse informazioni visualizzate durante la modifica di una pagina.

Record di controllo OSGi dalla console Web osgi-audit-records-from-the-web-console

Gli eventi OSGi generano inoltre record di controllo che possono essere visualizzati dalla scheda Stato configurazione > File di registro nella console Web AEM:

schermata_shot_2012-02-13alle50346pm

Monitoraggio degli agenti di replica monitoring-your-replication-agents

È possibile monitorare le code di replica per rilevare quando una coda è inattiva o bloccata, il che potrebbe a sua volta indicare un problema con un'istanza di pubblicazione o un sistema esterno:

  • tutte le code richieste sono abilitate?

  • sono ancora necessarie code disattivate?

  • tutte le code enabled devono avere lo stato idle o active, che indica il normale funzionamento; nessuna coda deve essere blocked, che spesso è un segno di problemi sul lato riceventi.

  • se la dimensione della coda aumenta nel tempo, può indicare una coda bloccata.

Per monitorare un agente di replica:

  1. Accedi alla scheda Strumenti in AEM.

  2. Fare clic su Replica.

  3. Fare doppio clic sul collegamento agli agenti per l'ambiente appropriato (sul riquadro sinistro o destro), ad esempio Agenti sull'autore.

    La finestra risultante mostra una panoramica di tutti gli agenti di replica per l’ambiente di authoring, inclusi la destinazione e lo stato.

  4. Fai clic sul nome dell’agente appropriato (che è un collegamento) per visualizzare informazioni dettagliate su tale agente:

    chlimage_1

    È possibile:

    • Verifica se l’agente è abilitato.
    • Visualizza la destinazione di qualsiasi replica.
    • Verifica se la coda di replica è attiva (abilitata).
    • Verifica se sono presenti elementi nella coda.
    • Aggiorna o Cancella per aggiornare la visualizzazione delle voci della coda. Questa operazione consente di visualizzare gli elementi che entrano ed escono dalla coda.
    • Visualizza registro per accedere al registro di tutte le azioni eseguite dall'agente di replica.
    • Verifica connessione all'istanza di destinazione.
    • Forza nuovo tentativo su qualsiasi elemento della coda, se necessario.
    note caution
    CAUTION
    Non utilizzare il collegamento "Prova connessione" per la cartella Posta in uscita di replica inversa in un'istanza pubblicata.
    Se viene eseguito un test di replica per una coda Posta in uscita, tutti gli elementi precedenti alla replica del test vengono rielaborati con ogni replica inversa.
    Se tali elementi sono presenti in una coda, è possibile trovarli con la seguente query XPath JCR e devono essere rimossi.
    /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

È possibile sviluppare una soluzione per rilevare tutti gli agenti di replica (che si trovano in /etc/replication/author o /etc/replication/publish), quindi controllare lo stato dell'agente ( enabled, disabled) e la coda sottostante ( active, idle, blocked).

Monitoraggio delle prestazioni monitoring-performance

Ottimizzazione delle prestazioni è un processo interattivo che viene attivato durante lo sviluppo. Dopo la distribuzione, viene rivisto dopo intervalli o eventi specifici.

I metodi utilizzati durante la raccolta delle informazioni per l’ottimizzazione possono essere utilizzati anche per il monitoraggio continuo.

Di seguito sono elencati i problemi di prestazioni comuni che si verificano, insieme a proposte su come individuarli e contrastarli.

Area
Sintomo
Per aumentare la capacità…
Per ridurre il volume…
Client
Utilizzo intensivo della CPU del client.
Installare una CPU client con prestazioni superiori.
Semplifica il layout (HTML).
Utilizzo ridotto della CPU del server.
Esegui l’aggiornamento a un browser più veloce.
Miglioramento della cache lato client.
Alcuni clienti sono veloci, altri lenti.
Server
Rete
Utilizzo della CPU ridotto sia sui server che sui client.
Rimuovere eventuali colli di bottiglia della rete.
Migliora/ottimizza la configurazione della cache client.
La navigazione locale sul server è (comparativamente) veloce.
Aumentare la larghezza di banda di rete.
Riduci il "peso" delle pagine web (ad esempio, meno immagini, HTML ottimizzati).
Server web
L'utilizzo della CPU nel server Web è elevato.
Crea un cluster per i server web.
Riduci gli hit per pagina (visita).
Utilizzare un load balancer hardware.
Applicazione
Utilizzo CPU server elevato.
Cluster per le istanze AEM.
Cercare ed eliminare hog di CPU e memoria (utilizzare l'output di revisione del codice e di temporizzazione).
Elevato consumo di memoria.
Migliora la memorizzazione nella cache a tutti i livelli.
Tempi di risposta ridotti.
Ottimizza modelli e componenti (ad esempio struttura, logica).
Archivio
Cache

I problemi di prestazioni possono derivare da varie cause che non hanno nulla a che fare con il sito web, tra cui rallentamenti temporanei della velocità di connessione, del carico della CPU e molto altro.

Inoltre, può influire su tutti i visitatori o solo su un sottoinsieme di essi.

Tutte queste informazioni devono essere ottenute, ordinate e analizzate prima di poter ottimizzare le prestazioni generali o risolvere problemi specifici.

  • Prima di riscontrare un problema di prestazioni:

    • raccogliere quante più informazioni possibili per sviluppare una buona conoscenza operativa del sistema in circostanze normali
  • Quando si verifica un problema di prestazioni:

    • prova a replicarlo con un browser web standard (o preferibilmente più), su un client diverso che sai avere buone prestazioni generali e/o sul server stesso (se possibile)

    • verifica se qualcosa (relativo al sistema) è cambiato entro uno spazio di tempo appropriato e se una qualsiasi di queste modifiche potrebbe avere influito sulle prestazioni

    • poni domande quali:

      • il problema si verifica solo in momenti specifici?
      • il problema si verifica solo su pagine specifiche?
      • sono interessate altre richieste?
    • raccogliere quante più informazioni possibili per confrontarle con la propria conoscenza del sistema in circostanze normali:

Strumenti per il monitoraggio e l'analisi delle prestazioni tools-for-monitoring-and-analyzing-performance

Di seguito viene fornita una breve panoramica di alcuni degli strumenti disponibili per il monitoraggio e l'analisi delle prestazioni.

Alcuni di questi strumenti dipendono dal sistema operativo.

Strumento
Utilizzato per analizzare...
Utilizzo / Ulteriori informazioni...
request.log
Tempi di risposta e concorrenza.
Interpretazione di request.log.
traliccio/cinghia
Caricamenti pagina

Comandi Unix/Linux per tracciare chiamate e segnali di sistema. Aumentare il livello di registro a INFO.

Analizza il numero di caricamenti di pagina per richiesta e quali pagine.

Thread dump
Osservare i thread JVM. Identifica conflitti, blocchi e long runner.

Dipende dal sistema operativo:
- Unix/Linux: kill -QUIT <pid>
- Windows (modalità console): Ctrl-Break

Sono inoltre disponibili strumenti di analisi, ad esempio TDA.

Dump heap
Memoria insufficiente che causa rallentamento delle prestazioni.

Aggiungere l'opzione:
-XX:+HeapDumpOnOutOfMemoryError
alla chiamata Java™ per l'AEM.

Consulta la pagina Opzioni/flag per la risoluzione dei problemi JVM.

Chiamate di sistema
Identificare i problemi relativi alla tempistica.

Chiamate a System.currentTimeMillis() o com.day.util. La tempistica viene utilizzata per generare marche temporali dal codice o tramite HTML-comments.

Nota: implementa questi elementi in modo che possano essere attivati o disattivati come richiesto. Quando un sistema funziona senza problemi, il sovraccarico della raccolta delle statistiche non è necessario.

Apache Bench
Identificare le perdite di memoria e analizzare in modo selettivo i tempi di risposta.

utilizzo di base:

ab -k -n <requests> -c <concurrency> <url>

Per informazioni dettagliate, vedere Apache Bench e la ab man page.

Ricerca analisi
Eseguire query di ricerca non in linea, identificare il tempo di risposta della query, il test e il set di risultati di conferma.
JMeter
Test di carico e funzionali.
https://jmeter.apache.org/
JProfiler
Profilatura approfondita della CPU e della memoria.
https://www.ej-technologies.com/
Registratore di volo Java™
Java™ Flight Recorder (JFR) è uno strumento per la raccolta di dati diagnostici e di profilatura su un'applicazione Java™ in esecuzione.
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr004.html#BABJJEEE
JConsole
Osservare metriche e thread JVM.

Utilizzo: jconsole

Consulta jconsole e Monitoraggio delle prestazioni tramite JConsole.

Nota: con JDK 1.8, JConsole è estensibile con i plug-in; ad esempio, Top o TDA (Thread Dump Analyzer).

Java™ VisualVM
Osserva le metriche JVM, i thread, la memoria e la profilatura.

Sintassi: visualvm o visualvm

Consulta visualvm e Monitoraggio delle prestazioni tramite (J)VisualVM.

Nota: con JDK 1.8, VisualVM è estensibile con i plug-in. VisualVM viene interrotto dopo JDK 9. Utilizza invece il registratore di volo Java™.

traliccio/cinghia, lsof
Chiamata del kernel approfondita e analisi dei processi (UNIX®).
Comandi Unix/Linux.
Statistiche temporali
Consulta le statistiche sui tempi per il rendering della pagina.
Per visualizzare le statistiche sugli intervalli per il rendering della pagina, puoi utilizzare Ctrl-Maiusc-U insieme a ?debugClientLibs=true impostato nell'URL.
Strumento di analisi della CPU e della memoria
Utilizzato per l'analisi di richieste lente durante lo sviluppo.
Ad esempio, YourKit. o il registratore di volo Java™.
Raccolta di informazioni
Stato corrente dell'installazione.
Conoscere il più possibile l'installazione può inoltre essere utile per tenere traccia di ciò che potrebbe aver causato un cambiamento nelle prestazioni e per verificare se tali modifiche sono giustificate. Raccogli queste metriche a intervalli regolari in modo da poter vedere facilmente cambiamenti significativi.

Interpretazione di request.log interpreting-the-request-log

In questo file vengono registrate le informazioni di base relative a ogni richiesta inviata all'AEM. Da ciò si possono trarre conclusioni preziose.

request.log offre una modalità incorporata per ottenere un'idea di quanto tempo richiedono le richieste. A scopo di sviluppo, è utile tail -f request.log e tenere d'occhio i tempi di risposta lenti. Per analizzare un request.log più grande, Adobe consiglia l'utilizzo di rlog.jar che consente di ordinare e filtrare per i tempi di risposta.

L'Adobe consiglia di isolare le pagine "lente" da request.log, quindi di regolarle singolarmente per ottenere prestazioni migliori. Includere metriche delle prestazioni per componente o utilizzare uno strumento di analisi delle prestazioni quale [yourkit](https://www.yourkit.com/).

Monitoraggio del traffico sul sito web monitoring-traffic-on-your-website

Il registro delle richieste registra ogni richiesta effettuata, insieme alla risposta fornita:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Calcolando il totale di tutte le voci di GET in periodi specifici (ad esempio, in vari periodi di 24 ore), puoi fare dichiarazioni sul traffico medio sul tuo sito web.

Monitoraggio dei tempi di risposta con request.log monitoring-response-times-with-the-request-log

Un buon punto di partenza per l’analisi delle prestazioni è il registro delle richieste:

<cq-installation-dir>/crx-quickstart/logs/request.log

Il registro si presenta come segue (le righe sono abbreviate per semplicità):

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Questo registro contiene una riga per richiesta o risposta:

  • La data in cui è stata effettuata ogni richiesta o risposta.

  • Numero della richiesta, tra parentesi quadre. Questo numero corrisponde per la richiesta e la risposta.

  • Una freccia che indica se si tratta di una richiesta (freccia che punta a destra) o di una risposta (freccia a sinistra).

  • Per le richieste, la riga contiene:

    • il metodo (in genere, GET, HEAD o POST)
    • la pagina richiesta
    • il protocollo
  • Per le risposte, la riga contiene:

    • il codice di stato (200 significa "successo", 404 significa "pagina non trovata"
    • il tipo MIME
    • il tempo di risposta

Utilizzando piccoli script, è possibile estrarre le informazioni richieste dal file di log e assemblare le statistiche desiderate. Da queste statistiche, puoi vedere quali pagine o tipi di pagine sono lenti e se le prestazioni complessive sono soddisfacenti.

Monitoraggio dei tempi di risposta delle ricerche con request.log monitoring-search-response-times-with-the-request-log

Le richieste di ricerca vengono registrate anche nel file di registro:

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Quindi, come sopra, puoi utilizzare gli script per estrarre le informazioni rilevanti e creare statistiche.

Tuttavia, dopo aver determinato il tempo di risposta, analizza il motivo per cui la richiesta sta impiegando il tempo richiesto e cosa si può fare per migliorare la risposta.

Monitoraggio del numero e dell'impatto di utenti simultanei monitoring-the-number-and-impact-of-concurrent-users

Anche in questo caso request.log può essere utilizzato per monitorare la concorrenza e la reazione del sistema ad essa.

È necessario eseguire dei test per determinare quanti utenti simultanei il sistema è in grado di gestire prima che si verifichi un impatto negativo. Di nuovo, gli script possono essere utilizzati per estrarre i risultati dal file di registro:

  • monitora quante richieste vengono effettuate in un intervallo di tempo specifico, ad esempio un minuto.
  • verifica gli effetti di un numero specifico di utenti che presentano tutte le stesse richieste nello stesso momento (il più vicino possibile). Ad esempio, 30 utenti che fanno clic contemporaneamente su Salva.
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Utilizzo di rlog.jar per trovare richieste con tempi di durata prolungata using-rlog-jar-to-find-requests-with-long-duration-times

L’AEM include vari strumenti di assistenza nei seguenti casi:
<cq-installation-dir>/crx-quickstart/opt/helpers

Uno di questi strumenti, rlog.jar, può essere utilizzato per ordinare rapidamente request.log in modo che le richieste vengano visualizzate per durata, da quella più lunga a quella più breve.

Il comando seguente mostra i possibili argomenti:

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Ad esempio, puoi eseguirlo specificando request.log file come parametro e visualizzare le dieci prime richieste con la durata più lunga:

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Concatenare i singoli file request.log se è necessario eseguire questa operazione su un campione di dati di grandi dimensioni.

Apache Bench apache-bench

Per ridurre al minimo l'impatto di casi speciali (ad esempio la raccolta di oggetti inattivi), si consiglia di utilizzare uno strumento come apachebench (ad esempio, ab per ulteriore documentazione) per identificare eventuali perdite di memoria e analizzare in modo selettivo i tempi di risposta.

Apache Bench può essere utilizzato nel modo seguente:

$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

I numeri riportati sopra sono ricavati da un notebook standard MAcBook Pro (metà 2010) che accede alla pagina della società del Geometrixx, come incluso in un'installazione AEM predefinita. La pagina è semplice, ma non ottimizzata per le prestazioni.

apachebench visualizza anche il tempo per richiesta come media, in tutte le richieste simultanee; vedi Time per request: 54.595 [ms] (media, in tutte le richieste simultanee). È possibile modificare il valore del parametro di concorrenza -c (numero di richieste multiple da eseguire alla volta) per visualizzare eventuali effetti.

Contatori richieste request-counters

Le informazioni sul traffico delle richieste (numero di richieste durante un periodo di tempo specifico) forniscono un’indicazione del carico sull’istanza. Queste informazioni possono essere estratte da request.log, anche se l'utilizzo dei contatori automatizza la raccolta dei dati per consentirti di visualizzare:

  • differenze significative nell’attività (ovvero, distinguere tra "molte richieste" e "bassa attività")
  • quando non viene utilizzata un’istanza
  • qualsiasi riavvio (i contatori vengono azzerati)

Per automatizzare la raccolta delle informazioni, è inoltre possibile installare RequestFilter per incrementare un contatore a ogni richiesta. È possibile utilizzare più contatori per diversi periodi di tempo.

Le informazioni raccolte possono essere utilizzate per indicare:

  • cambiamenti significativi nelle attività
  • un'istanza ridondante
  • qualsiasi riavvio (contatore azzerato su 0)

Commenti HTML html-comments

È consigliabile che ogni progetto includa html comments per le prestazioni del server. Si possono trovare molti buoni esempi pubblici. Seleziona una pagina, apri l’origine della pagina da visualizzare e scorri verso il basso. È possibile visualizzare un codice come il seguente:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Monitoraggio delle prestazioni tramite JConsole monitoring-performance-using-jconsole

Il comando dello strumento jconsole è disponibile con JDK.

  1. Avvia l’istanza AEM.

  2. Esegui jconsole.

  3. Seleziona la tua istanza AEM e Connetti.

  4. Dall'applicazione Local, fare doppio clic su com.day.crx.quickstart.Main. La panoramica viene visualizzata come predefinita:

    chlimage_1-1

    Ora puoi selezionare altre opzioni.

Monitoraggio delle prestazioni con (J)VisualVM monitoring-performance-using-j-visualvm

Per JDK 6-8, è disponibile il comando dello strumento visualvm. Dopo aver installato un JDK, puoi effettuare le seguenti operazioni:

  1. Avvia l’istanza AEM.

    note note
    NOTE
    Se si utilizza Java™ 5, è possibile aggiungere l'argomento -Dcom.sun.management.jmxremote alla riga di comando Java™ che avvia JVM. JMX è abilitato per impostazione predefinita con Java™ 6.
  2. Esegui una delle seguenti operazioni:

    • jvisualvm: nella cartella JDK 1.6 bin (versione testata)
    • visualvm: scaricabile da VisualVM (versione Edge sanguinante)
  3. Dall'applicazione Local, fare doppio clic su com.day.crx.quickstart.Main. L’impostazione predefinita è Panoramica:

    chlimage_1-2

    Ora puoi selezionare altre opzioni, tra cui Monitor:

    chlimage_1-3

Puoi utilizzare questo strumento per generare immagini thread e immagini head della memoria. Queste informazioni vengono spesso richieste dal team di supporto tecnico.

Raccolta di informazioni information-collection

Conoscere il più possibile le informazioni sull'installazione può essere utile per tenere traccia di ciò che potrebbe aver causato un cambiamento nelle prestazioni e per verificare se tali modifiche sono giustificate. Raccogli queste metriche a intervalli regolari in modo da poter vedere facilmente cambiamenti significativi.

Le seguenti informazioni possono essere utili:

Quanti autori lavorano con il sistema? how-many-authors-are-working-with-the-system

Per visualizzare il numero di autori che hanno utilizzato il sistema dall'installazione, utilizzare la riga di comando:

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Per visualizzare il numero di autori che lavorano in una data specifica:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Qual è il numero medio di attivazioni di pagina al giorno? what-is-the-average-number-of-page-activations-per-day

Per visualizzare il numero totale di attivazioni di pagina dall’installazione del server, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:AuditEvent)[@cq:type='Activate']

Quindi calcola il numero di giorni trascorsi dall’installazione per calcolare la media.

Quante pagine sono attualmente gestite in questo sistema? how-many-pages-do-you-currently-maintain-on-this-system

Per visualizzare il numero di pagine attualmente sul server utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:Page)

Se utilizzi MSM, qual è la media del numero di rollout al mese? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Per determinare il numero totale di rollout dall’installazione, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

Calcolare il numero di mesi trascorsi dall'installazione per calcolare la media.

Qual è il numero medio di Live Copy al mese? what-is-the-average-number-of-live-copies-per-month

Per determinare il numero totale di Live Copy effettuate dall’installazione, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:LiveSyncConfig)

Utilizzare nuovamente il numero di mesi trascorsi dall'installazione per calcolare la media.

Se utilizzi AEM Assets, quante risorse gestisci attualmente in Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Per visualizzare quante risorse DAM sono attualmente gestite, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath
  • Percorso /
  • Query /jcr:root/content/dam//element(*, dam:Asset)

Qual è la dimensione media delle risorse? what-is-the-average-size-of-the-assets

Per determinare la dimensione totale della /var/dam cartella:

  1. Utilizzare WebDAV per mappare l'archivio al file system locale.

  2. Utilizza la riga di comando:

    code language-shell
    cd /Volumes/localhost/var
    du -sh dam/
    

    Per ottenere la dimensione media, dividi la dimensione globale per il numero totale di risorse in /var/dam (ottenuto sopra).

Quanti modelli vengono attualmente utilizzati? how-many-templates-are-currently-used

Per visualizzare il numero di modelli attualmente sul server utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:Template)

Quanti componenti sono attualmente utilizzati? how-many-components-are-currently-used

Per visualizzare il numero di componenti attualmente sul server utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:Component)

Quante richieste all’ora hai nel sistema di authoring al momento di picco? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Per determinare le richieste all’ora disponibili nel sistema di authoring al momento di picco:

  1. Per determinare il numero totale di richieste dall’installazione, utilizza la riga di comando:

    code language-shell
    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
  2. Per determinare le date di inizio e di fine:

    code language-shell
    vim request.log
    G / 1G: for the last/first lines
    

    Utilizzare questi valori per calcolare il numero di ore trascorse dall'installazione, quindi il numero medio di richieste all'ora.

Quante richieste all’ora hai sul sistema di pubblicazione al momento di picco? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Ripeti la procedura precedente sull’istanza di pubblicazione.

Analisi di scenari specifici analyzing-specific-scenarios

Di seguito è riportato un elenco di suggerimenti su cosa controllare se si verificano alcuni problemi di prestazioni. L'elenco non è (purtroppo) completo.

CPU al 100% cpu-at

Se la CPU del sistema è costantemente in esecuzione al 100%, vedi quanto segue:

Memoria insufficiente out-of-memory

Anche se tali errori devono essere rilevati durante lo sviluppo e il test, alcuni scenari possono slittare.

Se la memoria del sistema è quasi esaurita, il problema può essere rilevato in vari modi, tra cui il deterioramento delle prestazioni e messaggi di errore, incluso il testo secondario:

java.lang.OutOfMemoryError

In questi casi verificare:

I/O disco disk-i-o

Se il sistema sta esaurendo lo spazio su disco o si notano problemi di accesso al disco, vedere:

Degradazione delle prestazioni regolare regular-performance-degradation

Se le prestazioni dell’istanza si deteriorano dopo ogni riavvio (a volte una settimana o più tardi), è possibile controllare quanto segue:

Ottimizzazione JVM jvm-tuning

La Java™ Virtual Machine (JVM) è migliorata per quanto riguarda la messa a punto (soprattutto da Java™ 7). Di conseguenza, spesso è opportuno specificare una dimensione JVM fissa ragionevole e utilizzare le impostazioni predefinite.

Se le impostazioni predefinite non sono adatte, è importante stabilire un metodo per monitorare e valutare le prestazioni di GC. Farlo prima di provare a regolare la JVM. Questo processo può includere fattori di monitoraggio, tra cui la dimensione dell’heap, l’algoritmo e altri aspetti.

Alcune scelte comuni sono:

  • Controllo catalogo dettagliato:

    code language-none
    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    

Il registro risultante può essere acquisito da un visualizzatore GC come:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Oppure JConsole:

  • Queste impostazioni sono per una connessione JMX "wide open":

    code language-none
    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
  • Quindi collegarsi alla JVM con JConsole; vedere quanto segue:
    [https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html)

È possibile vedere la quantità di memoria utilizzata, gli algoritmi GC utilizzati, il tempo necessario per l'esecuzione e l'effetto di questo processo sulle prestazioni dell'applicazione. Senza di esso, la messa a punto è solo "manopole che girano casualmente".

NOTE
Ad Oracle, nella VM sono disponibili informazioni su:
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2