Övervaka och underhålla din Adobe Experience Manager-instans monitoring-and-maintaining-your-aem-instance
När AEM har distribuerats måste du övervaka och underhålla deras åtgärder, prestanda och integritet.
En viktig faktor här är att du måste känna till hur systemet ser ut och fungerar under normala förhållanden för att kunna identifiera potentiella problem. Detta görs bäst genom att man övervakar systemet och samlar in information över tid.
*ERROR* LowDiskSpaceBlocker
-meddelanden kan visas i loggfilen när det lediga utrymmet börjar ta slut.Säkerhetskopior backups
Det är god praxis att säkerhetskopiera
- Programvaruinstallationen - före/efter viktiga ändringar i konfigurationen
- Innehållet i databasen - regelbundet
Företaget har förmodligen en säkerhetskopieringsprincip som du följer, ytterligare överväganden om vad och när du ska säkerhetskopiera inkluderar följande:
- hur viktigt systemet och data är.
- hur ofta ändringar görs i antingen programvaran eller data.
- datavolym; kapacitet kan ibland vara ett problem, liksom tiden för att utföra säkerhetskopieringen.
- om säkerhetskopieringen kan göras medan användarna är online och, om möjligt, vilken prestandaeffekt har säkerhetskopieringen?
- användarens geografiska utbredning, det vill säga när är den bästa tidpunkten att säkerhetskopiera (för att minimera påverkan)?
- Din återställningspolicy. Finns det riktlinjer för var säkerhetskopierade data ska lagras (t.ex. utanför platsen och ett visst medium).
Ofta utförs en fullständig säkerhetskopiering med regelbundna intervall (t.ex. varje dag, varje vecka eller varje månad), med inkrementella säkerhetskopieringar mellan (t.ex. varje timme, varje dag eller varje vecka).
Säkerhetskopiera din programvaruinstallation backing-up-your-software-installation
Efter installationen, eller betydande ändringar i konfigurationen, skapar du en säkerhetskopia av din programvaruinstallation.
För att utföra den här uppgiften, säkerhetskopiera hela lagringsplatsen och sedan:
- Stoppa AEM.
- Säkerhetskopiera hela
<cq-installation-dir>
från filsystemet.
Säkerhetskopiera din lagringsplats backing-up-your-repository
The Säkerhetskopiering och återställning i CRX-dokumentationen täcker alla problem som rör säkerhetskopiering av CRX-databasen.
Mer information om hur du gör en "hot"-säkerhetskopiering online finns i Skapa en säkerhetskopiering online.
Rensning av version version-purging
The Rensa versioner är avsett för att rensa versioner av en nod eller en hierarki av noder i din databas. Dess främsta syfte är att hjälpa dig att minska storleken på databasen genom att ta bort tidigare versioner av dina noder.
I det här avsnittet behandlas underhållsåtgärder som rör versionsfunktionen i AEM. The Rensa version är avsett för att rensa versioner av en nod eller en hierarki av noder i din databas. Dess primära syfte är att hjälpa dig att minska storleken på din lagringsplats genom att ta bort gamla versioner av dina noder.
Överblick overview
The Rensa versioner finns som en underhållsåtgärd varje vecka. Innan du använder den för första gången måste den läggas till och sedan konfigureras. Därefter kan det köras på begäran eller varje vecka.
Rensa versioner av en webbplats purging-versions-of-a-web-site
Så här rensar du versioner av en webbplats:
-
Navigera till verktyg konsol, markera Åtgärd, Underhåll sedan Underhållsfönster varje vecka.
-
Välj + Lägg till i det övre verktygsfältet.
-
Välj Rensa version från listrutan i Lägg till ny aktivitet -dialogrutan. Sedan Spara.
-
The Rensa version aktiviteten läggs till. Använd kortåtgärder för att:
- Markera - visar ytterligare åtgärder i det övre verktygsfältet
- Kör - för att köra den konfigurerade rensningen omedelbart
- Konfigurera - för att konfigurera veckorensningsaktiviteten
-
Välj Konfigurera åtgärd för att öppna webbkonsolen för Rensa CQ WCM-version för dag, där du kan konfigurera:
-
Rensa banor
Ange startsökvägen för innehållet som ska rensas, till exempel/content/wknd
.note caution CAUTION Adobe rekommenderar att du definierar flera sökvägar för varje webbplats. Om du definierar en bana med för många underordnade objekt kan det ta lång tid att tömma den. -
Rensa versioner rekursivt
- Avmarkera alternativet om du bara vill rensa den nod som definieras av sökvägen.
- Välj det här alternativet om du vill rensa noden som definieras av sökvägen och dess underordnade noder.
-
Maximalt antal versioner
Ange det maximala antalet versioner (för varje nod) som du vill behålla. Lämna tomt om du inte vill använda den här inställningen. -
Minsta antal versioner
Ange det minsta antal versioner (för varje nod) som du vill behålla. Lämna tomt om du inte vill använda den här inställningen. -
Högsta versionsålder
Ange den maximala versionsåldern i dagar (för varje nod) som du vill behålla. Lämna tomt om du inte vill använda den här inställningen.
Sedan Spara.
-
-
Navigera/återgå till Underhållsfönster varje vecka fönster och markera Kör för att starta processen direkt.
- http://localhost:4502/etc/versioning/purge.html
Torr körning - Analyserar konsolen analyzing-the-console
Det klassiska användargränssnittet har en Torr körning från:
- http://localhost:4502/etc/versioning/purge.html
Processen visar alla noder som har bearbetats. Under processen kan en nod ha någon av följande statusar:
-
ignore (not versionnable)
: noden stöder inte versionshantering och ignoreras under processen. -
ignore (no version)
: noden har ingen version och ignoreras under processen. -
retained
: noden rensas inte. -
purged
: noden rensas.
Konsolen ger dessutom användbar information om versionerna:
-
V 1.0
: versionsnumret. -
V 1.0.1
*: Stjärnan anger att versionen är den aktuella (basversionen) och inte kan rensas. -
Thu Mar 15 2012 08:37:32 GMT+0100
: datum för versionen.
I nästa exempel:
- Versionerna Shirts rensas eftersom deras versionsålder är högre än två dagar.
- The Tonga Fashions! versionerna rensas eftersom deras antal versioner är större än 5.
Arbeta med granskningsposter och loggfiler working-with-audit-records-and-log-files
Granskningsposter och loggfiler för Adobe Experience Manager (AEM) finns på olika platser. Här följer en översikt över vad du kan hitta och var du kan hitta den.
Arbeta med loggar working-with-logs
AEM WCM registrerar detaljerade loggar. När du har packat upp och startat Quickstart hittar du loggar in:
-
<cq-installation-dir>/crx-quickstart/logs/
-
<cq-installation-dir>/crx-quickstart/repository/
Rotation av loggfil log-file-rotation
Rotation av loggfiler avser den process som begränsar filens tillväxt genom att skapa en fil regelbundet. I AEM anropas en loggfil error.log
roteras en gång om dagen enligt följande regler:
-
The
error.log
filen får ett nytt namn enligt mönstret{original_filename}.yyyy-MM-dd
. Den aktuella loggfilen får till exempel ett nytt namn den 11 juli 2010error.log-2010-07-10
, sedan en nyerror.log
skapas. -
Tidigare loggfiler tas inte bort, så det är ditt ansvar att rensa gamla loggfiler med jämna mellanrum för att begränsa diskanvändningen.
Hitta loggfilerna finding-the-log-files
Olika loggfiler finns på den filserver där du installerade AEM:
-
<cq-installation-dir>/crx-quickstart/logs
-
access.log
Alla åtkomstbegäranden till AEM WCM och databasen registreras här. -
audit.log
Modereringsåtgärder registreras här. -
error.log
Felmeddelanden (av varierande allvarlighetsgrad) registreras här. -
ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
Den här loggen används bara om Dynamic Media är aktiverat. Det innehåller statistik och analysinformation som används för att analysera beteendet i den interna ImageServer-processen. -
request.log
Varje åtkomstbegäran registreras här tillsammans med svaret. -
s7access-<yyyy>-<mm>-<dd>.log
Den här loggen används bara om Dynamic Media är aktiverat. s7access-loggen registrerar varje begäran som görs till Dynamic Media via/is/image
och/is/content
. -
stderr.log
Innehåller felmeddelanden, återigen av varierande allvarlighetsgrad, som genereras under start. Som standard är loggnivån inställd påWarning
(WARN
) -
stdout.log
Innehåller loggningsmeddelanden som anger händelser under start. -
upgrade.log
Tillhandahåller en logg över alla uppgraderingsåtgärder som körs fråncom.day.compat.codeupgrade
ochcom.adobe.cq.upgradesexecutor
paket.
-
-
<cq-installation-dir>/crx-quickstart/repository/segmentstore
journal.log
Information om revideringsjournaler.
Aktivera loggnivån för FELSÖKNING activating-the-debug-log-level
Standardloggnivån (Konfiguration av Apache Sling-loggning) är Information, så felsökningsmeddelanden loggas inte.
Om du vill aktivera felsökningsloggnivån för en loggare anger du egenskapen org.apache.sling.commons.log.level
för att felsöka i databasen. På /libs/sling/config/org.apache.sling.commons.log.LogManager
för att konfigurera global Apache Sling Logging.
En rad i felsökningsfilen börjar oftast med DEBUG och anger sedan loggnivån, installationsåtgärden och loggmeddelandet. Till exempel:
DEBUG 3 WebApp Panel: WebApp successfully deployed
Loggnivåerna är följande:
Skapa en anpassad loggfil create-a-custom-log-file
I vissa fall kanske du vill skapa en anpassad loggfil med en annan loggnivå. Gör följande i databasen:
-
Om den inte finns skapar du en konfigurationsmapp (
sling:Folder
) för ditt projekt/apps/<project-name>/config
. -
Under
/apps/<project-name>/config
, skapa en nod för den nya Konfiguration av loggningsloggare för Apache Sling:-
Namn:
org.apache.sling.commons.log.LogManager.factory.config-<identifier>
Där
<identifier>
ersätts med fritext som du (måste) ange för att identifiera instansen (du kan inte utelämna den här informationen).Exempel:
org.apache.sling.commons.log.LogManager.factory.config-MINE
-
Typ:
sling:OsgiConfig
note note NOTE Även om det inte är ett tekniskt krav, är det lämpligt att göra <identifier>
unikt. -
-
Ange följande egenskaper för den här noden:
-
Namn:
org.apache.sling.commons.log.file
Typ: String
Värde: ange loggfilen, till exempel
logs/myLogFile.log
-
Namn:
org.apache.sling.commons.log.names
Typ: String[] (String + Multi)
Värde: Ange de OSGi-tjänster som loggaren ska logga meddelanden för, till exempel allt av följande:
org.apache.sling
org.apache.felix
com.day
-
Namn:
org.apache.sling.commons.log.level
Typ: String
Värde: ange den loggnivå som krävs (
debug
,info
,warn
, ellererror
); till exempeldebug
-
Konfigurera de andra parametrarna efter behov:
-
Namn:
org.apache.sling.commons.log.pattern
Typ:
String
Värde: ange mönstret för loggmeddelandet efter behov. till exempel
{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
-
note note NOTE org.apache.sling.commons.log.pattern
stöder upp till sex argument.{0} Tidsstämpeln av typen java.util.Date
{1} loggmarkören {2} namnet på den aktuella tråden {3} namnet på loggen {4} loggnivån {5} loggmeddelandet Om logganropet innehåller en Throwable
läggs stackspårningen till i meddelandet.note caution CAUTION org.apache.sling.Commons.log.names måste ha ett värde. note note NOTE Loggskrivarsökvägarna är relativa till crx-quickstart
plats.Därför har en loggfil angetts som: logs/thelog.log
skriver till: <cq-installation-dir>/crx-quickstart/logs/thelog.log
.Och en loggfil har angetts som: ../logs/thelog.log
skriver till en katalog: <cq-installation-dir>/logs/
(d.v.s. bredvid<cq-installation-dir>/crx-quickstart/
) -
-
Det här steget är bara nödvändigt när ett nytt skrivprogram krävs (d.v.s. med en annan konfiguration än standardskrivaren).
note caution CAUTION En ny loggningsskrivarkonfiguration krävs bara när den befintliga standardinställningen inte är lämplig. Om inget explicit skrivprogram är konfigurerat genereras automatiskt ett implicit skrivprogram baserat på standardvärdet. Under
/apps/<project-name>/config
, skapa en nod för den nya Konfiguration av skrivprogram för Apache Sling Logging:-
Namn:
org.apache.sling.commons.log.LogManager.factory.writer-<identifier>
(skrivprogram)Precis som med Logger,
<identifier>
ersätts med fri text som du (måste) anger för att identifiera instansen (du kan inte utelämna den här informationen). Exempel:org.apache.sling.commons.log.LogManager.factory.writer-MINE
-
Typ:
sling:OsgiConfig
note note NOTE Även om det inte är ett tekniskt krav är det tillrådligt att <identifier>
unika.Ange följande egenskaper för den här noden:
-
Namn:
org.apache.sling.commons.log.file
Typ:
String
Värde: ange loggfilen så att den matchar den fil som anges i loggboken.
i detta exempel,
../logs/myLogFile.log
. -
Konfigurera de andra parametrarna efter behov:
-
Namn:
org.apache.sling.commons.log.file.number
Typ:
Long
Värde: ange antalet loggfiler som du vill behålla, till exempel
5
-
Namn:
org.apache.sling.commons.log.file.size
Typ:
String
Värde: ange som krävs för att styra filrotation efter storlek/datum, till exempel
'.'yyyy-MM-dd
-
note note NOTE org.apache.sling.commons.log.file.size
styr rotationen av loggfilen genom att ange antingen:- maximal filstorlek
- ett tids-/datumschema
för att ange när en ny fil skapas (och den befintliga filen får ett nytt namn enligt namnmönstret). - En storleksgräns kan anges med ett tal. Om ingen storleksindikator anges används den som antal byte, eller så kan du lägga till en av storleksindikatorerna -
KB
,MB
, ellerGB
(skiftläge ignoreras). - Ett tids-/datumschema kan anges som ett
java.util.SimpleDateFormat
mönster. Den definierar den tidsperiod efter vilken filen roteras. Dessutom läggs suffixet till i den roterade filen (för identifiering).
Standardvärdet är '.'yyyy-MM-dd (för daglig loggrotation). Till exempel vid midnatt den 20 januari 2010 (eller när det första loggmeddelandet efter detta datum inträffar för att vara exakt), … /logs/error.log har bytt namn till … /logs/error.log.2010-01-20. Loggning för 21 januari matas ut till (en ny och tom) … /logs/error.log tills den rullas över vid nästa dagbyte. table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 '.'yyyy-MM
Rotation i början av varje månad '.'yyyy-ww
Rotation på den första dagen i varje vecka (beror på språkområdet). '.'yyyy-MM-dd
Rotation vid midnatt varje dag. '.'yyyy-MM-dd-a
Rotation vid midnatt och middag varje dag. '.'yyyy-MM-dd-HH
Rotation överst varje timme. '.'yyyy-MM-dd-HH-mm
Rotation i början av varje minut. Obs! När du anger tid/datum: -
Du bör"escape"-text inom ett par enkla citattecken (' ');
Undviker att vissa tecken tolkas som mönsterbokstäver.
-
Använd bara tecken som är tillåtna för ett giltigt filnamn var som helst i alternativet.
-
-
Läs den nya loggfilen med det verktyg du valt.
Loggfilen som skapas i det här exemplet är
../crx-quickstart/logs/myLogFile.log
.
Felix Console innehåller även information om stöd för loggning på ../system/console/slinglog
; till exempel https://localhost:4502/system/console/slinglog
.
Söka efter granskningsposter finding-the-audit-records
Granskningsregister förs för att visa vem som gjorde vad och när. Olika granskningsposter genereras för både AEM WCM- och OSGi-händelser.
AEM WCM-granskningsposter visas vid sidredigering aem-wcm-audit-records-shown-when-page-authoring
-
Öppna en sida.
-
I sidosparken kan du välja fliken med låsikonen och sedan dubbelklicka Granskningslogg…
-
Ett nytt fönster öppnas med en lista över granskningsposter för den aktuella sidan.
-
Klicka OK när du vill stänga fönstret.
AEM WCM-granskningsposter i databasen aem-wcm-auditing-records-within-the-repository
I /var/audit
mapp, granskningsposter sparas enligt resursen. Du kan gå nedåt tills du ser enskilda poster och den information de innehåller.
Dessa poster innehåller samma information som den som visas när du redigerar en sida.
OSGi Granskningsposter från webbkonsolen osgi-audit-records-from-the-web-console
OSGi-händelser genererar också granskningsposter som kan ses av Konfigurationsstatus tab > Loggfiler i AEM webbkonsol:
Övervaka replikeringsagenter monitoring-your-replication-agents
Du kan övervaka dina replikeringsköer för att identifiera när en kö är avstängd eller blockerad - vilket i sin tur kan tyda på ett problem med en publiceringsinstans eller ett externt system:
-
Är alla obligatoriska köer aktiverade?
-
Krävs det fortfarande inaktiverade köer?
-
alla
enabled
köer ska ha statusenidle
elleractive
, vilket anger normal drift; inga köer ska varablocked
, som ofta är ett tecken på problem på mottagarsidan. -
om storleken på kön ökar över tid kan det indikera en blockerad kö.
Så här övervakar du en replikeringsagent:
-
Öppna verktyg AEM.
-
Klicka Replikering.
-
Dubbelklicka på länken till agenter för lämplig miljö (antingen vänster eller höger ruta), till exempel Agenter på författare.
I det resulterande fönstret visas en översikt över alla dina replikeringsagenter för redigeringsmiljön, inklusive mål och status.
-
Klicka på lämpligt agentnamn (som är en länk) för att visa detaljerad information om agenten:
Här kan du:
- Se om agenten är aktiverad.
- Se målet för alla replikeringar.
- Kontrollera om replikeringskön är aktiv (aktiverad).
- Se om det finns några objekt i kön.
- Uppdatera eller Rensa för att uppdatera visningen av köposter. Om du gör det blir det lättare att se objekt som kommer in i och lämnar kön.
- Visa logg för att få åtkomst till loggen över eventuella åtgärder från replikeringsagenten.
- Testanslutning till målinstansen.
- Tvinga återförsök på alla köobjekt, om det behövs.
note caution CAUTION Använd inte länken Testa anslutning för den omvända replikeringsutkorgen på en publiceringsinstans. Om ett replikeringstest utförs för en Utkorgskö bearbetas alla objekt som är äldre än testreplikeringen om med varje omvänd replikering. Om sådana objekt finns i en kö kan de hittas med följande XPath JCR-fråga och bör tas bort. /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']
Du kan också utveckla en lösning för att identifiera alla replikeringsagenter (som finns under /etc/replication/author
eller /etc/replication/publish
) och sedan kontrollera status för agenten ( enabled
, disabled
) och den underliggande kön ( active
, idle
, blocked
).
Övervakningsprestanda monitoring-performance
Prestandaoptimering är en interaktiv process som får fokus under utvecklingen. Efter distributionen granskas den efter specifika intervall eller händelser.
Metoder som används för att samla in information för optimering kan också användas för kontinuerlig övervakning.
Nedan visas vanliga prestandaproblem som uppstår, tillsammans med förslag om hur du kan hitta och motverka dem.
Prestandaproblem kan bero på olika orsaker som inte har något med din webbplats att göra, bland annat tillfälliga avbrott i anslutningshastigheten, processorbelastningen och många andra.
Det kan även påverka alla besökare eller bara en del av dem.
All denna information måste hämtas, sorteras och analyseras innan du kan optimera den allmänna prestandan eller lösa specifika problem.
-
Innan du upplever ett prestandaproblem:
- Samla in så mycket information som möjligt för att bygga upp goda kunskaper om systemet under normala förhållanden
-
När du får ett prestandaproblem:
-
försök att replikera den med en (eller helst med flera) standardwebbläsare, på en annan klient som du vet har bra allmänna prestanda och/eller på själva servern (om möjligt)
-
kontrollera om något (relaterat till systemet) har ändrats inom en lämplig tidsperiod och om någon av dessa ändringar kan ha påverkat prestandan
-
ställa frågor som:
- inträffar problemet endast vid vissa tidpunkter?
- uppstår problemet endast på vissa sidor?
- Påverkas andra förfrågningar?
-
Samla in så mycket information som möjligt för att jämföra med dina kunskaper om systemet under normala förhållanden:
-
Verktyg för övervakning och analys av prestanda tools-for-monitoring-and-analyzing-performance
Nedan ges en kort översikt över några av de verktyg som är tillgängliga för övervakning och analys av prestanda.
Vissa av dessa verktyg är beroende av operativsystemet.
Tolka request.log interpreting-the-request-log
Den här filen registrerar grundläggande information om varje begäran som görs till AEM. Därigenom kan värdefulla slutsatser dras.
The request.log
erbjuder ett inbyggt sätt att se hur lång tid det tar att begära. I utvecklingssyfte är det användbart att tail -f
den request.log
och hålla utkik efter långsamma svarstider. Analysera en större request.log
, Adobe rekommenderar användning av rlog.jar
med vilket du kan sortera och filtrera svarstider.
Adobe rekommenderar att du isolerar de långsamma sidorna från request.log
och sedan justera dem individuellt för att få bättre prestanda. Inkludera prestandamått per komponent eller använda ett prestandaprofileringsverktyg som [yourkit](https://www.yourkit.com/)
.
Övervaka trafik på din webbplats monitoring-traffic-on-your-website
Begärandeloggen registrerar varje begäran som gjorts, tillsammans med svaret:
09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms
Genom att summera alla GETTER inom specifika perioder (t.ex. under olika 24-timmarsperioder) kan du göra utdrag om den genomsnittliga trafiken på webbplatsen.
Övervaka svarstider med request.log monitoring-response-times-with-the-request-log
En bra utgångspunkt för prestandaanalys är begärandeloggen:
<cq-installation-dir>/crx-quickstart/logs/request.log
Loggen ser ut så här (raderna förkortas för enkelhetens skull):
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
Den här loggen har en rad per begäran eller svar:
-
Det datum då varje begäran eller svar gjordes.
-
Numret på begäran, inom hakparentes. Numret matchar för begäran och svaret.
-
En pil som anger om det är en begäran (pil som pekar till höger) eller ett svar (pilen till vänster).
-
För begäranden innehåller raden:
- metoden (vanligtvis GET, HEAD eller POST)
- begärd sida
- protokollet
-
För svar innehåller raden:
- statuskoden (200 betyder "lyckades", 404 betyder "sidan hittades inte"
- MIME-typen
- svarstid
Med små skript kan du extrahera den information som behövs från loggfilen och sammanställa den statistik som du vill ha. Med hjälp av den här statistiken kan du se vilka sidor eller typer av sidor som är långsamma och om de totala prestandan är tillfredsställande.
Övervaka söksvarstider med request.log monitoring-search-response-times-with-the-request-log
Sökbegäranden registreras också i loggfilen:
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
Så som ovan kan du använda skript för att extrahera relevant information och bygga upp statistik.
När du har bestämt svarstiden kan du analysera varför begäran tar den tid som behövs och vad som kan göras för att förbättra svaret.
Övervaka antalet samtidiga användare och deras inverkan monitoring-the-number-and-impact-of-concurrent-users
Igen request.log
kan användas för att övervaka samtidighet och systemets reaktion på detta.
Testerna måste göras för att avgöra hur många samtidiga användare som systemet kan hantera innan en negativ påverkan ses. Återigen kan du använda skript för att extrahera resultat från loggfilen:
- övervaka hur många förfrågningar som görs inom en viss tidsperiod, t.ex. en minut.
- testa effekterna av ett visst antal användare som alla gör samma förfrågningar samtidigt (så nära som möjligt). 30 användare klickar till exempel Spara samtidigt.
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
Använda rlog.jar för att hitta begäranden med lång varaktighet using-rlog-jar-to-find-requests-with-long-duration-times
AEM innehåller olika hjälpverktyg i följande:<cq-installation-dir>/crx-quickstart/opt/helpers
Ett av dessa verktyg, rlog.jar
, kan användas för att snabbt sortera request.log
så att förfrågningar visas med varaktighet, från längst till kortast.
Följande kommando visar möjliga argument:
$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.
Du kan till exempel köra den och ange request.log
som en parameter och visa de tio första begäranden som har längst varaktighet:
$ 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
Sammanfoga individen request.log
filer om du måste utföra den här åtgärden på ett stort dataprov.
Apache Bench apache-bench
För att minimera specialfall (till exempel skräpinsamling) rekommenderar vi att du använder ett verktyg som apachebench
(till exempel ab för ytterligare dokumentation) för att identifiera minnesläckor och selektivt analysera svarstiden.
Apache Bench kan användas på följande sätt:
$ 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)
Siffrorna ovan hämtas från en vanlig bärbar dator från MAcBook Pro (mitten av 2010) som har åtkomst till Geometrixx företagssida, vilket ingår i en AEM. Sidan är enkel, men inte optimerad för prestanda.
The apachebench
visar också tiden per begäran som medelvärde, för alla samtidiga begäranden, se Time per request: 54.595 [ms]
(medelvärde, för alla samtidiga begäranden). Du kan ändra värdet på parametern concurrency -c
(antal flera begäranden om att utföra samtidigt) för att se eventuella effekter.
Begäranräknare request-counters
Information om begärandetrafik (antal förfrågningar under en viss tidsperiod) ger dig en indikation på belastningen på din instans. Den här informationen kan extraheras från request.logmen med räknare kan du automatisera datainsamlingen så att du kan se:
- betydande skillnader i aktivitet (det vill säga skillnader mellan"många förfrågningar" och"låg aktivitet")
- när en instans inte används
- alla omstarter (räknarna återställs till 0)
Om du vill automatisera informationsinsamlingen kan du även installera ett RequestFilter för att öka antalet räknare vid varje begäran. Flera räknare kan användas för olika tidsperioder.
De insamlade uppgifterna kan användas för att ange
- betydande förändringar i verksamheten
- en redundant instans
- alla omstarter (räknaren återställs till 0)
HTML kommentarer html-comments
Vi rekommenderar att alla projekt innehåller html comments
för serverprestanda. Många bra exempel finns. Välj en sida, öppna sidkällan för visning och rulla längst ned. Kod som följande kan ses:
</body>
</html>
<!--
Page took 58 milliseconds to be rendered by server
-->
Övervaka prestanda med JConsole monitoring-performance-using-jconsole
Verktygskommandot jconsole
är tillgängligt med JDK.
-
Starta AEM.
-
Kör
jconsole.
-
Markera AEM och Anslut.
-
Från
Local
program, dubbelklickacom.day.crx.quickstart.Main
; Översikten visas som standard:Nu kan du välja andra alternativ.
Övervaka prestanda med hjälp av (J)VisualVM monitoring-performance-using-j-visualvm
För JDK 6-8 är verktygskommandot visualvm
tillgängligt. När du har installerat en JDK kan du göra följande:
-
Starta AEM.
note note NOTE Om du använder Java™ 5 kan du lägga till -Dcom.sun.management.jmxremote
argument till den Java™-kommandorad som startar din JVM. JMX är aktiverat som standard med Java™ 6. -
Kör antingen:
jvisualvm
: i mappen JDK 1.6 bin (testversion)visualvm
: kan hämtas från VisualVM (avskalningsversion)
-
Från
Local
program, dubbelklickacom.day.crx.quickstart.Main
. Översikten visas som standard:Nu kan du välja andra alternativ, bland annat Bildskärm:
Du kan använda det här verktyget för att generera tråddumpar och minnesdumpar. Den här informationen begärs ofta av den tekniska supportteamet.
Informationsinsamling information-collection
Om du vet så mycket som möjligt om din installation kan det hjälpa dig att spåra vad som kan ha orsakat prestandaförändringar och om dessa ändringar är motiverade. Samla in dessa mätvärden med jämna mellanrum så att du enkelt kan se betydande ändringar.
Följande information kan vara användbar:
- Hur många författare arbetar med systemet?
- Vilket är det genomsnittliga antalet sidaktiveringar per dag?
- Hur många sidor har du i det här systemet?
- Om du använder MSM, vilket är det genomsnittliga antalet utrullningar per månad?
- Vilket är det genomsnittliga antalet Live-kopior per månad?
- Om du använder AEM Assets, hur många mediefiler har du för närvarande i Assets?
- Vilken är den genomsnittliga storleken på resurserna?
- Hur många mallar används för närvarande?
- Hur många komponenter används för närvarande?
- Hur många förfrågningar per timme har du på författarsystemet vid maximal tid?
- Hur många begäranden per timme har du i publiceringssystemet vid maximal tid?
Hur många författare arbetar med systemet? how-many-authors-are-working-with-the-system
Använd kommandoraden för att se hur många författare som har använt systemet sedan installationen:
cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l
Så här ser du hur många författare som arbetar ett visst datum:
grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l
Vilket är det genomsnittliga antalet sidaktiveringar per dag? what-is-the-average-number-of-page-activations-per-day
Om du vill se det totala antalet sidaktiveringar sedan serverinstallationen använder du en databasfråga. Med CRXDE - Verktyg - Fråga:
-
Typ
XPath
-
Bana
/
-
Fråga
//element(*, cq:AuditEvent)[@cq:type='Activate']
Beräkna sedan medelvärdet genom att beräkna antalet dagar som har gått sedan installationen.
Hur många sidor har du i det här systemet? how-many-pages-do-you-currently-maintain-on-this-system
Om du vill se antalet sidor som finns på servern använder du en databasfråga, via CRXDE - Verktyg - Fråga:
-
Typ
XPath
-
Bana
/
-
Fråga
//element(*, cq:Page)
Om du använder MSM, vilket är det genomsnittliga antalet utrullningar per månad? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month
Använd en databasfråga för att fastställa det totala antalet rollouts sedan installationen. Med CRXDE - Verktyg - Fråga:
-
Typ
XPath
-
Bana
/
-
Fråga
//element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
Beräkna medelvärdet genom att beräkna antalet månader som har gått sedan installationen.
Vilket är det genomsnittliga antalet Live-kopior per månad? what-is-the-average-number-of-live-copies-per-month
Om du vill fastställa det totala antalet live-kopior som har gjorts sedan installationen använder du en databasfråga, via CRXDE - Verktyg - Fråga:
-
Typ
XPath
-
Bana
/
-
Fråga
//element(*, cq:LiveSyncConfig)
Använd återigen antalet månader som har gått sedan installationen för att beräkna genomsnittet.
Om du använder AEM Assets, hur många mediefiler har du för närvarande i Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets
Använd en databasfråga, via CRXDE - Verktyg - Fråga, om du vill se hur många DAM-resurser du för närvarande har:
- Typ
XPath
- Bana
/
- Fråga
/jcr:root/content/dam//element(*, dam:Asset)
Vilken är den genomsnittliga storleken på resurserna? what-is-the-average-size-of-the-assets
Så här fastställer du mappens /var/dam
totala storlek:
-
Använd WebDAV för att mappa databasen till det lokala filsystemet.
-
Använd kommandoraden:
code language-shell cd /Volumes/localhost/var du -sh dam/
För att få medelstorleken dividerar du den globala storleken med det totala antalet resurser i
/var/dam
(se ovan).
Hur många mallar används för närvarande? how-many-templates-are-currently-used
Om du vill visa antalet mallar som finns på servern använder du en databasfråga, via CRXDE - Verktyg - Fråga:
- Typ
XPath
- Bana
/
- Fråga
//element(*, cq:Template)
Hur många komponenter används för närvarande? how-many-components-are-currently-used
Om du vill se antalet komponenter som finns på servern använder du en databasfråga, via CRXDE - Verktyg - Fråga:
- Typ
XPath
- Bana
/
- Fråga
//element(*, cq:Component)
Hur många förfrågningar per timme har du på författarsystemet vid maximal tid? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time
Så här avgör du begäranden per timme som du har på författarsystemet vid maximal tid:
-
Använd kommandoraden för att bestämma det totala antalet begäranden sedan installationen:
code language-shell cd <cq-installation-dir>/crx-quickstart/logs grep -R "\->" request.log | wc -l
-
Så här bestämmer du start- och slutdatum:
code language-shell vim request.log G / 1G: for the last/first lines
Använd dessa värden för att beräkna antalet timmar som har gått sedan installationen, och sedan det genomsnittliga antalet begäranden per timme.
Hur många begäranden per timme har du i publiceringssystemet vid maximal tid? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time
Upprepa proceduren ovan på din publiceringsinstans.
Analyserar specifika scenarier analyzing-specific-scenarios
Här följer en lista med förslag på vad du ska kontrollera om du får vissa prestandaproblem. Listan är tyvärr inte helt heltäckande.
CPU vid 100 % cpu-at
Om datorns CPU hela tiden körs med 100 %, se följande:
-
Kunskapsbasen:
Slut på minne out-of-memory
Även om sådana fel bör identifieras under utveckling och testning kan vissa scenarier gå igenom.
Om det inte finns tillräckligt med minne i systemet kan det här problemet visas på olika sätt, bland annat prestandaförsämringar och felmeddelanden, bland annat undertexten:
java.lang.OutOfMemoryError
Kontrollera i så fall:
-
De JVM-inställningar som används för AEM
-
Kunskapsbasen:
Skiva-I/O disk-i-o
Om det inte finns tillräckligt med diskutrymme på datorn eller om det uppstår problem med hårddisken kan du läsa mer i:
-
Oavsett om du har inaktiverat en samling felsökningsinformation kan den konfigureras på olika platser, bland annat följande:
-
Om och hur du har konfigurerat versionsrensning
-
Kunskapsbasen:
Regelbunden prestandaförsämring regular-performance-degradation
Om du ser att instansens prestanda försämras efter varje omstart (ibland en vecka eller senare) kan du kontrollera följande:
-
Kunskapsbasen:
JVM-justering jvm-tuning
Java™ Virtual Machine (JVM) har förbättrats när det gäller justering (särskilt sedan Java™ 7). Därför är det ofta lämpligt att ange en rimlig fast JVM-storlek och att använda standardvärdena.
Om standardinställningarna inte är lämpliga är det viktigt att upprätta en metod för att övervaka och utvärdera GC-prestanda. Gör det innan du försöker justera JVM. Den här processen kan omfatta övervakningsfaktorer, inklusive heapstorlek, algoritm och andra aspekter.
Några vanliga alternativ är:
-
VerboseGC:
code language-none -verbose:gc \ -Xloggc:$LOGS/verbosegc.log \ -XX:+PrintGCDetails \ -XX:+PrintGCDateStamps
Den resulterande loggen kan importeras av en GC-visualiserare som:
[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)
Eller JConsole:
-
De här inställningarna gäller för en "bred" JMX-anslutning:
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
-
Anslut sedan till JVM med JConsole. Se följande:
[https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html)
Du kan se hur mycket minne som används, vilka GC-algoritmer som används, hur lång tid det tar att köra dem och vilken effekt den här processen har på programmets prestanda. Utan den är finjustering bara "slumpmässigt virvlande knoppar".