Uw AEM controleren en onderhouden

Nadat uw AEM instanties zijn opgesteld zullen bepaalde taken nodig zijn om hun verrichting, prestaties en integriteit te controleren en te handhaven.

Een belangrijke factor hierbij is dat u, om potentiële problemen te herkennen, moet weten hoe uw systemen er onder normale omstandigheden uitzien en zich gedragen. Dit kan het best worden gedaan door het systeem te controleren en informatie over een bepaalde periode te verzamelen.

Vinkje	Overwegingen	Opmerkingen / Handelingen
Back-upplan.		Zie hoe te Back-up maken van uw exemplaar.
Rampenherstelplan.	De richtlijnen voor noodherstel van uw bedrijf.
Er is een systeem voor foutcontrole beschikbaar voor het melden van problemen.	Bijvoorbeeld: bugzilla, jiraof een van de vele andere.
Bestandssystemen worden gecontroleerd.	De CRX-opslagplaats zal "bevriezen" als er onvoldoende vrije schijfruimte is. Het wordt hervat zodra er ruimte beschikbaar is.	" *ERROR* LowDiskSpaceBlocker"-berichten kunnen in het logbestand worden weergegeven wanneer er weinig vrije ruimte is.
Logbestanden worden gecontroleerd.
Systeembewaking wordt (voortdurend) op de achtergrond uitgevoerd.	Inclusief CPU-, geheugen-, schijf- en netwerkgebruik. Gebruik bijvoorbeeld iostat / vmstat / perfmon.	De geregistreerde gegevens worden visualiseerd en kunnen voor het volgen van prestatiesproblemen worden gebruikt. Onbewerkte gegevens zijn ook toegankelijk.
AEM prestaties worden gecontroleerd.	Inclusief Aanvraagtellers om verkeersniveaus te controleren.	Indien een aanzienlijk of langdurig prestatieverlies wordt vastgesteld, moet een grondig onderzoek worden ingesteld.
U volgt uw Replication Agents.
Workflowinstanties regelmatig leegmaken.	Grootte opslagplaats en workflowprestaties.	Zie Regelmatig leegmaken van workflowinstanties.

Back-ups

Het is een goede gewoonte back-ups te maken van:

• Uw software-installatie - voor/na belangrijke wijzigingen in de configuratie
• De inhoud die binnen de gegevensbank wordt gehouden - regelmatig

Uw bedrijf zal waarschijnlijk een reservebeleid hebben dat u zult moeten volgen, extra overwegingen van wat aan steun en wanneer omvatten:

• hoe kritisch het systeem en de gegevens zijn.
• hoe vaak de software of gegevens worden gewijzigd.
• gegevensvolume; De capaciteit kan af en toe een probleem zijn, evenals de tijd nodig om de steun uit te voeren.
• of uw back-up kan worden gemaakt terwijl gebruikers online zijn; en zo mogelijk, wat is de invloed op de prestaties.
• de geografische spreiding van de gebruikers; d.w.z. wanneer is de beste tijd om een back-up te maken (om de impact tot een minimum te beperken)?
• uw beleid voor noodherstel; zijn er richtsnoeren over waar de back-upgegevens moeten worden opgeslagen (bijv. buiten de locatie, specifiek medium, enz.).

Vaak wordt een volledige back-up gemaakt met regelmatige tussenpozen (bijvoorbeeld dagelijks, wekelijks of maandelijks), met incrementele back-ups tussen (bijvoorbeeld uur, dag of week).

Back-up maken van de software-installatie

Maak na de installatie of na belangrijke wijzigingen in de configuratie een back-up van de software-installatie.

Om dit te doen, moet u back-up maken van de gehele opslagplaats en dan:

1. Stop AEM.
2. Maak een back-up van het gehele <cq-installation-dir> van uw bestandssysteem.

Back-up maken van uw opslagplaats

De Back-up en herstel in de CRX-documentatie worden alle problemen besproken die te maken hebben met back-ups van de CRX-opslagplaats.

Voor meer informatie over het maken van een online "hot" back-up raadpleegt u Een online back-up maken.

Versie leegmaken

De Purperen is bedoeld voor het verwijderen van de versies van een knooppunt of een hiërarchie van knooppunten in uw opslagplaats. Het belangrijkste doel is om u te helpen de grootte van uw opslagplaats te verminderen door oude versies van uw knopen te verwijderen.

Deze sectie behandelt onderhoudswerkzaamheden met betrekking tot de versieeigenschap van AEM. De Versie wissen is bedoeld voor het verwijderen van de versies van een knooppunt of een hiërarchie van knooppunten in uw opslagplaats. Het belangrijkste doel is om u te helpen de grootte van uw opslagplaats te verminderen door oude versies van uw knopen te verwijderen.

Overzicht

De Purperen is beschikbaar als wekelijkse onderhoudstaak. Alvorens het voor het eerst te gebruiken moet het worden toegevoegd, dan gevormd. Daarna kan het op verzoek of wekelijks worden uitgevoerd.

Versies van een website wissen

Ga als volgt te werk om versies van een website te wissen:

1. Ga naar de Gereedschappen console, selecteert u Bewerking, Onderhoud vervolgens Wekelijks onderhoudvenster.

2. Selecteren + Toevoegen in de bovenste werkbalk.

   

3. Selecteren Versie wissen in de vervolgkeuzelijst in het dialoogvenster Nieuwe taak toevoegen . Vervolgens Opslaan.

   

4. De Versie wissen taak wordt toegevoegd. Met de kaartacties kunt u:

   • Selecteren - extra acties worden weergegeven op de bovenste werkbalk
   • Uitvoeren - om de gevormde zuivering onmiddellijk in werking te stellen
   • Configureren - voor het configureren van de wekelijkse zuiveringstaak

   

5. Selecteer Configureren handeling om de webconsole te openen voor Taak voor het opruimen van WCM-versie op dag-CQ, waar u kunt configureren:

   

   • Paden wissen
     Stelt het beginpad in van de inhoud die moet worden gewist; bijvoorbeeld:
     /content/wknd.

     LET OP

     Het wordt ten zeerste aanbevolen voor elk van uw websites meerdere paden te definiëren.

     Als u een pad met te veel kinderen definieert, kan dit de tijd die nodig is om het leegmaken uit te voeren aanzienlijk langer maken.

   • Versies recursief wissen

     • Schakel deze optie uit als u alleen het knooppunt dat door het pad wordt gedefinieerd, wilt leegmaken.
     • Selecteer deze optie als u het knooppunt dat door het pad en de onderliggende knooppunten wordt gedefinieerd, wilt leegmaken.

   • Maximum aantal versies
     Stel het maximumaantal versies (voor elk knooppunt) in dat u wilt behouden. Laat leeg om deze instelling niet te gebruiken.

   • Minimum aantal versies
     Stel het minimale aantal versies (voor elk knooppunt) in dat u wilt behouden. Laat leeg om deze instelling niet te gebruiken.

   • Maximale versieleeftijd
     Stel de maximale versiepagina in dagen in (voor elk knooppunt) die u wilt behouden. Laat leeg om deze instelling niet te gebruiken.
     Vervolgens Opslaan.

6. Navigeren naar/terugkeren naar de Wekelijks onderhoudvenster venster en selecteer Uitvoeren om het proces onmiddellijk te starten.

Droog uitvoeren - De console analyseren

De klassieke interface biedt een Droog optie van:

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

In dit proces worden alle knooppunten weergegeven die zijn verwerkt. Tijdens het proces, kan een knoop één van de volgende status hebben:

• ignore (not versionnable): het knooppunt ondersteunt geen versiebeheer en wordt tijdens het proces genegeerd.

• ignore (no version): het knooppunt heeft geen versie en wordt tijdens het proces genegeerd.

• retained: het knooppunt is niet gewist.

• purged: Het knooppunt wordt gewist.

Bovendien verstrekt de console nuttige informatie over de versies:

• V 1.0: het versienummer.

• V 1.0.1*: de ster geeft aan dat de versie de huidige (basis)versie is en niet kan worden gewist.

• Thu Mar 15 2012 08:37:32 GMT+0100: de datum van de versie.

In het volgende voorbeeld:

• De Shirts versies worden gewist omdat hun versieleeftijd langer is dan 2 dagen.
• De Tonga Fashions! versies worden gewist omdat het aantal versies groter is dan 5.

Werken met auditrecords en logbestanden

Op verschillende plaatsen zijn controledossiers en logbestanden met betrekking tot Adobe Experience Manager (AEM) te vinden. Hieronder vindt u een overzicht van waar u kunt vinden.

Werken met logbestanden

AEM WCM registreert gedetailleerde logboeken. Nadat u QuickStart hebt uitpakken en gestart, kunt u logbestanden vinden:

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

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

Bestandsrotatie logbestand

De omwenteling van het dossier van het logboek verwijst naar het proces dat de groei van dossier door nieuw dossier periodiek te creëren beperkt. In AEM wordt een logbestand met de naam error.log eenmaal per dag worden geroteerd volgens de volgende regels:

• De error.log de naam van het bestand wordt gewijzigd volgens het patroon {original_filename} .yyyy-MM-dd. Op 11 juli 2010 is de naam van het huidige logbestand bijvoorbeeld gewijzigd error.log-2010-07-10, dan een nieuwe error.og wordt gemaakt.

• Eerdere logbestanden worden niet verwijderd. Het is dus uw verantwoordelijkheid om oude logbestanden regelmatig te wissen om het schijfgebruik te beperken.

De logbestanden zoeken

Verschillende logbestanden worden opgeslagen op de bestandsserver waarop u AEM hebt geïnstalleerd:

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

  • access.log
    Alle verzoeken om toegang tot AEM WCM en de opslagplaats worden hier geregistreerd.

  • audit.log
    Moderatiehandelingen worden hier geregistreerd.

  • error.log
    Foutberichten (van verschillende ernst) worden hier geregistreerd.

  • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
    Dit logboek wordt alleen gebruikt als Dynamic Media is ingeschakeld. Het verstrekt statistieken en analytische informatie die voor het analyseren van gedrag van het interne proces ImageServer wordt gebruikt.

  • request.log
    Elk toegangsverzoek wordt hier geregistreerd samen met de reactie.

  • s7access-<yyyy>-<mm>-<dd>.log
    Dit logboek wordt alleen gebruikt als Dynamic Media is ingeschakeld. Het s7access logboek registreert elk verzoek aan Dynamic Media doorheen /is/image en /is/content.

  • stderr.log
    Bevat foutberichten, opnieuw van verschillende niveaus van ernst, die tijdens het opstarten worden gegenereerd. Standaard is het logniveau ingesteld op
    Warning ( WARN)

  • stdout.log
    Bevat logboekberichten die op gebeurtenissen tijdens opstarten wijzen.

  • upgrade.log
    Verstrekt een logboek van alle verbeteringsverrichtingen die van de
    com.day.compat.codeupgrade en com.adobe.cq.upgradesexecutor pakketten.

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

  • revision.log
    Informatie over Revisie-journalistiek.

Het FOUTOPSPORINGSlogniveau activeren

Het standaardlogniveau (Configuratie van Apache Sling-logboekregistratie) is Informatie, zodat worden de foutopsporingsberichten niet geregistreerd.

Om het debug logboekniveau voor een Logger te activeren, plaats het bezit org.apache.sling.commons.log.level om fouten op te sporen in de opslagplaats. Bijvoorbeeld, aan /libs/sling/config/org.apache.sling.commons.log.LogManager om het global Apache Sling Logging.

Een lijn in zuivert dossier begint gewoonlijk met DEBUG, dan verstrekt het logboekniveau, de installeractie en het logboekbericht. Bijvoorbeeld:

DEBUG 3 WebApp Panel: WebApp successfully deployed

De logniveaus zijn als volgt:

0	Fatale fout	De handeling is mislukt en het installatieprogramma kan niet doorgaan.
1	Fout	De handeling is mislukt. De installatie gaat door, maar een deel van AEM WCM is niet correct geïnstalleerd en werkt niet.
2	Waarschuwing	De actie is geslaagd maar heeft problemen ondervonden. AEM WCM werkt mogelijk niet correct.
3	Informatie	De actie is geslaagd.

Een aangepast logbestand maken

In bepaalde omstandigheden wilt u mogelijk een aangepast logbestand met een ander logniveau maken. U kunt dit in de repository doen door:

1. Maak een nieuwe configuratiemap ( sling:Folder) voor uw project /apps/<project-name>/config.

2. Onder /apps/<project-name>/config, maakt u een knooppunt voor het nieuwe Logboekconfiguratie Apache Sling Logging:

   • Naam: org.apache.sling.commons.log.LogManager.factory.config-<identifier> (aangezien dit een Logger is)

     Wanneer <identifier> wordt vervangen door vrije tekst die u (moet) invoeren om het exemplaar te identificeren (u kunt deze informatie niet weglaten).

     Bijvoorbeeld, org.apache.sling.commons.log.LogManager.factory.config-MINE

   • Type: sling:OsgiConfig

   OPMERKING

   Hoewel het geen technische eis is, is het raadzaam <identifier> uniek.

3. Stel de volgende eigenschappen in voor dit knooppunt:

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

     Type: String

     Waarde: het logbestand specificeren; bijvoorbeeld: logs/myLogFile.log

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

     Type: String[] (String + Multi)

     Waarde: specificeert de diensten OSGi waarvoor de Logger berichten moet registreren; bijvoorbeeld:

     • org.apache.sling
     • org.apache.felix
     • com.day

   • Naam: org.apache.sling.commons.log.level

     Type: String

     Waarde: Geef het vereiste logniveau op ( debug, info, warn of error); bijvoorbeeld debug

   • Configureer de overige parameters naar wens:

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

       Type: String

       Waarde: het patroon van het logbericht specificeren, indien nodig; bijvoorbeeld:

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

   OPMERKING

   org.apache.sling.commons.log.pattern ondersteunt maximaal zes argumenten.

   {0} The timestamp of type java.util.Date

   {1} de logboekmarkering

   {2} the name of the current thread

   {3} de naam van de logboekregistratie

   {4} het logniveau

   {5} het logbericht

   Als de logboekvraag a omvat Throwable de stacktrace wordt toegevoegd aan het bericht.

   LET OP

   org.apache.sling.commons.log.names moet een waarde hebben.

   OPMERKING

   Paden voor logschrijvers zijn relatief ten opzichte van de crx-quickstart locatie.

   Daarom wordt een logbestand opgegeven als:

   logs/thelog.log

   schrijft naar:

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

   En een logbestand dat is opgegeven als:

   ../logs/thelog.log

   schrijft naar een map:

   <cq-installation-dir>/logs/
   (d.w.z. naast <cq-installation-dir>/crx-quickstart/)

4. Deze stap is alleen nodig wanneer een nieuwe schrijver is vereist (dat wil zeggen met een andere configuratie dan de standaardschrijver).

   LET OP

   Een nieuwe configuratie van de schrijver van het Registreren wordt slechts vereist wanneer het bestaande gebrek niet geschikt is.

   Als geen expliciete Schrijver wordt gevormd zal het systeem automatisch een impliciete Schrijver produceren die op het gebrek wordt gebaseerd.

   Onder /apps/<project-name>/config, maakt u een knooppunt voor het nieuwe Configuratie van auteur van Apache Sling Logging:

   • Naam: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (omdat dit een schrijver is)

     Net als bij de Logger <identifier> wordt vervangen door vrije tekst die u (moet) invoeren om het exemplaar te identificeren (u kunt deze informatie niet weglaten). Bijvoorbeeld, org.apache.sling.commons.log.LogManager.factory.writer-MINE

   • Type: sling:OsgiConfig

   OPMERKING

   Hoewel het geen technische eis is, is het raadzaam <identifier> uniek.

   Stel de volgende eigenschappen in voor dit knooppunt:

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

     Type: String

     Waarde: geeft het logbestand op, zodat het overeenkomt met het bestand dat is opgegeven in het logbestand;

     in dit voorbeeld: ../logs/myLogFile.log.

   • Configureer de overige parameters naar wens:

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

       Type: Long

       Waarde: het aantal logbestanden opgeven dat u wilt behouden; bijvoorbeeld: 5

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

       Type: String

       Waarde: specificeren zoals vereist om de omwenteling van het dossier door grootte/datum te controleren; bijvoorbeeld: '.'yyyy-MM-dd

   OPMERKING

   org.apache.sling.commons.log.file.size Hiermee bepaalt u de rotatie van het logbestand door een van de volgende instellingen in te stellen:

   • een maximale bestandsgrootte
   • een datum-/tijdschema

   om aan te geven wanneer een nieuw bestand wordt gemaakt (en de naam van het bestaande bestand wordt gewijzigd volgens het naampatroon).

   • Een formaatlimiet kan met een getal worden opgegeven. Als er geen grootteindicator is opgegeven, wordt deze gebruikt als het aantal bytes. U kunt ook een van de grootteindicatoren toevoegen - KB, MB, of GB (case wordt genegeerd).
   • Een tijd-/datumschema kan als een java.util.SimpleDateFormat patroon. Hiermee wordt de periode gedefinieerd waarna het bestand wordt geroteerd. ook het achtervoegsel dat aan het geroteerde dossier (voor identificatie) wordt toegevoegd.

   De standaardwaarde is '.'jjjj-MM-dd (voor dagelijkse logrotatie).

   Bijvoorbeeld, om middernacht van 20 Januari 2010 (of wanneer het eerste logboekbericht na dit voorkomt om precies te zijn), zal …/logs/error.log worden anders genoemd aan …/logs/error.log.2010-01-20. Logboekregistratie voor 21 januari wordt uitgevoerd naar (een nieuw en leeg) …/logs/error.log totdat de logbestanden bij de volgende wijziging van de dag worden doorgehaald.

   '.'yyyy-MM	Rotatie aan het begin van elke maand
   '.'yyyy-ww	Rotatie op de eerste dag van elke week (afhankelijk van de landinstelling).
   '.'yyyy-MM-dd	Rotatie elke dag om middernacht.
   '.'yyyy-MM-dd-a	Roteren om middernacht en middag van elke dag.
   '.'yyyy-MM-dd-HH	Rotatie boven aan elk uur.
   '.'yyyy-MM-dd-HH-mm	Rotatie aan het begin van elke minuut.

   Opmerking: Wanneer u een tijd/datum opgeeft:

   1. U moet letterlijke tekst met enkele aanhalingstekens (' ') "escape"-tekens gebruiken;

      dit om te voorkomen dat bepaalde tekens worden geïnterpreteerd als patroonletters.

   2. Gebruik alleen tekens die zijn toegestaan voor een geldige bestandsnaam op een willekeurige plaats in de optie.

5. Lees het nieuwe logbestand met het gekozen gereedschap.

   Het logbestand dat in dit voorbeeld wordt gemaakt, wordt ../crx-quickstart/logs/myLogFile.log.

De Felix-console biedt ook informatie over de ondersteuning voor het verkooplogboek op ../system/console/slinglog; bijvoorbeeld https://localhost:4502/system/console/slinglog.

Controleregisters zoeken

Er worden auditrecords bijgehouden om een overzicht te geven van wie wat heeft gedaan en wanneer. Er worden verschillende auditverslagen gegenereerd voor zowel AEM WCM- als OSGi-gebeurtenissen.

AEM WCM-auditrecords die worden weergegeven bij het ontwerpen van pagina's

1. Open een pagina.

2. Vanuit het zijpaneel kunt u de tab selecteren met het vergrendelingspictogram en vervolgens dubbelklikken op Logboek controleren…

3. Er wordt een nieuw venster geopend met de lijst met auditrecords voor de huidige pagina.

   

4. Klikken OK wanneer u het venster wilt sluiten.

AEM WCM-controlegegevens in de opslagplaats

Binnen de /var/audit map, worden auditrecords bijgehouden op basis van de bron. U kunt naar beneden boren tot u de individuele verslagen en de informatie kunt zien zij bevatten.

Deze vermeldingen bevatten dezelfde gegevens als bij het bewerken van een pagina.

OSGi-auditrecords van de webconsole

OSGi-gebeurtenissen genereren ook controlegegevens die kunnen worden afgeleid uit de Configuratiestatus tab -> Logbestanden in de AEM webconsole:

Uw replicatieagents controleren

U kunt uw replicatiewachtrijen om te ontdekken wanneer een rij of neer of geblokkeerd is - die op zijn beurt op een probleem met een het publiceren instantie of extern systeem zou kunnen wijzen:

• zijn alle vereiste rijen ingeschakeld?

• zijn om het even welke gehandicapte rijen nog vereist?

• alles enabled wachtrijen moeten de status hebben idle of active, die de normale werking aangeven; geen rijen zouden moeten zijn blocked, wat vaak een teken is van problemen aan de kant van de ontvangers.

• als de grootte van de rij in tijd groeit, kan dit op een geblokkeerde rij wijzen.

Om een replicatieagent te controleren:

1. Toegang krijgen tot Gereedschappen in AEM.

2. Klikken Replicatie.

3. Dubbelklik op de koppeling naar agents voor de juiste omgeving (links of rechts); bijvoorbeeld Medewerkers op auteur.

   Het resulterende venster toont een overzicht van al uw replicatieagenten voor het auteursmilieu, met inbegrip van hun doel en status.

4. Klik de aangewezen agentennaam (die een verbinding is) om gedetailleerde informatie over die agent te tonen:

   

   Hier kunt u:

   • Zie of de agent wordt toegelaten.

   • Zie het doel van eventuele replicaties.

   • Zie of de replicatierij momenteel actief (toegelaten) is.

   • Zie of er items in de wachtrij staan.

   • Vernieuwen of Wissen de weergave van wachtrijitems bijwerken; dit helpt u punten te zien ingaan en de rij verlaten.

   • Logboek weergeven om tot het logboek van om het even welke acties door de replicatieagent toegang te hebben.

   • Verbinding testen naar de doelinstantie.

   • Opnieuw forceren indien nodig op alle wachtrij-items.

   LET OP

   Gebruik de koppeling "Verbinding testen" niet voor het selectievakje Reverse Replication Outbox op een publicatie-instantie.

   Als een replicatietest voor een Postbus rij wordt uitgevoerd, om het even welke punten die ouder zijn dan de testreplicatie zullen met elke omgekeerde replicatie opnieuw worden verwerkt.

   Als dergelijke items al in een wachtrij staan, kunt u ze vinden met de volgende JCR-query voor XPath en moet u ze verwijderen.

   /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

Opnieuw kunt u een oplossing ontwikkelen om alle replicatieagenten te ontdekken (onder worden gevestigd /etc/replication/author of /etc/replication/publish), controleert u vervolgens de status van de agent ( enabled, disabled) en de onderliggende wachtrij ( active, idle, blocked).

Monitorprestaties

Optimalisatie van prestaties is een interactief proces dat tijdens de ontwikkeling de nadruk krijgt. Na plaatsing wordt het gewoonlijk herzien na specifieke intervallen of gebeurtenissen.

Methoden die worden gebruikt bij het verzamelen van informatie voor optimalisatie kunnen ook worden gebruikt voor doorlopende bewaking.

Hieronder worden gemeenschappelijke prestatieproblemen opgesomd die zich voordoen, samen met voorstellen voor het opsporen en bestrijden van deze problemen.

Gebied	Symptom(s)	Capaciteit verhogen…	Volume verkleinen…
Client	Hoog CPU-gebruik van de client.	Installeer een client-CPU met hogere prestaties.	Vereenvoudig de lay-out (HTML).
	Laag CPU-gebruik van de server.	Voer een upgrade uit naar een snellere browser.	Cache op de client verbeteren.
	Sommige clients zijn snel, sommige traag.
Server
Netwerk	Het CPU-gebruik is laag op zowel servers als clients.	Verwijder netwerkknelpunten.	Verbeter/optimaliseer de configuratie van het cliëntgeheime voorgeheugen.
	Lokaal bladeren op de server is (relatief) snel.	Verhoog de netwerkbandbreedte.	Verminder het "gewicht" van uw webpagina's (bijvoorbeeld minder afbeeldingen, geoptimaliseerde HTML).
Webserver	Het CPU-gebruik op de webserver is hoog.	Cluster uw webservers.	Verminder de hits per pagina (bezoek).
		Gebruik een taakverdelingsmechanisme voor hardware.
Toepassing	Het CPU-gebruik van de server is hoog.	Cluster uw AEM.	Zoeken naar CPU- en geheugenhogs en deze elimineren (gebruik coderevisie, timinguitvoer, enz.).
	Hoge geheugenconsumptie.		Verbeter caching op alle niveaus.
	Lage responstijd.		Sjablonen en componenten optimaliseren (bijvoorbeeld structuur, logica).
Bewaarplaats
Cache

Prestatieproblemen kunnen het gevolg zijn van een aantal oorzaken die niets te maken hebben met uw website, zoals tijdelijke vertragingen in de verbindingssnelheid, CPU-belasting en nog veel meer.

Het kan ook gevolgen hebben voor al uw bezoekers of alleen voor een deel ervan.

Al deze informatie moet worden verkregen, gesorteerd en geanalyseerd voordat u de algemene prestaties kunt optimaliseren of specifieke problemen kunt oplossen.

• Voordat u een prestatieprobleem ervaart:

  • zoveel mogelijk informatie verzamelen om onder normale omstandigheden een goede werkkennis van het systeem op te bouwen

• Wanneer u een prestatieprobleem ondervindt:

  • proberen deze te repliceren met een (of bij voorkeur meer) standaardwebbrowser, op een andere client waarvan u weet dat deze goede algemene prestaties levert en/of op de server zelf (indien mogelijk)

  • controleren of er iets (met betrekking tot het systeem) binnen een passende tijdspanne is gewijzigd en of een van deze wijzigingen van invloed kan zijn geweest op de prestaties

  • vragen stellen zoals:

    • komt dit probleem alleen op specifieke tijdstippen voor ?
    • komt de kwestie slechts op specifieke pagina's voor?
    • worden andere verzoeken ingewilligd ?

  • zoveel mogelijk informatie verzamelen om onder normale omstandigheden met uw kennis van het systeem te kunnen vergelijken:

Gereedschappen voor het bewaken en analyseren van prestaties

Hieronder vindt u een kort overzicht van enkele gereedschappen die beschikbaar zijn voor het bewaken en analyseren van de prestaties.

Sommige hiervan zijn afhankelijk van uw besturingssysteem.

Gereedschap	Wordt gebruikt om te analyseren...	Gebruik / Meer informatie...
request.log	Responstijden en gelijktijdige toediening.	Het interpreteren van request.log.
sporen	Pagina wordt geladen	Unix/Linux bevelen om systeemvraag en signalen te volgen. Het logniveau verhogen tot INFO. Analyseer het aantal pagina's dat per aanvraag wordt geladen, welke pagina's enzovoort.
Draad-dumpen	Bekijk JVM-threads. Identificeer contouren, sluizen en lange looptijden.	Afhankelijk van het besturingssysteem: - Unix/Linux: kill -QUIT <pid> - Windows (consolemodus): Ctrl-einde Er zijn ook analyseprogramma's beschikbaar, zoals TDA.
Heap Dumps	Onvoldoende geheugen, wat langzame prestaties tot gevolg heeft.	Voeg het volgende toe: -XX:+HeapDumpOnOutOfMemoryError optie aan de vraag van java aan AEM. Zie de Opties/vlaggen voor JVM-pagina voor probleemoplossing.
Systeemaanroepen	Problemen met timing vaststellen.	verzoekt System.currentTimeMillis() of com.day.util.Timing wordt gebruikt om tijdstempels van uw code te produceren, of via HTML-opmerkingen. Opmerking: Deze moeten zo worden geïmplementeerd dat ze indien nodig kunnen worden geactiveerd/gedeactiveerd; wanneer een systeem soepel functioneert , zal de overhead van het verzamelen van statistieken niet nodig zijn .
Apache Bench	Identificeer geheugenlekken, selectief analyseer reactietijd.	basisgebruik is: ab -k -n <requests> -c <concurrency> <url> Zie Apache Bench en de Ab man page voor volledige informatie.
Zoekanalyse		Voer onderzoeksvragen offline uit, identificeer reactietijd van vraag, test en bevestig resultaatreeks.
JMeter	Belastings- en functionele tests.	https://jmeter.apache.org/
JProfiler	Uitgebreide CPU- en geheugenprofilering.	https://www.ej-technologies.com/
Java Flight Recorder	Java Flight Recorder (JFR) is een hulpmiddel voor het verzamelen van diagnostische en profilerende gegevens over een lopende toepassing van Java.	https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr004.html#BABJJEEE
JConsole	Bekijk JVM-metriek en -threads.	Gebruik: jconsole Zie jconsole en Prestaties controleren met behulp van JConsole. Opmerking: Met JDK 1.8 is JConsole uitbreidbaar met plug-ins; bijvoorbeeld Top of TDA (Thread Dump Analyzer).
Java VisualVM	Bekijk JVM-metriek, threads, geheugen en profilering.	Gebruik: visualvm of visualvm Zie visualvm en Prestaties bewaken met behulp van (J)VisualVM. Opmerking: Met JDK 1.8, is VisualVM verlengbaar met stop-ins. VisualVM wordt stopgezet na JDK 9. Gebruik in plaats hiervan de Java-vluchtrecorder.
worstjes/resten, laatste	De diepte vraag van de kernel en procesanalyse (Unix).	Unix/Linux-opdrachten.
Timingstatistieken	Zie timingstatistieken voor paginerendering.	Om timatiestatistieken voor paginerendering te zien kunt u gebruiken Ctrl-Shift-U samen met ?debugClientLibs=true ingesteld in de URL.
Hulpprogramma voor CPU- en geheugenanalyse	Wordt gebruikt bij het analyseren van langzame aanvragen tijdens de ontwikkeling.	Bijvoorbeeld: YourKit. of de Java Flight Recorder.
Informatie verzamelen	De huidige staat van uw installatie.	Als u zoveel mogelijk weet over de installatie, kunt u ook bijhouden wat een wijziging in de prestaties heeft veroorzaakt en of deze wijzigingen gerechtvaardigd zijn. Deze gegevens moeten regelmatig worden verzameld, zodat u gemakkelijk significante veranderingen kunt zien.

Het interpreteren van request.log

In dit bestand wordt basisinformatie geregistreerd over elk verzoek aan AEM. Hieruit kunnen waardevolle conclusies worden getrokken.

De request.log biedt een ingebouwde manier om te zien hoe lang verzoeken duren. Voor ontwikkelingsdoeleinden is het nuttig om tail -f de request.log en let op langzame reactietijden. Een groter object analyseren request.log wij bevelen de gebruik van rlog.jar waarmee u kunt sorteren en filteren op responstijden.

We raden u aan om de pagina's met de notatie 'traag' te isoleren van de request.logen deze vervolgens individueel af te stemmen voor betere prestaties. Dit gebeurt meestal door prestatiemetriek per component op te nemen of een hulpmiddel te gebruiken om prestaties te profileren zoals [yourkit](https://www.yourkit.com/).

Bewaking van verkeer op uw website

Het aanvraaglogboek registreert elke ingediende aanvraag, samen met het gegeven antwoord:

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

Door alle GET-items in een bepaalde periode op te tellen (bijvoorbeeld over verschillende periodes van 24 uur), kunt u instructies geven over het gemiddelde verkeer op uw website.

De reactietijden van de controle met request.log

Een goed uitgangspunt voor prestatiesanalyse is het verzoeklogboek:

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

Het logbestand ziet er als volgt uit (de regels worden ingekort om het eenvoudig te houden):

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

Dit logboek heeft één lijn per verzoek of reactie:

• De datum waarop elk verzoek of antwoord is ingediend.

• The number of the request, in square brackets. Dit aantal komt voor het verzoek en de reactie overeen.

• Een pijl die aangeeft of dit een aanvraag (pijl die naar rechts wijst) of een reactie (pijl naar links) is.

• Voor verzoeken bevat de regel:

  • de methode (gewoonlijk GET, HEAD of POST)
  • de gevraagde pagina
  • het protocol

• Voor reacties bevat de regel:

  • de statuscode (200 betekent "succes", 404 betekent "pagina niet gevonden"
  • het MIME-type
  • de responstijd

Met behulp van kleine scripts kunt u de vereiste informatie uit het logbestand extraheren en de gewenste statistieken samenstellen. Hieruit kunt u zien welke pagina's of typen pagina's langzaam zijn en of de prestaties over het geheel genomen bevredigend zijn.

De onderzoekreactie tijden van het toezicht met request.log

Zoekverzoeken worden ook in het logbestand geregistreerd:

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

Dus, zoals hierboven, kunt u manuscripten gebruiken om de relevante informatie te halen en statistieken op te bouwen.

Als u echter eenmaal de responstijd hebt bepaald, moet u misschien analyseren waarom het verzoek de tijd neemt die het nodig heeft en wat er kan worden gedaan om de reactie te verbeteren.

Het aantal en de gevolgen van gelijktijdige gebruikers controleren

Opnieuw request.log kan worden gebruikt om de samenhang en de reactie van het systeem daarop te controleren.

Er moeten tests worden uitgevoerd om te bepalen hoeveel gelijktijdige gebruikers het systeem kan verwerken voordat een negatieve invloed wordt waargenomen. Opnieuw kunnen de manuscripten worden gebruikt om resultaten uit het logboekdossier te halen:

• na te gaan hoeveel verzoeken binnen een bepaalde tijdspanne, bijvoorbeeld één minuut, worden ingediend
• de effecten te testen van een specifiek aantal gebruikers die allemaal op hetzelfde tijdstip (zo dicht mogelijk) dezelfde verzoeken indienen; Bijvoorbeeld 30 gebruikers die klikken Opslaan tegelijkertijd.

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

Het gebruiken van rlog.jar om verzoeken met lange duurtijden te vinden

AEM bevat diverse hulpgereedschappen in:
<cq-installation-dir>/crx-quickstart/opt/helpers

Eén van deze rlog.jar, kan worden gebruikt om snel te sorteren request.log zodat verzoeken op duur, van langste tot kortste tijd worden getoond.

De volgende opdracht toont de mogelijke argumenten:

$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.

U kunt bijvoorbeeld de opdracht uitvoeren door request.log bestand als parameter en geef de 10 eerste aanvragen weer die de langste duur hebben:

$ 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

Mogelijk moet u de afzonderlijke request.log bestanden als u deze bewerking wilt uitvoeren in een groot gegevensvoorbeeld.

Apache Bench

Om het effect van speciale gevallen (zoals afvalophaling, enz.) tot een minimum te beperken, wordt aangeraden een hulpmiddel te gebruiken zoals apachebench (zie bijvoorbeeld ab voor verdere documentatie) om geheugenlekken te helpen identificeren en selectief reactietijd te analyseren.

Apache Bench kan als volgt worden gebruikt:

$ 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)

De bovenstaande nummers zijn afkomstig van een standaard MAcBook Pro-laptop (medio 2010) die toegang heeft tot de geometrixx-bedrijfspagina, zoals opgenomen in een standaard AEM installatie. De pagina is heel eenvoudig, maar niet geoptimaliseerd voor prestaties.

apachebench geeft ook de tijd per verzoek als gemiddelde, over alle gezamenlijke verzoeken weer; zie Time per request: 54.595 [ms] (gemiddeld over alle gelijktijdige aanvragen). U kunt de waarde van de parameter voor gelijktijdige uitvoering wijzigen -c (aantal meerdere verzoeken om tegelijk uit te voeren) om effecten te zien.

Aanvraagtellers

De informatie over verzoekverkeer (aantal verzoeken tijdens een specifieke tijdspanne) geeft u een aanwijzing van de lading op uw geval. Deze informatie kan worden afgeleid uit request.log, hoewel het gebruiken van tellers gegevensinzameling zal automatiseren om u te laten zien:

• significante verschillen in activiteit ( dat wil zeggen onderscheid maken tussen " veel verzoeken " en " lage activiteit " )
• wanneer een instantie niet wordt gebruikt
• om het even welke nieuwe begin (tellers worden teruggesteld aan 0)

Om informatieinzameling te automatiseren kunt u een RequestFilter ook installeren om een teller op elk verzoek te verhogen. De veelvoudige tellers kunnen voor verschillende tijdsperioden worden gebruikt.

De verzamelde informatie kan worden gebruikt om aan te geven:

• belangrijke veranderingen in de activiteit
• een redundante instantie
• opnieuw opstarten (teller teruggesteld aan 0)

Opmerkingen HTML

Aanbevolen wordt dat elk project html comments voor serverprestaties. Er zijn veel goede openbare voorbeelden te vinden; Selecteer een pagina, open de paginabron voor weergave en schuif naar de onderkant. U ziet bijvoorbeeld de volgende code:

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

Prestaties controleren met behulp van JConsole

De opdracht Gereedschap jconsole is beschikbaar bij de JDK.

1. Start de AEM.

2. Uitvoeren jconsole.

3. Selecteer uw AEM en Verbinden.

4. Van binnen Local toepassing, dubbelklikken com.day.crx.quickstart.Main; het Overzicht zal als gebrek worden getoond:

   

   Hierna kunt u andere opties selecteren.

Prestaties bewaken met behulp van (J)VisualVM

Voor JDK 6-8, de hulpmiddelbevel visualvm is beschikbaar. Nadat u een JDK hebt geïnstalleerd kunt u:

1. Start de AEM.

   OPMERKING

   Als u Java 5 gebruikt, kunt u de opdracht -Dcom.sun.management.jmxremote argument naar de java-opdrachtregel die uw JVM start. JMX is standaard ingeschakeld in Java 6.

2. Voer een van beide uit:

   • jvisualvm: in de map JDK 1.6 bin (geteste versie)
   • visualvm: kan worden gedownload van VisualVM (versie met bloeding)

3. Van binnen Local toepassing, dubbelklikken com.day.crx.quickstart.Main; het Overzicht zal als gebrek worden getoond:

   

   Hierna kunt u andere opties selecteren, waaronder Monitor:

   

U kunt dit gereedschap gebruiken om thread-dumps en dumps voor geheugenkoppen te maken. Deze informatie wordt vaak gevraagd door het technische ondersteuningsteam.

Informatie verzamelen

Als u zoveel mogelijk weet wat u met de installatie kunt doen, kunt u nagaan wat een wijziging in de prestaties heeft veroorzaakt en of deze wijzigingen gerechtvaardigd zijn. Deze gegevens moeten regelmatig worden verzameld, zodat u gemakkelijk significante veranderingen kunt zien.

De volgende informatie kan nuttig zijn:

• Hoeveel auteurs werken met het systeem?
• Wat is het gemiddelde aantal paginanavigaties per dag?
• Hoeveel pagina's handhaaft u momenteel op dit systeem?
• Als u MSM gebruikt, wat is het gemiddelde aantal rollouts per maand?
• Wat is het gemiddelde aantal levende exemplaren per maand?
• Als u AEM Assets gebruikt, hoeveel middelen handhaaft u momenteel in Middelen?
• Wat is de gemiddelde omvang van de activa?
• Hoeveel sjablonen worden momenteel gebruikt?
• Hoeveel componenten worden momenteel gebruikt?
• Hoeveel verzoeken hebt u per uur op het auteurssysteem op piektijd?
• Hoeveel verzoeken per uur hebt u op het publicatiesysteem bij piektijd?

Hoeveel auteurs werken met het systeem?

Om het aantal auteurs te zien die het systeem sinds installatie hebben gebruikt gebruik de bevellijn:

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

Om het aantal auteurs te zien die op een bepaalde datum werken:

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

Wat is het gemiddelde aantal paginanavigaties per dag?

Om het totale aantal paginanavigaties te zien sinds de serverinstallatie een dataopslagvraag gebruikt; via CRXDE - Hulpmiddelen - Vraag:

• Type XPath

• Pad /

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

Bereken vervolgens het aantal dagen dat is verstreken sinds de installatie om het gemiddelde te berekenen.

Hoeveel pagina's handhaaft u momenteel op dit systeem?

Om het aantal pagina's momenteel op de server te zien gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

• Type XPath

• Pad /

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

Als u MSM gebruikt, wat is het gemiddelde aantal rollouts per maand?

Om het totale aantal rollouts sinds installatie te bepalen gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

• Type XPath

• Pad /

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

Bereken het aantal maanden dat is verstreken sinds de installatie om het gemiddelde te berekenen.

Wat is het gemiddelde aantal levende exemplaren per maand?

Om het totale aantal Actieve Kopieën te bepalen die sinds installatie worden gemaakt gebruikt een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

• Type XPath

• Pad /

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

Gebruik opnieuw het aantal maanden dat sinds installatie is verstreken om het gemiddelde te berekenen.

Als u AEM Assets gebruikt, hoeveel middelen handhaaft u momenteel in Middelen?

Als u wilt zien hoeveel DAM-middelen u momenteel beheert, gebruikt u een query voor de opslagplaats. via CRXDE - Hulpmiddelen - Vraag:

• Type XPath
• Pad /
• Query /jcr:root/content/dam//element(*, dam:Asset)

Wat is de gemiddelde omvang van de activa?

Om de totale grootte van te bepalen /var/dam map:

1. Gebruik WebDAV om de opslagplaats aan het lokale dossiersysteem in kaart te brengen.

2. Gebruik de opdrachtregel:

   cd /Volumes/localhost/var
   du -sh dam/
   

   U krijgt de gemiddelde grootte door de totale grootte te delen door het totale aantal elementen in /var/dam (hierboven verkregen).

Hoeveel sjablonen worden momenteel gebruikt?

Om het aantal malplaatjes momenteel op de server te zien gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

• Type XPath
• Pad /
• Query //element(*, cq:Template)

Hoeveel componenten worden momenteel gebruikt?

Om het aantal componenten te zien momenteel op de server gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

• Type XPath
• Pad /
• Query //element(*, cq:Component)

Hoeveel verzoeken hebt u per uur op het auteurssysteem op piektijd?

Om de verzoeken per uur te bepalen hebt u op het auteurssysteem bij piektijd:

1. Om het totale aantal verzoeken te bepalen sinds installatie gebruik de bevellijn:

   cd <cq-installation-dir>/crx-quickstart/logs
   grep -R "\->" request.log | wc -l
   

2. De begin- en einddatum bepalen:

   vim request.log
   G / 1G: for the last/first lines
   

   Gebruik deze waarden om het aantal uren te berekenen die sinds installatie zijn verstreken, dan het gemiddelde aantal verzoeken per uur.

Hoeveel verzoeken per uur hebt u op het publicatiesysteem bij piektijd?

Herhaal de bovenstaande procedure voor uw publicatieexemplaar.

Specifieke scenario's analyseren

Hieronder volgt een lijst met suggesties voor het controleren of er bepaalde prestatieproblemen optreden. De lijst is (helaas) niet volledig.

CPU bij 100%

Als de CPU van uw systeem constant op 100% draait, zie dan:

• De Knowledge Base:

  • Trage en geblokkeerde processen analyseren

Onvoldoende geheugen

Hoewel dergelijke fouten tijdens de ontwikkeling en het testen moeten worden ontdekt, kunnen bepaalde scenario's door glijden.

Als er onvoldoende geheugen beschikbaar is voor uw systeem, is dit op verschillende manieren zichtbaar, zoals prestatievermindering en foutmeldingen, waaronder de subtekst:

java.lang.OutOfMemoryError

Controleer in deze gevallen:

• De JVM-instellingen die worden gebruikt voor AEM starten

• De Knowledge Base:

  • Geheugenproblemen analyseren

I/O schijf

Als er onvoldoende schijfruimte beschikbaar is op uw systeem of als u merkt dat de schijf wordt vastgezet, zie:

• Of u inzameling van zuivert informatie hebt onbruikbaar gemaakt; dit kan op diverse plaatsen worden gevormd, die omvatten:

  • Apache Sling JSP Script Handler
  • Apache Sling Java Script Handler
  • Configuratie van Apache Sling-logboekregistratie
  • Bibliotheekbeheer CQ HTML
  • CQ WCM-foutopsporingsfilter
  • Logboeken

• Of en hoe u hebt gevormd Versie leegmaken

• De Knowledge Base:

  • Te veel geopende bestanden
  • Dagboek verbruikt te veel schijfruimte

Reguliere prestatievermindering

Als u ziet dat de prestaties van uw instantie achteruitgaan nadat u opnieuw hebt opgestart (soms een week of meer later), kunt u het volgende controleren:

• Onvoldoende geheugen

• De Knowledge Base:

  • Niet-gesloten sessies

JVM-tuning

De JVM (Java Virtual Machine) is aanzienlijk verbeterd op het gebied van tuning (vooral sinds Java 7). Daarom is het vaak handig om een redelijke, vaste JVM-grootte op te geven en de standaardinstellingen te gebruiken.

Als de standaardinstellingen niet geschikt zijn, is het belangrijk een methode vast te stellen om de GC-prestaties te controleren en te beoordelen voordat wordt geprobeerd de JVM af te stemmen. dit kan bestaan uit monitoringfactoren zoals heapgrootte , algoritme en andere aspecten .

Enkele algemene keuzen zijn:

• VerboseGC:

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

Het resulterende logboek kan door GC visualizer zoals worden opgenomen:

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

Of JConsole:

• Deze instellingen zijn bedoeld voor een "brede open" JMX-verbinding:

  -Dcom.sun.management.jmxremote \
   -Dcom.sun.management.jmxremote.port=8889 \
   -Dcom.sun.management.jmxremote.authenticate=false \
   -Dcom.sun.management.jmxremote.ssl=false
  

• Maak vervolgens verbinding met de JVM met de JConsole; zie:
  [https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html)

Zo kunt u zien hoeveel geheugen wordt gebruikt, welke GC-algoritmen worden gebruikt, hoe lang het duurt om te werken en welk effect dit heeft op de prestaties van uw toepassing. Zonder dit, is het stemmen enkel "willekeurig het draaien knopen".