Nadat uw AEM instanties worden opgesteld, moet u hun verrichting, prestaties, en integriteit controleren en handhaven.
Een belangrijke factor in dit verband is dat als u potentiële problemen wilt herkennen, u moet weten hoe uw systeem er onder normale omstandigheden uitziet en zich gedraagt. Deze mogelijkheid kan het best worden verwezenlijkt door het systeem te controleren en informatie in de loop van de tijd te verzamelen.
Controleren | 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 "bevriest" als er onvoldoende vrije schijfruimte is. Het wordt hervat nadat ruimte beschikbaar wordt. | " *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. |
Het is een goede gewoonte om back-ups te maken van:
Uw bedrijf heeft waarschijnlijk een reservebeleid dat u volgt, extra overwegingen van wat en wanneer aan file omvatten het volgende:
Vaak wordt een volledige steun genomen met regelmatige intervallen (bijvoorbeeld, dagelijks, wekelijks, of maandelijks), met stijgende steunen binnen tussen (bijvoorbeeld, uur, dag, of wekelijks).
Bij het implementeren van back-ups van uw productie-instanties, testen moet om ervoor te zorgen dat u de back-up kunt herstellen.
Zonder deze test is de back-up mogelijk nutteloos (worst case-scenario).
Voor meer informatie over back-upprestaties leest u de Back-upprestaties sectie.
Na installatie, of significante veranderingen in de configuratie, creeer een steun van uw softwareinstallatie.
Om deze taak te verwezenlijken, back-up maken van de gehele opslagplaats en dan:
<cq-installation-dir>
van uw bestandssysteem.Als u een externe toepassingsserver gebruikt, kunnen extra mappen zich op een andere locatie bevinden en moet er ook een back-up van worden gemaakt. Zie Hoe te om AEM met een Server van de Toepassing te installeren voor informatie over het installeren van toepassingsservers.
Incrementele back-up van de bestandsgegevensopslag wordt ondersteund. Wanneer u incrementele back-up voor andere componenten gebruikt (zoals de Lucene-index), moet u ervoor zorgen dat verwijderde bestanden ook worden gemarkeerd als verwijderd in de back-up.
Schijfspiegeling kan ook worden gebruikt als back-upmechanisme.
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 volledige informatie over het maken van een online "hot" back-up raadpleegt u Een online back-up maken.
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 primaire doel is om u te helpen de grootte van uw opslagplaats te verkleinen door oude versies van uw knooppunten te verwijderen.
De Purperen is beschikbaar als wekelijkse onderhoudstaak. Voordat u deze voor de eerste keer kunt gebruiken, moet u deze toevoegen en vervolgens configureren. Daarna kan het op verzoek of wekelijks worden uitgevoerd.
Ga als volgt te werk om versies van een website te wissen:
Ga naar de Gereedschappen console, selecteert u Bewerking, Onderhoud vervolgens Wekelijks onderhoudvenster.
Selecteren + Toevoegen in de bovenste werkbalk.
Selecteren Versie wissen in de vervolgkeuzelijst in het Nieuwe taak toevoegen in. Vervolgens Opslaan.
De Versie wissen taak is toegevoegd. Met de kaartacties kunt u:
Selecteer de Configureren handeling om de webconsole te openen voor Dag CQ WCM-versie opschoontaak, waar u kunt configureren:
Paden wissen
Stel het beginpad in van de inhoud die moet worden gewist, bijvoorbeeld /content/wknd
.
Adobe raadt u aan meerdere paden te definiëren voor elk van uw websites.
Als u een pad met te veel kinderen definieert, kan de tijd voor het leegmaken aanzienlijk langer worden.
Versies recursief wissen
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.
Navigeren naar/terugkeren naar de Wekelijks onderhoudvenster venster en selecteer Uitvoeren om het proces onmiddellijk te starten.
U kunt het dialoogvenster Klassieke UI gebruiken om een Droog van uw configuratie:
Opgeloste knooppunten kunnen niet worden hersteld zonder de opslagplaats te herstellen. Zorg voor uw configuratie door altijd een droge run uit te voeren alvorens te zuiveren.
De klassieke interface biedt een Droog optie van:
In dit proces worden alle knooppunten weergegeven die zijn verwerkt. Tijdens het proces kan een knooppunt een van de volgende statussen 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 leeggemaakt.
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:
Op verschillende plaatsen zijn controledossiers en logbestanden met betrekking tot Adobe Experience Manager (AEM) te vinden. Hieronder vindt u een overzicht van wat u kunt vinden en waar u het kunt vinden.
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/
De omwenteling van het dossier van het logboek verwijst naar het proces dat de groei van het dossier door een dossier periodiek te creëren beperkt. In AEM wordt een logbestand met de naam error.log
eenmaal per dag wordt 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.
Vorige logbestanden worden niet verwijderd, dus het is uw verantwoordelijkheid om regelmatig oude logbestanden op te schonen om het gebruik van de schijf te beperken.
Als u uw AEM-installatie upgrade, blijft elk bestaand logbestand dat niet meer door AEM wordt gebruikt, op de schijf staan. Je kunt ze zonder risico verwijderen. Alle nieuwe logitems worden geschreven in de nieuwe logbestanden.
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 de 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/segmentstore
journal.log
De logboeken van ImageServer en s7access zijn niet inbegrepen in Download volledig pakket dat van het systeem/console/status-Bundlelist pagina wordt geproduceerd. Voor ondersteuningsdoeleinden, als u Dynamic Media voegt u de logbestanden voor ImageServer en s7access toe wanneer u contact opneemt met de Klantenondersteuning.
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.
Verlaat het logboek bij zuivert logboekniveau niet langer dan noodzakelijk, omdat het talrijke logboekingangen produceert, die middelen verbruiken.
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. |
Wanneer u met Adobe Experience Manager werkt, zijn er verschillende methoden om de configuratie-instellingen voor dergelijke services te beheren. Zie OSGi configureren voor meer details en de aanbevolen werkwijzen.
In bepaalde omstandigheden, kunt u een dossier van het douanelogboek met een verschillend logboekniveau willen tot stand brengen. Voer de volgende handelingen uit in de opslagplaats:
Indien niet bestaand, creeer een configuratiemap ( sling:Folder
) voor uw project /apps/<project-name>/config
.
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>
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
Hoewel het geen technische vereiste is, is het raadzaam om uniek te maken <identifier>
.
Stel de volgende eigenschappen in op dit knooppunt:
Naam: org.apache.sling.commons.log.file
Type: String
Waarde: geef het logbestand op, bijvoorbeeld logs/myLogFile.log
Naam: org.apache.sling.commons.log.names
Type: String[] (String + Multi)
Waarde: specificeer de diensten OSGi waarvoor Logger berichten moet registreren; bijvoorbeeld, al het volgende:
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: geef het patroon van het bericht in het logboek op; bijvoorbeeld,
{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
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
, wordt de stacktrace toegevoegd aan het bericht.
org.apache.sling.commons.log.names moet een waarde hebben.
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 opgegeven als:
../logs/thelog.log
schrijft naar een map:
<cq-installation-dir>/logs/
(dus naast <cq-installation-dir>/crx-quickstart/
)
Deze stap is alleen nodig wanneer een nieuwe schrijver is vereist (dat wil zeggen met een andere configuratie dan de standaardschrijver).
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, produceert het systeem automatisch een impliciete Schrijver 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>
(een schrijver)
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
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: geef het logbestand op, zodat dit 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: geef het aantal logbestanden op dat u wilt behouden, bijvoorbeeld 5
Naam: org.apache.sling.commons.log.file.size
Type: String
Waarde: geef de vereiste waarde op om het roteren van het bestand op grootte/datum te bepalen, bijvoorbeeld '.'yyyy-MM-dd
org.apache.sling.commons.log.file.size
Hiermee bepaalt u de rotatie van het logbestand door een van de volgende instellingen in te stellen:
om aan te geven wanneer een nieuw bestand wordt gemaakt (en de naam van het bestaande bestand wordt gewijzigd volgens het naampatroon).
KB
, MB
, of GB
(case wordt genegeerd).java.util.SimpleDateFormat
patroon. Hiermee wordt de tijdsperiode gedefinieerd waarna het bestand wordt geroteerd. Het achtervoegsel dat aan het geroteerde bestand is toegevoegd (ter identificatie).De standaardwaarde is '.'jjjj-MM-dd (voor dagelijkse logrotatie).
Bijvoorbeeld om middernacht op 20 januari 2010 (of wanneer het eerste logboekbericht na deze datum precies wordt weergegeven), … /logs/error.log heet voortaan … /logs/error.log.2010-01-20. De aanmelding voor 21 januari wordt uitgevoerd naar (een nieuwe en lege) … /logs/error.log totdat het wordt overgedragen bij de volgende wijziging van de dag.
'.'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:
U moet letterlijke tekst met enkele aanhalingstekens (' ') "escape" (escape)";
Hiermee voorkomt u dat bepaalde tekens worden geïnterpreteerd als patroonletters.
Gebruik alleen tekens die zijn toegestaan voor een geldige bestandsnaam op een willekeurige plaats in de optie.
Lees het nieuwe logbestand met het gekozen gereedschap.
Het logbestand dat in dit voorbeeld wordt gemaakt, is ../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
.
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.
Open een pagina.
Vanuit het zijpaneel kunt u de tab selecteren met het vergrendelingspictogram en vervolgens dubbelklikken Logboek controleren…
Er wordt een nieuw venster geopend met de lijst met auditrecords voor de huidige pagina.
Klikken OK wanneer u het venster wilt sluiten.
Binnen de /var/audit
map, worden auditrecords bijgehouden op basis van de bron. U kunt naar beneden boren tot u individuele verslagen en de informatie ziet die zij bevatten.
Deze vermeldingen bevatten dezelfde gegevens als bij het bewerken van een pagina.
OSGi-gebeurtenissen genereren ook controlegegevens die kunnen worden afgeleid uit de Configuratiestatus tab -> Logbestanden in de AEM webconsole:
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 op normale verrichting wijzen; 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 het op een geblokkeerde rij wijzen.
Om een replicatieagent te controleren:
Toegang krijgen tot de Gereedschappen in AEM.
Klikken Replicatie.
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.
Klik de aangewezen agentennaam (die een verbinding is) om gedetailleerde informatie over die agent te tonen:
Hier kunt u:
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, worden om het even welke punten die ouder zijn dan de testreplicatie opnieuw verwerkt met elke omgekeerde replicatie.
Als dergelijke punten in een rij bestaan, kunnen zij met de volgende vraag van JCR van XPath worden gevonden en zouden moeten worden verwijderd.
/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
).
Optimalisatie van prestaties is een interactief proces dat tijdens de ontwikkeling de nadruk krijgt. Na plaatsing, wordt het herzien na specifieke intervallen of gebeurtenissen.
Methoden die worden gebruikt bij het verzamelen van informatie voor optimalisatie kunnen ook worden gebruikt voor doorlopende bewaking.
Specifiek beschikbare configuraties voor betere prestaties kan ook worden gecontroleerd.
Hieronder worden gemeenschappelijke prestatieproblemen weergegeven die zich voordoen, samen met voorstellen voor het opsporen en bestrijden van deze problemen.
Gebied | Symptoom | Capaciteit verhogen… | Volume verkleinen… |
---|---|---|---|
Client | Hoog CPU-gebruik van de client. | Installeer een client-CPU met hogere prestaties. | Vereenvoudig de indeling (HTML). |
Laag CPU-gebruik van de server. | Voer een upgrade uit naar een snellere browser. | Cache aan de clientzijde 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. | Zoek naar, en elimineer, cpu, en geheugenhogs (gebruik codeoverzicht en timingoutput). |
Hoog geheugenverbruik. | Verbeter caching op alle niveaus. | ||
Lage responstijden. | Sjablonen en componenten optimaliseren (bijvoorbeeld structuur, logica). | ||
Bewaarplaats | |||
Cache |
Prestatieproblemen kunnen het gevolg zijn van verschillende 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:
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:
zoveel mogelijk informatie verzamelen om onder normale omstandigheden met uw kennis van het systeem te kunnen vergelijken:
Hieronder vindt u een kort overzicht van enkele gereedschappen die beschikbaar zijn voor het bewaken en analyseren van de prestaties.
Sommige van deze gereedschappen 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 Analyseer het aantal pagina's dat per aanvraag wordt geladen en welke pagina's. |
Draad-dumpen | Bekijk JVM-threads. Identificeer inhoud, sloten, en lange looprunners. | Afhankelijk van het besturingssysteem: Er zijn ook analysehulpmiddelen beschikbaar, zoals TDA. |
Heap Dumps | Onvoldoende geheugen, waardoor de prestaties vertragen. | Voeg het volgende toe: Zie de Opties/vlaggen voor JVM-pagina voor probleemoplossing. |
Systeemaanroepen | Problemen met timing vaststellen. | roept aan Opmerking: Deze dingen implementeren zodat ze naar behoefte kunnen worden geactiveerd/gedeactiveerd; wanneer een systeem probleemloos werkt, is de overhead van het verzamelen van statistieken niet nodig. |
Apache Bench | Identificeer geheugenlekken, selectief analyseer reactietijd. | basisgebruik is:
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 geheugenanalyse. | 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 Java™-toepassing. | 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 visuaal 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™ Flight Recorder. |
worstjes/resten, laatste | Diepgaande kernel vraag en procesanalyse (UNIX®). | Unix/Linux-opdrachten. |
Timingstatistieken | Zie timingstatistieken voor het weergeven van pagina's. | Als u timingsstatistieken voor het weergeven van pagina's wilt zien, kunt u Ctrl-Shift-U samen met |
Hulpprogramma voor CPU- en geheugenanalyse |
Wordt gebruikt bij het analyseren van langzame aanvragen tijdens de ontwikkeling. | Bijvoorbeeld: YourKit. of de Java™ Flight Recorder. |
Informatieverzameling | 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. Verzamel deze metriek met regelmatige intervallen zodat u significante veranderingen gemakkelijk kunt zien. |
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 tail -f
de request.log
en let op langzame reactietijden. Een groter object analyseren request.log
, beveelt de Adobe de gebruik van rlog.jar
waarmee u kunt sorteren en filteren op reactietijden.
Adobe raadt aan de pagina ''slow'' pagina's te isoleren van de request.log
en deze vervolgens individueel af te stemmen voor betere prestaties. Prestatiegegevens per component opnemen of een hulpprogramma voor het maken van prestatieprofielen gebruiken, zoals [yourkit](https://www.yourkit.com/)
.
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 ingangen van de GET binnen specifieke periodes (bijvoorbeeld, over diverse periodes van 24 uur) in totaal te zijn, kunt u verklaringen over het gemiddelde verkeer op uw website doen.
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 het een aanvraag (pijl die naar rechts wijst) of een reactie (pijl naar links) is.
Voor verzoeken bevat de regel:
Voor reacties bevat de regel:
Met behulp van kleine scripts kunt u de vereiste informatie uit het logbestand extraheren en de gewenste statistieken samenstellen. Uit deze statistieken kunt u zien welke pagina's of typen pagina's langzaam zijn en of de prestaties over het geheel genomen bevredigend zijn.
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.
Nadat u echter de responstijd hebt bepaald, analyseert u waarom het verzoek de tijd neemt die nodig is en wat u kunt doen om de reactie te verbeteren.
Opnieuw de 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:
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
AEM bevat de volgende verschillende hulplijnen:
<cq-installation-dir>/crx-quickstart/opt/helpers
Een van deze gereedschappen, 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 tien 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
De persoon aaneenschakelen request.log
als u deze bewerking moet uitvoeren op een groot gegevensvoorbeeld.
Om het effect van speciale gevallen (zoals huisvuilinzameling) te minimaliseren, adviseert men om een hulpmiddel zoals te gebruiken apachebench
(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 pagina van het bedrijf Geometrixx, zoals deze is opgenomen in een standaard AEM installatie. De pagina is eenvoudig, maar niet geoptimaliseerd voor prestaties.
De 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.
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 automatiseert om u te laten zien:
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:
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 kunt de volgende code zien:
</body>
</html>
<!--
Page took 58 milliseconds to be rendered by server
-->
De opdracht Gereedschap jconsole
is beschikbaar bij de JDK.
Start de AEM.
Uitvoeren jconsole.
Selecteer uw AEM en Verbinden.
Van binnen Local
toepassing, dubbelklikken com.day.crx.quickstart.Main
; het overzicht wordt getoond als gebrek:
Nu kunt u andere opties selecteren.
Voor JDK 6-8 is de toolopdracht visualvm
beschikbaar. Nadat u een JDK hebt geïnstalleerd, kunt u het volgende doen:
Start de AEM.
Als u Java™ 5 gebruikt, kunt u de opdracht -Dcom.sun.management.jmxremote
argument naar de Java™-opdrachtregel waarmee uw JVM wordt gestart. JMX is standaard ingeschakeld met Java™ 6.
Voer een van beide uit:
jvisualvm
: in de map JDK 1.6 bin (geteste versie)visualvm
: kan worden gedownload van VisualVM (versie met bloeding)Van binnen Local
toepassing, dubbelklikken com.day.crx.quickstart.Main
. Het overzicht wordt getoond als gebrek:
Nu 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.
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. Verzamel deze metriek met regelmatige intervallen zodat u significante veranderingen gemakkelijk kunt zien.
De volgende informatie kan nuttig zijn:
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
Als u het totale aantal paginaberichten sinds de serverinstallatie wilt zien, gebruikt u een opslagruimtequery; als CRXDE - Tools - Query:
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.
Als u het aantal pagina's wilt zien dat momenteel op de server staat, gebruikt u een query in de repository; via CRXDE - Tools - Query:
Type XPath
Pad /
Query //element(*, cq:Page)
Om het totale aantal rollouts sinds installatie te bepalen, gebruik een bewaarplaatvraag; als 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.
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 wilt zien hoeveel DAM-middelen u momenteel beheert, gebruikt u een query voor de opslagplaats; via CRXDE - Tools - Query:
XPath
/
/jcr:root/content/dam//element(*, dam:Asset)
De totale grootte van de /var/dam
map bepalen:
Gebruik WebDAV om de opslagplaats toe te wijzen aan het lokale bestandssysteem.
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).
Om het aantal malplaatjes momenteel op de server te zien gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:
XPath
/
//element(*, cq:Template)
Als u het aantal componenten wilt zien dat momenteel op de server aanwezig is, gebruikt u een query voor de opslagplaats; via CRXDE - Tools - Query:
XPath
/
//element(*, cq:Component)
Om de verzoeken per uur te bepalen die u op het auteurssysteem bij piektijd hebt:
Om het totale aantal verzoeken sinds installatie te bepalen, gebruik de bevellijn:
cd <cq-installation-dir>/crx-quickstart/logs
grep -R "\->" request.log | wc -l
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.
Herhaal de bovenstaande procedure voor uw publicatieexemplaar.
Hieronder volgt een lijst met suggesties voor het controleren of er bepaalde prestatieproblemen optreden. De lijst is (helaas) niet volledig.
Zie ook de volgende artikelen voor meer informatie:
Als de CPU van uw systeem constant op 100% draait, zie het volgende:
De Knowledge Base:
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, kunt u dit probleem op verschillende manieren zien, waaronder prestatievermindering en foutmeldingen, zoals de subtekst:
java.lang.OutOfMemoryError
Controleer in deze gevallen:
De JVM-instellingen die worden gebruikt voor AEM starten
De Knowledge Base:
Als er onvoldoende schijfruimte beschikbaar is op uw systeem, of als u merkt dat de schijf wordt vastgezet, raadpleegt u:
Of u inzameling van zuivert informatie hebt onbruikbaar gemaakt, kan het in diverse plaatsen, met inbegrip van het volgende worden gevormd:
Of en hoe u Versie zuiveren hebt geconfigureerd
De Knowledge Base:
Als u ziet dat de prestaties van uw instantie achteruitgaan nadat u opnieuw hebt opgestart (soms een week of later), kunt u het volgende controleren:
De Knowledge Base:
De JVM (Java™ Virtual Machine) is verbeterd op het gebied van tuning (vooral sinds Java™ 7). Als zodanig is het vaak handig een redelijke vaste JVM-grootte op te geven en de standaardinstellingen te gebruiken.
Als de standaardinstellingen niet geschikt zijn, is het belangrijk een methode op te zetten om de prestaties van de GC te bewaken en te beoordelen. Doe dit voordat u probeert de JVM af te stemmen. Dit proces kan betrekking hebben op monitoringfactoren, waaronder heap-grootte, 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 het volgende:
[https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html)
U kunt zien hoeveel geheugen wordt gebruikt, welke GC-algoritmen worden gebruikt, hoe lang het duurt om te werken en welk effect dit proces heeft op de prestaties van uw toepassing. Zonder dit, is het stemmen enkel "willekeurig het draaien knopen".
Voor VM van Oracle is er ook informatie op:
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html