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

  1. Gegevensreiniging
  2. Begintijd
  3. Aantal toegangen per uur
  4. Maximale gelijktijdige verwerking
  5. Een logbestand splitsen
  6. Aanvraagrecords samenvoegen en reactierecords

C. Voorbeelden van analyse

  1. De zwaarste toegang
  2. Accepteert ontbrekende reactie
  3. Langzame toegang
  4. Reeks gegevens van de responstijd
  5. Minimum, gemiddelde (gemiddelde), mediaan, maximale responstijd
  6. Aantal toegangen per periode
  7. Aantal responsstatussen per periode
  8. Meest voorkomende URL's
  9. access.log records voor een request.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.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f