Exempel på request.log-analys | AEM

request.log från Adobe Experience Manager (AEM) är en omfattande informationskälla, inklusive svarstider, som är viktig för att analysera prestandaproblem. I den här artikeln finns flera exempel som illustrerar detta.

Beskrivning description

Miljö

Experience Manager 6.5

Problem/symtom

Adobe Experience Manager (AEM) request.log innehåller olika användbar information, till exempel svarstid, för att analysera prestandaproblem. Här är en lista med exempel på analyser som använder Linux-kommandon (inklusive några externa kommandon som ruby [ 1] och datamash [ 2] ).

Installationsguider

[ 1] https://www.ruby-lang.org/en/documentation/installation/

[ 2] https://www.gnu.org/software/datamash/download/

Upplösning resolution

Innehållsförteckning

A. Introduktion

B. Förberedelsesteg

C. Exempel på analys

D. Slutsats

A. Introduktion

Formatet på request.log:

AEM 6.5 genererar request.log i följande format som standard. På grund av en systembegränsning visas kommandoraden i den här artikeln som bilder i stället för som vanlig text.

Exempel på request.log:

I den här artikeln kallas en rad med "->" för en begärandepost. En rad med < - är en svarspost.

Begär post:

När en begäran tas emot av AEM loggas en begärandepost. Den innehåller datum och tid för mottagande, begärande-ID, begärandemetod och URL.

Svarspost:

När AEM svarar på en begäran loggas en svarspost. Den innehåller datum och tid för svar, begärande-ID, statuskod, innehållstyp och svarstid (i millisekunder).

Sök efter motsvarande handbok på Tolkar request.log.

B. Förberedelsesteg

Steg 1. Datarensning

Innan du börjar analysera request.log är det viktigt att standardisera loggposterna.

Det första sed-kommandot tar bort ett extra utrymme i Content-Type för svarsposter för att förhindra felfältseparation med tomt utrymme. Kommandot ruby (se [ 1] ovan för att installera Ruby) konverterar datumformatet till ISO 8601. Kommandot ruby separerar även datum och tid med tomt utrymme i stället för ett kolon.

Steg 2. Starttid

Startar om AEM och en installation av Service Pack återställer begärande-ID:t för request.log. Begärandeposterna med begäran ID = 0 indikerar att det kan finnas sådana typer av åtgärder.

I exemplet ovan återställdes begäran-ID:n till 0 vid 13:08:49 och 13:26:13.

Steg 3. Antal åtkomster per timme

Räkna antalet åtkomster per timme och tidsintervallet för request.log.

Steg 4. Maximal samtidig bearbetning:

Antalet samtidiga bearbetningar gör det lättare att gissa serverbelastningen på AEM.

Som standard är det maximala antalet samtidiga anslutningar för Jetty i AEM inställt på 200. Det är en fördröjning när socketen har släppts efter att svaret har slutförts. När antalet samtidiga behandlingar överstiger cirka 170 kan de inte godkänna nya begäranden.

Steg 5. Dela en loggfil

Begärande-ID request.log återställs när AEM startas om eller när ett Service Pack installeras. På grund av det här beteendet kan analysen vara felaktig när en request.log innehåller sådana åtgärder. Om du vill utföra en korrekt analys och minska filstorleken som hanteras samtidigt delar du request.log med hjälp av begärandeposter med begäran ID = 0.

Steg 6. Sammanfoga begärandeposter och svarsposter

Genom att sammanfoga begäran- och svarsposter med begäran-ID blir det enklare att identifiera när prestandaproblem har startats. Den här sammanfogade loggfilen kommer att användas i de senare exemplen.

Det sista sed-kommandot lägger till ett dummy-svar i begärandeposter som inte har någon motsvarande svarspost. Det kan också finnas svarsposter utan begärandeposter. Men de är okunniga eftersom de vanligtvis inte är till för utredning.

Den sammanfogade loggfilen ska se ut så här:

C. Exempel på analys

Exempel 1. De tyngsta åtkomsten

Sortera den sammanfogade loggfilen efter svarstid i fallande ordning, inklusive åtkomst utan svar.

Exempel 2. Kommer åt saknat svar

Extrahera-åtkomster saknar motsvarande svarsposter med hjälp av dummy-svarstiden.

Om tidpunkten för mottagande av åtkomst utan svar är korrelerad med en ökning av serverbelastningen, kan dessa åtkomster ha utlöst prestandaproblem.

Exempel 3. Långsam åtkomst

Extrahera åtkomster som tog mer än 10 sekunder.

När antalet träffar är för högt ersätter du [ 0-9] {5} med [ 0-9] {6} i kommandot grep för att begränsa åtkomsten till aktiviteter som tog mer än 100 sekunder.

Exempel 4. Tidsseriedata för svarstid

Det kan vara bra att extrahera enbart tidsstämpeln och svarstiden från data för att skapa diagram.

Om du utelämnar åtkomst som svarat omedelbart blir informationen mer effektiv. Följande exempel extraherar åtkomst som tog mer än en sekund.

Exempel 5. Minsta, medelvärde (medelvärde), median, maximal svarstid

I ovanstående exempel används datamash-kommandot (https://www.gnu.org/software/datamash/) för statistisk bearbetning. Om loggen innehåller åtkomst utan respons kommer det osäkra värdet att påverka resultatet.

Exempel 6. Antal åtkomster per period

Räkna antalet åtkomster per tio minuter. Resultatet hjälper till att avgöra om stor trafik orsakade ett prestandaproblem.

I följande exempel begränsas data ned till enbart POSTER. Ett typiskt användningsexempel är att avgöra om det finns en koncentration av redigering eller replikering av innehåll till Publish-nivån.

Exempel 7. Antal svarsstatusar per period

Skapa en tabell med antalet svar per tio minuter med kommandot datamash.

Exempel 8. De vanligaste URL:erna

Skriv ut de tre översta URL:erna som du oftast fick åtkomst till under tio minuter.

Exempel 9. access.log-poster för en request.log-post

Sök efter poster i access.log som motsvarar ett visst begärande-ID.

Om flera åtkomster av samma URL samtidigt inträffar, visar resultatet flera access.log-poster för ett enda begäran-ID.

D. Slutsats

Exemplen i den här artikeln bör hjälpa dig att analysera dina prestandaproblem.

Exemplen i listan har testats i CentOS 7.5 och Ubuntu 22.04LTS, men de kanske inte fungerar som förväntat beroende på din miljö, till exempel olika versioner eller variationer av kommandona. Justera dem efter de kommandon som är installerade i din miljö.