Voorbeelden van request.log-analyse | AEM
The request.log of Adobe Experience Manager (AEM) is een rijke bron van informatie, inclusief responstijden, die cruciaal is voor het analyseren van prestatieproblemen. Dit artikel bevat verschillende voorbeelden ter illustratie van dit punt.
Beschrijving description
Milieu
Experience Manager 6.5
Uitgave/Symptomen
De Adobe Experience Manager (AEM) request.log
bevat verschillende nuttige informatie, zoals de responstijd, voor het analyseren van de prestatieproblemen. Hier is een lijst van analysevoorbeelden gebruikend de bevelen van Linux (met inbegrip van sommige externe bevelen zoals ruby [
1 ]
en datamash [
2 ]
).
gidsen van de Installatie
[
1 ]
https://www.ruby-lang.org/en/documentation/installation/
[
2 ]
https://www.gnu.org/software/datamash/download/
Resolutie resolution
Inhoudsopgave
A. Inleiding
- Indeling van
request.log
B. Voorbereidingsstappen
- Gegevensreiniging
- Begintijd
- Aantal toegangen per uur
- Maximale gelijktijdige verwerking
- Een logbestand splitsen
- Aanvraagrecords samenvoegen en reactierecords
C. Voorbeelden van analyse
- De zwaarste toegang
- Accepteert ontbrekende reactie
- Langzame toegang
- Reeks gegevens van de responstijd
- Minimum, gemiddelde (gemiddelde), mediaan, maximale responstijd
- Aantal toegangen per periode
- Aantal responsstatussen per periode
- Meest voorkomende URL's
access.log
records voor eenrequest.log
record
D. Conclusie
A. Inleiding
het formaat van request.log :
AEM 6.5 genereert standaard request.log
in de volgende indeling. Vanwege een systeembeperking worden de opdrachtregels in dit artikel weergegeven als afbeeldingen in plaats van als onbewerkte tekst.
Voorbeeld van request.log
:
In dit artikel, wordt een lijn met "- >
" bedoeld als "verzoekverslag." Een lijn met "<
-"is een "reactieverslag."
Verslag van het Verzoek :
Wanneer een verzoek door AEM wordt ontvangen, wordt een verzoekverslag geregistreerd. Het bevat de datum en tijd van ontvangst, verzoekidentiteitskaart, de verzoekmethode, en URL.
Verslag van de Reactie :
Wanneer AEM op een verzoek reageert, wordt een reactieverslag geregistreerd. Deze bevat de datum en tijd van de reactie, de aanvraag-id, de statuscode, Content-Type en de reactietijd (in milliseconden).
Vind het overeenkomstige handboek op Interpreting the request.log.
B. Voorbereidingsstappen
Stap 1. Gegevens opschonen
Voordat u naar de analyse van request.log
gaat, is het belangrijk dat u de logrecords gestandaardiseert.
Met de eerste opdracht sed
verwijdert u een extra ruimte in Inhoudstype van reactierecords om te voorkomen dat er een onjuiste veldscheiding met witruimte ontstaat. Met de ruby-opdracht (zie [
1 ]
hierboven voor de installatie van Ruby) wordt de datumnotatie omgezet in ISO 8601. Met de opdracht Ruby worden datum en tijd ook gescheiden door witruimte in plaats van een dubbele punt.
Stap 2. Herstelde tijd
Door AEM opnieuw te starten en een service pack-installatie wordt de aanvraag-id van request.log
opnieuw ingesteld. De request-records met request ID = 0
geven aan dat dit soort bewerkingen mogelijk zijn.
In het bovengenoemde voorbeeld, verzoek IDs werd teruggesteld aan 0 bij 13 :08: 49 en 13 :26: 13.
Stap 3. Aantal toegangen per uur
Telt het aantal toegangen per uur en het tijdbereik van request.log
.
Stap 4. Maximale gelijktijdige verwerking
Het aantal gelijktijdige verwerkingen helpt de serverbelasting van AEM te raden.
Standaard is het maximumaantal gelijktijdige verbindingen voor Jetty in AEM ingesteld op 200. Er is een vertraging bij het vrijgeven van de socket nadat de reactie is voltooid. Als het aantal gelijktijdige verwerkingen groter is dan ongeveer 170, kan het geen nieuwe aanvragen accepteren.
Stap 5. Een logbestand splitsen
De aanvraag-id van request.log
wordt opnieuw ingesteld wanneer AEM opnieuw start of wanneer een Service Pack is geïnstalleerd. Door dit gedrag kan de analyse onjuist zijn wanneer een request.log
dergelijke bewerkingen bevat. Als u een nauwkeurige analyse wilt uitvoeren en de bestandsgrootte die tegelijkertijd wordt afgehandeld wilt beperken, splitst u de request.log
met behulp van aanvraagrecords met de aanvraag ID = 0
.
Stap 6. De verzoekverslagen van de fusie en reactieverslagen
Het samenvoegen van verzoek en reactieverslagen door verzoekidentiteitskaart maakt het gemakkelijker om te merken wanneer de prestatieskwesties begonnen. Dit samengevoegde logbestand wordt in de latere voorbeelden gebruikt.
Met de laatste opdracht sed
voegt u een dummyreactie toe op aanvraagrecords die geen corresponderende reactierecord hebben. Er kunnen ook reactieverslagen zonder verzoekverslagen zijn. Maar ze zijn onwetend, omdat ze doorgaans geen kwestie van onderzoek zijn.
Het samengevoegde logbestand moet er als volgt uitzien:
C. Voorbeelden van analyses
Voorbeeld 1. De zwaarste toegangen
Sorteer het samengevoegde logbestand op reactietijd in aflopende volgorde, inclusief toegangspunten zonder reactie.
Voorbeeld 2. Benodigt ontbrekende reactie
Bij het extraheren wordt de corresponderende reactiegegevens niet weergegeven bij de dummy reactietijd.
Als de timing van het ontvangen van toegangen zonder reactie met een toename van serverlading gecorreleerd is, kunnen deze toegangen prestatieskwesties teweegbrengen.
Voorbeeld 3. Langzame toegang
Extraheer toegang die meer dan 10 seconden duurde.
Wanneer het aantal hits te hoog is, vervangt u [ 0-9] {5}
door [ 0-9] {6}
in de opdracht grep
om het aantal hits te beperken tot toegangspunten die meer dan 100 seconden in beslag namen.
Voorbeeld 4. De tijdreeksgegevens van reactietijd
Het is handig alleen de tijdstempel en de reactietijd uit de gegevens te halen om grafieken te maken.
Het weglaten van toegangen die onmiddellijk antwoordden maakt de gegevens efficiënter. In het volgende voorbeeld wordt toegang die meer dan een seconde heeft geduurd, geëxtraheerd.
Voorbeeld 5. Minimum, gemiddelde (gemiddelde), mediaan, maximale responstijd
In het bovenstaande voorbeeld wordt de opdracht datamash (https://www.gnu.org/software/datamash/) gebruikt voor statistische verwerking. Als het logboek toegang zonder reactie bevat, zal de dummywaarde het resultaat beïnvloeden.
Voorbeeld 6. Aantal toegangen per een periode
Telt het aantal toegangen per tien minuten. Het resultaat helpt om te bepalen als het grote verkeer een prestatieskwestie veroorzaakte.
In het volgende voorbeeld worden de gegevens beperkt tot alleen POST-aanvragen. Doorgaans wordt gebruikt om te bepalen of er een concentratie is van het ontwerpen of repliceren van inhoud naar de Publish-laag.
Voorbeeld 7. Aantal responsstatussen per periode
Maak een tabel met het aantal responsstatus per tien minuten met de opdracht datamash.
Voorbeeld 8. Meest frequente URLs
Druk de bovenste drie URL's af die het meest per tien minuten zijn geopend.
Voorbeeld 9. access.log verslagen voor een request.log verslag
Zoek access.log
naar verslagen die aan een bepaalde verzoekidentiteitskaart beantwoorden
Als er meerdere benaderingen van dezelfde URL tegelijk zijn geweest, bevat het resultaat meerdere access.log
records voor één aanvraag-id.
D. Conclusie
Aan de hand van de voorbeelden in dit artikel kunt u uw prestatieproblemen analyseren.
De vermelde voorbeelden zijn getest op CentOS 7.5 en Ubuntu 22.04LTS, maar werken mogelijk niet zoals verwacht, afhankelijk van uw omgeving, zoals verschillende versies of variaties van de bevelen. Pas de opdrachten aan die in de omgeving zijn geïnstalleerd.