Tips voor het testen van prestaties

Splits uw manuscript in configureerbare scenario's, die, bijvoorbeeld zouden moeten behandelen:

• Startpagina openen

• Categoriepagina openen (PLP)

• Eenvoudige producten (PDP) weergeven - 2 lussen binnen elke herhaling

• Configureerbare Producten van de mening - 2 lijnen binnen elke herhaling

  • Stel de stappen hierboven bijvoorbeeld in op 60% van het verkeer

• Zoeken in producten

  • Stel bijvoorbeeld het zoeken in de catalogus in op 37% van het verkeer

• Winkelwagentje en Afhandeling

  • Bijvoorbeeld, zou een gebruiker die de Kar en het controlegedeelte van het manuscript voltooit aan een industrie standaardtarief van de de plaatsomzetting van de elektronische handel van rond 3% moeten in gebreke blijven
  • Aangezien de controlestroom uncached en gewoonlijk een middel intensieve verrichting is, zou het plaatsen van een onrealistisch hoog cijfer voor de aantallen mensen die orden voltooien tegenover het aantal plaatsbrowsers een onbetrouwbaar resultaat voor het volume van verkeer geven uw plaats kon behandelen.

Reinig alle caches vóór elke testrun:

• De cache van de AEM-verzender moet volledig worden schoongemaakt
• Adobe Commerce Fastly en internal cache moeten volledig worden leeggemaakt en schoongemaakt - dit kan via de cachebesturing in Adobe Commerce-beheer.

Neem een oprijperiode op in de Jmeter-test: als er geen oplaadperiode is ingesteld, wordt het verkeer niet geleidelijk opgevoerd en kan de site geen van de algemeen bezochte pagina's en onderdelen van de pagina in cache plaatsen. In het echte leven, zou het ongebruikelijk zijn voor al piekverkeer om op een volledig uncached plaats op precies de zelfde tijd aan te komen, daarom zou een hellingperiode in de testmanuscripten van Jmeter moeten worden omvat om het geheime voorgeheugen toe te staan om op te bouwen zoals op een echte e-commerce plaats zou gebeuren.

Een "Wacht tijd"tussen elke stap binnen een herhaling zou moeten worden gebruikt - in werkelijkheid zou een gebruiker niet
direct naar de volgende pagina op de site gaan tijdens hun reis - de gebruiker kan de pagina lezen en vervolgens beslissen over zijn volgende actie .

Door de thread-groepen oneindig in te stellen op een lus, maar voor een ingestelde tijd van x (bijvoorbeeld 60 minuten), wordt een herhaalbare test uitgevoerd met mediane responstijden tot vergelijkbaar met vorige testrun. Dit betekent dat er na de oplaadperiode van de set het doelaantal virtuele gebruikers is dat tegelijkertijd wordt uitgevoerd en dat dit gedurende de tijd van de set-lus zal duren.

De mediane tijd moet worden gebruikt om een verbetering/afname van de gemiddelde responstijd te bereiken, niet gemiddeld. Indien
er zijn verschillende randresultaten die veel langer duren dan de andere resultaten , wat dit gemiddelde resultaat zou scheeftrekken , maar wat wij interesseren in de reactietijd van de eindgebruiker voor de meerderheid van de gebruikers , die geschikter is voor de mediane maatregel .

Ingesloten bronnen worden niet standaard in jmeter verzameld (bijvoorbeeld JS, CSS en andere bronnen die worden gedownload wanneer een echte gebruiker de pagina bezoekt). Dit kan worden toegelaten, maar slechts voor het domein u test - de externe middelvraag zou nog moeten worden uitgesloten (b.v. wij willen geen reactietijden van de extern ontvangen diensten, bijvoorbeeld omvatten. google analytics code , omdat we er geen controle over hebben ) .

De Manager van het Geheime voorgeheugen van HTTP zou moeten worden toegelaten, dit laat Jmeter toe om paginaelementen tijdens een reis als voor te schrijven
een echte reis van de gebruiker zou tijdens het surfen op de website op zijn eigen browser plaatsvinden . Tijdens hun reis door de site zou de browser van de gebruiker de bijbehorende ingesloten bronnen slechts één keer downloaden en deze zouden dan in de cache van de browser van de gebruiker worden geplaatst. Als dezelfde gebruiker enige tijd na zijn oorspronkelijke bezoek terugkeert naar de site, kan het ook nog steeds de cache zijn dat die elementen in de cache worden opgeslagen.

Listeners moeten binnen de eigenlijke laadtestrun (bijvoorbeeld "View Results Tree" en "Aggregate Report") worden gehouden. Het opnemen van deze gegevens in de niet-GUI-testrun voor werkelijke belasting kan van invloed zijn op de prestatieresultaten die door Jmeter worden gerapporteerd, aangezien de bronnen tijdens de echte testrun worden gebruikt om de rapporten te genereren. Deze listeners zijn verwijderd uit het testscript dat moet worden vervangen door een JTL-resultatenbestand dat vervolgens kan worden verwerkt met de functie Report Dashboard van Jmeter.

Een doelreactietijd voor geëvalueerd zodat de "Apdex score"van het dashboard rapport als snelle manier kan worden gebruikt om het effect van veranderingen op prestaties tussen testlooppas te meten. De Apdex-score is gebaseerd op het feit dat een bepaalde hoeveelheid mensen de site binnen een aanvaardbare tijd kan openen. Als de reactietijd een bepaalde "frustrerende"hoeveelheid overschrijdt, vermindert dit de score. De tijden kunnen worden geplaatst gebruikend de "apdex_Tevreden_ drempel"en "apdex_tolerated_threshold"parameters.

Plaats een doel "Orders per uur"metrisch om aan bedrijfsgebruikers voor te stellen, niet een Virtuele telling van de Gebruiker. "Virtuele gebruikers" kunnen een complex onderwerp zijn om te begrijpen wat in de praktijk de test meet. Door het tarief van de plaatsomzetting, orden per uur, gemiddelde tijd te berekenen een gebruiker op de plaats doorbrengt en tijd tussen elke paginading denkt, kunnen de industrie standaardberekeningen worden gebruikt om verschillende ladingstest scenario's voor te stellen die op orden per te bereiken uur worden gebaseerd.

Tot slot zou uw Jmeter testserver op een server geografisch dichtbij moeten worden in werking gesteld waar het grootste deel van uw gebruikersverkeer uit komt en waar uw wolkeninfrastructuur wordt ontvangen - hopelijk zouden deze het zelfde zijn.