Bästa metoder för prestandatestning best-practices-for-performance-testing

Introduktion introduction

Prestandatestning är en viktig del i all AEM. Beroende på kundens krav kan prestandatestning utföras på publiceringsinstanser, författarinstanser eller både och.

Denna dokumentation kommer att innehålla en beskrivning av övergripande strategier och metoder för att utföra prestandatester samt några av de verktyg som Adobe tillhandahåller för att hjälpa till i processen. Slutligen kommer vi att analysera några av de verktyg som finns i AEM 6 som hjälp vid prestandajustering, både från kodanalys och systemkonfigurationsperspektiv.

Simulera verklighet simulating-reality

Det som är viktigast när du utför prestandatester är att se till att du härmar en produktionsmiljö så nära som möjligt. Detta kan ofta vara svårt, men det är av största vikt att säkerställa att dessa tester är korrekta. När du arbetar med att utforma prestandatester är det viktigt att tänka på följande:

Många prestandamått i AEM, t.ex. svarstid för frågor, kan påverkas av storleken på innehållet i systemet. Det är viktigt att se till att testmiljön har så nära en kopia som möjligt av produktionsdata.

De AEM versionerna och snabbkorrigeringarna som används i produktionen bör vara desamma i testmiljön. Det är också viktigt att testa vilken version av koden som distribueras till produktionen.

Testerna är meningslösa utan en miljö som liknar produktionen så nära som möjligt. I idealfallet bör maskinvaruspecifikationerna, nätverksgränssnitten, belastningsutjämnarna och CDN vara identiska med produktionen i testmiljön.

Många prestandaproblem uppstår inte förrän systemet är hårt belastat. Goda prestandatester bör simulera den belastning som produktionssystemen kommer att vara under vid sin topp.

Ange mål setting-goals

Innan prestandatestning börjar måste icke-funktionella krav ställas för att specificera belastnings- och svarstider. Om du migrerar från ett befintligt system bör du se till att svarstiden liknar dina aktuella produktionsvärden. För belastning är det bäst att ta den aktuella toppbelastningen och dubbla den. Detta säkerställer att webbplatsen kan fortsätta fungera som den ska.

verktyg tools

Det finns många kommersiellt tillgängliga verktyg för prestandatestning på marknaden. När du kör ett lastgenereringsverktyg är det viktigt att se till att de datorer som utför testerna har tillräcklig nätverksbandbredd. I annat fall genereras ingen ytterligare belastning i den miljö som testas när provningsmaskinen når anslutningens gränser.

Testverktyg testing-tools

Optimeringsverktyg optimization-tools

Övervakning

The Övervakningsprestanda dokumentation är en bra resurs för verktyg och metoder som kan användas för att diagnostisera problem och identifiera områden för justering.

Utvecklarläge i Touch UI

En av de nya funktionerna i pekgränssnittet AEM 6 är utvecklarläget. Precis som författare kan växla mellan redigerings- och förhandsgranskningslägena kan utvecklare växla till utvecklarläget i redigeringsgränssnittet för att se renderingstiden för varje komponent på sidan och för att se stackspårningar av eventuella fel. Mer information om utvecklarläget finns i CQ Gems-presentation.

Läs begärandeloggarna med rlog.jar

För en mer omfattande analys av begärandeloggarna i ett AEM. rlog.jar kan användas för att söka igenom och sortera request.log filer som AEM genererar. Denna jar-fil ingår i en AEM installation i /crx-quickstart/opt/helpers mapp. Mer information om loggverktyget och förfrågningsloggen i allmänhet finns i Övervakning och underhåll dokumentation.

Verktyget Förklara fråga

The Förklara fråga i ACS AEM Verktyg kan användas för att visa index som används när en fråga körs. Det här kan vara mycket användbart när du optimerar långsamma frågor.

PageSpeed-verktyg

Google PageSpeed-verktyg erbjuder webbplatsanalys för att följa vedertagna standarder för sidprestanda och en plugin som kan installeras tillsammans med dispatchern på en Apache-instans för ytterligare optimeringar. Mer information finns i PageSpeed Tools Website.

Författarmiljö author-environment

Utföra tester performing-tests

För att kunna utföra prestandatestning i författarmiljön måste du simulera upplevelsen hos författare. Detta innebär att författarinstallationerna måste innehålla alla komponenter, OSGi-paket, gränssnittsanpassning, anpassade index och andra tillägg som du har gjort för produktionsförfattarinstanserna.

Det finns många automatiseringsramverk som är utformade för prestanda- och belastningstestning. Anpassade skript kan spelas in i dessa verktyg och sedan spelas upp för att simulera ett oändligt antal skribenter som samtidigt utför liknande åtgärder för att skapa och aktivera innehåll. Vi rekommenderar att du använder verktyget Tough Day för att simulera aktiviteter som att överföra tusentals resurser eller aktivera ett stort antal sidor.

För de typer av miljöer som kräver mycket resurser eller sidredigering är det av största vikt att använda verktyg som t.ex. Tough Day för att säkerställa att miljön fungerar effektivt under toppbelastning. WebDAV är ett verktyg som inte kräver skript och som också kan användas för att läsa in stora mängder resurser.

MongoDB-specifika steg mongodb-specific-steps

På system med MongoDB-backendar har AEM flera JMX MBeans som behöver övervakas vid belastnings- eller prestandatester:

https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D6%2Cname%3D%22Consolidated+Cache+statistics%22%2Ctype%3D%22ConsolidatedCacheStats%22

För namngiven cache Document-Diff bör träfffrekvensen vara över .90. Om träfffrekvensen är under 90 % är det troligt att du måste ändra din DocumentNodeStoreService konfiguration. Adobe produktsupport kan rekommendera optimala inställningar för din miljö.

https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D16%2Cname%3D%22Oak+Repository+Statistics%22%2Ctype%3D%22RepositoryStats%22

The ObservationQueueMaxLength -avsnittet visar antalet händelser i Oaks observationskö under de senaste timmarna, minuterna, sekunderna och veckorna. Hitta det största antalet händelser i avsnittet"per timme". Det här numret måste jämföras med oak.observation.queue-length som finns i SlingRepositoryManager i OSGi-konsol. Om det högsta antalet som visas för observationskön överstiger queue-length ska du kontakta Adobe Support för att få hjälp med att höja inställningen. Standardinställningen är 1 000, men de flesta distributioner behöver oftast öka den till 20 000 eller 50 000.

Publiceringsmiljö publish-environment

Utföra tester performing-tests-1

Den viktigaste delen av en distribution som behöver genomgå inläsningstester är den publicerings- eller utskicksmiljö som slutanvändaren är intresserad av.

Automatiska testverktyg från tredje part kan användas för att testa webbplatsens prestanda. Med de här verktygen kan du spela in steg som användare ska gå igenom på webbplatsen och köra många av dessa sessioner samtidigt för att simulera den belastning som är typisk för en produktionswebbplats.

De flesta webbplatser för produktion har optimeringar på plats, som dispatcher caching och ett leveransnätverk. När du testar måste du se till att även dessa optimeringar är tillgängliga för testmiljön. Förutom att övervaka svarstiderna för slutanvändarna måste du också övervaka systemstatistik på publiceringsservrarna och utskickarna för att säkerställa att systemet inte begränsas av maskinvaruresurser.

På ett system som inte kräver en hög nivå av personalisering bör avsändaren cachelagra de flesta förfrågningar. Därför bör inläsningen av publiceringsinstansen förbli relativt platt. Om det krävs en hög nivå av personalisering rekommenderar vi att du använder tekniker som iFrames eller AJAX förfrågningar för det personaliserade innehållet för att tillåta så mycket dispatcher-cachning som möjligt.

För grundläggande tester kan Apache Bench användas för att mäta svarstider på webbservern och för att skapa belastning för att mäta minnesläckage. Mer information finns i exemplet i Övervakningsdokumentation.

Felsökning av prestandaproblem troubleshooting-performance-issues

När du har kört prestandatester på författarinstansen måste eventuella problem undersökas, diagnostiseras och åtgärdas. Du kan använda flera verktyg och tekniker när du utför analyser och åtgärdar problem:

När problemområden har identifierats kan programkoden genomsökas efter prestandaoptimeringar. Alla AEM som inte fungerar som de ska kan hanteras med Adobe Support.