Allmänna riktlinjer för prestanda finns i Riktlinjer för prestanda sida.
Mer information om felsökning och korrigering av prestandaproblem finns även i Prestandaträd.
Du kan även läsa en kunskapsbasartikel på Tips för prestandajustering.
Ett viktigt problem är den tid det tar för er webbplats att svara på besökarnas förfrågningar. Även om det här värdet varierar för varje begäran kan ett genomsnittligt målvärde definieras. När det här värdet har visat sig vara både genomförbart och underhållbart kan det användas för att övervaka webbplatsens prestanda och indikera utvecklingen av potentiella problem.
De svarstider du vill ha skiljer sig åt mellan olika utvecklings- och publiceringsmiljöer, vilket återspeglar målpublikens olika egenskaper:
Den här miljön används av författare som anger och uppdaterar innehåll. Den måste tillgodose ett fåtal användare som var och en skapar ett stort antal prestandaintensiva begäranden när de uppdaterar innehållssidor och de enskilda elementen på dessa sidor.
Den här miljön innehåller innehåll som du gör tillgängligt för användarna. Här är antalet förfrågningar ännu större och hastigheten är lika viktig. Men eftersom förfrågningarnas karaktär är mindre dynamisk kan ytterligare mekanismer för prestandaförbättring tillämpas. till exempel cachelagra innehållet eller belastningsutjämning.
En prestandaoptimeringsmetod för AEM kan sammanfattas i fem enkla regler som kan följas för att undvika prestandaproblem redan från början:
Dessa regler gäller för webbprojekt i allmänhet och är relevanta för projektledare och systemadministratörer för att säkerställa att deras projekt inte ställs inför prestandamässiga utmaningar när lanseringen sker.
Planera cirka 10 % av projektinsatsen för prestandaoptimeringsfasen. De faktiska prestandaoptimeringskraven beror på ett projekts komplexitet och utvecklingsteamets erfarenheter. Även om ditt projekt (i slutändan) inte behöver den tilldelade tiden är det bra rutin att alltid planera för prestandaoptimering i den föreslagna regionen.
När så är möjligt bör ett projekt först lanseras på ett mjukt sätt till en begränsad publik för att samla in verkliga erfarenheter och genomföra ytterligare optimeringar, utan det extra tryck som följer efter ett fullständigt meddelande.
Prestandaoptimeringen är inte över när du är"live". Det är nu när du upplever den"verkliga" belastningen på ditt system. Det är viktigt att planera för ytterligare justeringar efter lanseringen.
Eftersom inläsningen av systemet ändras och prestandaprofilerna för systemet förändras över tid, bör en"trimning" eller"hälsokontroll" för prestandan schemaläggas med 6-12 månaders intervall.
Om du bor med en webbplats och sedan lanseringen får du reda på att du stöter på prestandaproblem, det beror troligen på att dina belastnings- och prestandatester inte simulerade verkligheten tillräckligt bra.
Det är svårt att simulera verkligheten och hur mycket arbete du vill lägga på att bli"verklig" beror på projektets karaktär. "Real" betyder inte bara"riktig kod" och"verklig trafik", utan även"verkligt innehåll", särskilt när det gäller innehållets storlek och struktur. Mallarna kan bete sig på olika sätt beroende på databasens storlek och struktur.
Det är inte underskattat hur viktigt det är att uppnå prestationsmålen på rätt sätt. Efter det att man fokuserat på specifika prestationsmål är det ofta svårt att ändra dessa mål efteråt, även om de bygger på antaganden.
Att uppnå goda, gedigna prestationsmål är verkligen ett av de svåraste områdena. Det är oftast bäst att samla in riktiga livsloggar och referensvärden från en jämförbar webbplats (till exempel den nya webbplatsens föregångare).
Det är viktigt att optimera en flaskhals i taget. Om du försöker göra saker parallellt utan att validera effekten av den optimerade optimeringen, kan du tappa reda på vilken optimeringsåtgärd som hjälpte.
Prestandajustering är en iterativ process som innefattar mätning, analys, optimering och validering tills målet nås. Om du vill ta hänsyn till den här aspekten implementerar du en flexibel valideringsprocess i optimeringsfasen i stället för en mer tung testprocess efter varje iteration.
Detta innebär att utvecklaren som implementerar optimeringen snabbt bör kunna se om optimeringen redan har nått målet. Den här informationen är värdefull eftersom optimeringen är över när målet har uppnåtts.
I allmänhet bör du spara dina ocachelagrade HTML-begäranden på mindre än 100 millisekunder. Mer specifikt kan följande fungera som riktlinjer:
Siffrorna ovan förutsätter följande villkor:
Det finns problem som ofta orsakar prestandaproblem, bland annat följande:
JVM- och OS-nivåjustering leder vanligtvis inte till några större prestandaförluster och bör därför utföras i slutet av optimeringscykeln.
Det sätt på vilket en innehållsdatabas är strukturerad kan även påverka prestanda. För bästa prestanda bör antalet underordnade noder som är kopplade till enskilda noder i en innehållsdatabas inte överstiga 1 000 (som regel).
Dina bästa vänner under en vanlig prestandaoptimeringsövning är:
request.log
På grund av den stora datamängden som används vid inläsning och redigering av digitala resurser kan prestanda bli ett problem.
Två saker påverkar prestandan här:
Om du vill förbättra prestanda bör du tänka på följande:
Prestanda (eller avsaknaden av) är en av de första saker som användarna märker, så som med andra program med ett användargränssnitt är prestanda av avgörande betydelse. Om du vill optimera prestanda för AEM ska du övervaka olika attribut för instansen och dess beteende.
Mer information om hur du utför prestandaövervakning finns i Övervakningsprestanda.
De problem som orsakar prestandaproblem är ofta svåra att spåra, även när effekterna är enkla att se.
En grundläggande utgångspunkt är goda kunskaper i systemet när det fungerar som vanligt. Om du inte vet hur miljön "ser ut" och "fungerar" när den fungerar som den ska, är det svårt att hitta problemet när prestandan försämras. Lägg tid på att undersöka systemet när det körs smidigt och se till att det är en pågående uppgift att samla in prestandainformation. På så sätt får du en grund att jämföra om prestandan skulle försämras.
I följande diagram visas den sökväg som en begäran om AEM kan ta och därför antalet olika element som kan påverka prestandan.
Prestanda är också en balans mellan volym och kapacitet:
Prestanda kan illustreras på olika platser i hela webbkedjan.
Det finns flera funktionsområden som ofta är ansvariga för att påverka prestandan:
Vissa regler bör beaktas vid prestandaoptimering:
Tänk på att den mekanism du använder för att mäta prestanda ofta påverkar exakt det du försöker mäta. Försök att ta hänsyn till dessa skillnader och eliminera så mycket av deras effekt som möjligt, särskilt bör webbläsarplugin-program avaktiveras när det är möjligt.
Vissa aspekter av AEM (och/eller den underliggande databasen) kan konfigureras för att optimera prestanda. Följande är möjligheter och förslag. Du måste vara säker på om du använder funktionerna innan du gör några ändringar eller inte.
Från och med AEM 6.0 använder Adobe Experience Manager en Oak-baserad databasarkitektur.
Den uppdaterade indexeringsinformationen finns här:
Om du vill förbättra prestanda bör du begränsa antalet arbetsflödesprocesser som körs samtidigt. Som standard behandlar arbetsflödesmotorn så många arbetsflöden parallellt som det finns processorer tillgängliga för den virtuella datorn Java™. När arbetsflödessteg kräver stora mängder bearbetningsresurser (RAM eller CPU) kan flera av dessa arbetsflöden köras parallellt, ställa höga krav på tillgängliga serverresurser.
När bilder (eller DAM-resurser i allmänhet) överförs, importeras bilderna automatiskt till DAM i arbetsflöden. Bilderna är ofta högupplösta och kan lätt ta upp hundratals MB av stacken för bearbetning. När du hanterar dessa bilder parallellt placeras en hög belastning på undersystemet för minne och skräpinsamlaren.
Arbetsflödesmotorn använder Apache Sling-jobbköer för hantering och schemaläggning av bearbetning av arbetsobjekt. Följande jobbkötjänster har skapats som standard från tjänsten Apache Sling Job Queue Configuration för bearbetning av arbetsflödesjobb:
Konfigurera de här tjänsterna för att begränsa antalet arbetsflödesprocesser som körs samtidigt.
Om du konfigurerar dessa jobbköer påverkas alla arbetsflöden såvida du inte har skapat en jobbkö för en viss arbetsflödesmodell (se Konfigurera kön för en viss arbetsflödesmodell nedan).
Om du konfigurerar tjänsterna använda en sling:OsgiConfig-nodmåste du hitta PID för de befintliga tjänsterna, till exempel: org.apache.sling.event.job.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Du kan identifiera ditt PID med webbkonsolen.
Konfigurera egenskapen med namnet queue.maxparallel
.
Så här konfigurerar du dessa tjänster med webbkonsolenLeta reda på de befintliga konfigurationsobjekten under konfigurationsfabriken för Apache Sling-jobbkön.
Konfigurera egenskapen Maximum Parallel Jobs.
Skapa en jobbkö för en viss arbetsflödesmodell så att du kan konfigurera jobbhantering för den arbetsflödesmodellen. På så sätt påverkar dina konfigurationer bearbetningen för ett visst arbetsflöde, medan konfigurationen av standardarbetsflödeskön för Granite styr bearbetningen av andra arbetsflöden.
När arbetsflödesmodeller körs skapas Sling-jobb för ett specifikt ämne. Som standard matchar ämnet de ämnen som är konfigurerade för den allmänna arbetsflödeskön för Begränsa arbetsflöde eller den externa jobbkön för Begränsa arbetsflöde:
com/adobe/granite/workflow/job*
com/adobe/granite/workflow/external/job*
Faktiska jobbämnen som arbetsflödesmodeller genererar innehåller modellspecifikt suffix. Till exempel DAM-uppdateringsresurs arbetsflödesmodellen genererar jobb med följande ämne:
com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
Därför kan du skapa en jobbkö för ämnet som matchar jobbavsnitten i arbetsflödesmodellen. Om du konfigurerar de prestandarelaterade egenskaperna för kön påverkas bara arbetsflödesmodellen som genererar jobben som matchar köavsnittet.
Följande procedur skapar en jobbkö för ett arbetsflöde med DAM-uppdateringsresurs arbetsflöde som exempel.
Kör arbetsflödesmodellen som du vill skapa jobbkön för så att ämnesstatistik genereras. Lägg till exempel till en bild i Resurser för att köra DAM-uppdateringsresurs arbetsflöde.
Öppna Sling Jobs-konsolen (https://<host>:<port>/system/console/slingevent
).
Identifiera arbetsflödesrelaterade ämnen i konsolen. Följande avsnitt finns för DAM Update Asset:
com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/model
com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
com/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model
Skapa en jobbkö för vart och ett av dessa ämnen. Om du vill skapa en jobbkö skapar du en fabrikskonfiguration för fabrikstjänsten för Apache Sling Job Queue.
Fabrikskonfigurationerna liknar den Granite-arbetsflödeskö som beskrivs i Samtidig bearbetning av arbetsflöden, förutom att egenskapen Ämnen matchar ämnet för dina arbetsflödesjobb.
The AssetSynchronizationService
används för att synkronisera resurser från monterade databaser (inklusive LiveLink, Documentum®, bland annat). Som standard utförs en regelbunden kontroll var 300:e sekund (5 minuter), så om du inte använder monterade databaser kan du inaktivera den här tjänsten.
Tjänsten inaktiveras av konfigurera OSGi-tjänsten CQ DAM Asset Synchronization Service för att ange Synkroniseringsperiod ( scheduler.period
) till (minst) ett år (anges i sekunder).
Distribuering av flera DAM-instanser kan hjälpa prestandan när till exempel:
Ytterligare överväganden är:
Prestanda är av stor betydelse för er publiceringsmiljö. Därför måste du noga planera och analysera prestandatesterna du gör för publiceringsmiljön när du implementerar projektet.
Det här avsnittet syftar till att ge en standardiserad översikt över problemen med att definiera ett testkoncept specifikt för prestandatester på publicera miljö. Den här informationen är främst av intresse för kvalitetstekniker, projektledare och systemadministratörer.
Följande omfattar en standardiserad metod för prestandatester för en AEM på Publicera miljö. Prestandatestet omfattar följande fem faser:
Kontrollen är en extra, heltäckande process - nödvändig men inte begränsad till testning.
Ett första steg är att dokumentera den grundläggande information som du måste känna till innan du kan börja testa:
Dokumentera arkitekturen för testmiljön som används för prestandatestning.
Du behöver en återgivning av den planerade publiceringsmiljön, tillsammans med Dispatcher och Load Balancer.
Få en tydlig översikt som du kan använda för att skapa en karta över hela programmet (du kanske redan har den här kartan från tester i redigeringsmiljön).
En diagramrepresentation av applikationens interna delar kan ge en översikt över testkraven. med färgkodning kan den också fungera som grund för rapporter.
Ett program har vanligtvis ett urval av användningsfall. Vissa användningsområden är viktiga, andra mindre viktiga.
Om du vill fokusera omfattningen på prestandatestningen vid publicering rekommenderar Adobe att du definierar följande:
Antalet användningsfall är upp till dig, men bör begränsas till ett enkelt hanterbart antal (till exempel mellan 5 och 10).
När de viktigaste användningsfallen har valts kan nyckelutförandeindikatorerna (KPI) och de verktyg som används för att mäta dem definieras för varje fall. Exempel på vanliga KPI:er är:
Det här konceptet har fyra scenarier som används för att definiera och testa prestationsmålen:
Baserat på följande principer.
När omfånget och relaterade nyckeltal har definierats, ställs de specifika prestationsmålen in. Den här processen innebär att du utformar testscenarier tillsammans med målvärden.
Provningsprestanda under både genomsnittliga och högsta förhållanden. Dessutom behöver ni Going Live-scenariotester för att försäkra er om att ni kan tillgodose det ökade intresset för er webbplats när den blir tillgänglig för första gången.
Alla erfarenheter och all statistik som du har samlat in från en befintlig webbplats kan också vara användbara när du ska fastställa framtida mål. Till exempel topptrafik från din webbplats.
Kritiska komponenter måste testas - både under medelvärdes- och toppförhållanden.
I båda fallen kan du definiera det förväntade antalet transaktioner per sekund när ett fördefinierat antal användare använder systemet.
Komponent | Testtyp | Nej. Användare | Tx/sek (förväntas) | Tx/sek (testad) | Beskrivning |
---|---|---|---|---|---|
Startsida - en användare | Genomsnittlig | 1 | 1 | ||
Toppvärde | 1 | 3 | |||
Startsida 100 användare | Genomsnittlig | 100 | 3 | ||
Toppvärde | 100 | 3 |
Genom att testa komponenterna i kombination får du en närmare bild av hur programmen fungerar. Även här måste man testa genomsnittliga och högsta förhållanden.
Scenario | Komponent | Nej. Användare | Tx/sek (förväntas) | Tx/sek (testad) | Beskrivning |
---|---|---|---|---|---|
Blandat genomsnitt | Hemsida | 10 | 1 | ||
Sökning | 10 | 1 | |||
Nyheter | 10 | 2 | |||
Händelser | 10 | 1 | |||
Aktiveringar | 10 | 3 | Simulering av författarbeteende. | ||
Blandad topp | Hemsida | 100 | 5 | ||
Sökning | 50 | 5 | |||
Nyheter | 100 | 10 | |||
Händelser | 100 | 10 | |||
Aktiveringar | 20 | 20 | Simulering av författarbeteende. |
Under de första dagarna efter det att webbplatsen har tillgängliggjorts kan du förvänta dig ett ökat intresse. Detta scenario är ännu större än de toppvärden som du testar för. Adobe rekommenderar att du testar Going Live-scenarier för att se till att systemet klarar detta.
Scenario | Testtyp | Nej. Användare | Tx/sek (förväntas) | Tx/sek (testad) | Beskrivning |
---|---|---|---|---|---|
Live-topp på väg | Hemsida | 200 | 20 | ||
Sökning | 100 | 10 | |||
Nyheter | 200 | 20 | |||
Händelser | 200 | 20 | |||
Aktiveringar | 20 | 20 | Simulering av författarbeteende. |
Testa felscenarier för att säkerställa att systemet reagerar korrekt och korrekt. Inte bara hur själva felet hanteras, utan även hur det kan påverka prestandan. Till exempel:
När man utformar dessa tester bör man komma ihåg att inte alla scenarier inträffar regelbundet. Deras inverkan på hela systemet är dock viktig.
Felscenario | Feltyp | Nej. Användare | Tx/sek (förväntas) | Tx/sek (testad) | Beskrivning |
---|---|---|---|---|---|
Överlagring av sökkomponent | Sök på globalt jokertecken (asterisk) | 10 | 1 | Endast &senaste;&senaste; söks igenom. | |
Stoppord | 20 | 2 | Söker efter ett stoppord. | ||
Tom sträng | 10 | 1 | Söker efter en tom sträng. | ||
Specialtecken | 10 | 1 | Söker efter specialtecken. |
Vissa problem uppstår bara efter att systemet har körts kontinuerligt, antingen timmar eller dagar. En uthållighetsprovning används för att testa en konstant genomsnittlig belastning under en viss tidsperiod. Alla prestandaförsämringar kan sedan analyseras.
Scenario | Testtyp | Nej. Användare | Tx/sek (förväntas) | Tx/sek (testad) | Beskrivning |
---|---|---|---|---|---|
Varaktighetsprovning (72 timmar) | Hemsida | 10 | 1 | ||
Sökning | 10 | 1 | |||
Nyheter | 20 | 2 | |||
Händelser | 10 | 1 | |||
Aktiveringar | 1 | 3 | Simulering av författarbeteende. |
I de senare implementeringsfaserna optimerar du programmet så att det uppfyller och maximerar prestandamålen.
Alla optimeringar som görs måste testas för att säkerställa att de har:
Det finns ett urval verktyg som kan hjälpa dig med lastgenerering, prestandaövervakning och resultatanalys. Några av dessa verktyg är:
Efter optimeringen testar du igen för att bekräfta påverkan.
Kontinuerlig rapportering håller alla informerade om statusen. Som tidigare nämnts med färgkodning kan arkitekturschemat användas för den här statusen.
När alla tester är slutförda, rapportera följande:
The Dispatcher är Adobe och/eller belastningsutjämningsverktyg. När du använder Dispatcher bör du överväga att optimera webbplatsen för cacheprestanda.
Dispatcher-versionerna är oberoende av AEM, men Dispatcher-dokumentationen är inbäddad i AEM. Använd alltid Dispatcher-dokumentationen som är inbäddad i dokumentationen för den senaste versionen av AEM.
Du kan ha omdirigerats till den här sidan om du har följt en länk till Dispatcher-dokumentationen som är inbäddad i dokumentationen för en tidigare version av AEM.
Dispatcher har flera inbyggda funktioner som du kan använda för att optimera prestanda om webbplatsen utnyttjar dem. I det här avsnittet beskrivs hur du utformar din webbplats för att maximera fördelarna med cachning.
Det kan hjälpa dig att komma ihåg att Dispatcher lagrar cachen på en standardwebbserver. Om du känner till den här informationen kan du cachelagra allt som du kan lagra som en sida och begära via en URL. Och du kan inte lagra andra saker, som cookies, sessionsdata och formulärdata.
I allmänhet innebär många cachelagringsstrategier att du måste välja bra URL:er och inte förlita dig på dessa ytterligare data.
Med Dispatcher version 4.1.11 kan du även cachelagra svarshuvuden, se Cachelagra HTTP-svarshuvuden.
Cachekvotsformeln uppskattar procentandelen begäranden som hanteras av cachen av det totala antalet begäranden som kommer in i systemet. För att beräkna cachekvoten behöver du följande:
Totalt antal begäranden. Den här informationen är tillgänglig i Apache access.log
. Mer information finns i officiell Apache-dokumentation.
Antalet begäranden som den publicerade instansen betjänade. Den här informationen finns i request.log
för instansen. Mer information finns i Tolka request.log och Söka efter loggfiler.
Formeln för beräkning av cacheförhållandet är:
Om det totala antalet begäranden till exempel är 129491 och antalet begäranden som hanteras av Publish-instansen är 58959 är cachekvoten: (129491 - 58959)/129491= 54,5 %.
Om du inte har ett enda utgivar-/dispatcherpar lägger du till förfrågningar från alla avsändare och utgivare tillsammans för att få en korrekt mätning. Se även Rekommenderade distributioner.
För bästa prestanda rekommenderar Adobe en cachekvot på 90 % till 95 %.
Med Dispatcher version 4.1.11 kan du cachelagra svarshuvuden. Om du inte cachelagrar svarshuvuden i Dispatcher kan det uppstå problem om du lagrar sidkodningsinformation i sidhuvudet. I det här fallet används webbserverns standardkodning för sidan när Dispatcher visar en sida från cachen. Det finns två sätt att undvika det här problemet:
<META>
-taggen i HTML head
som i följande exempel: <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
Undvik om möjligt URL-parametrar för sidor som du vill cachelagra. Om du till exempel har ett bildgalleri cachelagras aldrig följande URL (såvida inte Dispatcher är konfigurerad):
www.myCompany.com/pictures/gallery.html?event=christmas&page=1
Du kan dock placera de här parametrarna i sidans URL-adress enligt följande:
www.myCompany.com/pictures/gallery.christmas.1.html
Den här URL:en anropar samma sida och samma mall som gallery.html
. I malldefinitionen kan du ange vilket skript som ska återge sidan eller använda samma skript för alla sidor.
Om du tillåter användare att ändra teckensnittsstorleken (eller annan layoutanpassning) kontrollerar du att de olika anpassningarna återspeglas i webbadressen.
Till exempel cachelagras inte cookies, så om du sparar teckensnittsstorleken i en cookie (eller på liknande sätt) bevaras inte teckensnittsstorleken för den cachelagrade sidan. Därför returnerar Dispatcher dokument med valfri teckenstorlek på måfå.
Om du tar med teckensnittsstorleken i URL:en som väljare undviker du det här problemet:
www.myCompany.com/news/main.large.html
I de flesta layoutaspekter går det även att använda formatmallar, klientskript eller båda. Dessa instrument fungerar bra med cachning.
Den här strategin är också användbar för en utskriftsversion där du kan använda en URL-adress som:
www.myCompany.com/news/main.print.html
Med hjälp av skriptordlistan för malldefinitionen kan du ange ett separat skript som återger utskriftssidorna.
Om du återger sidrubriker, eller annan text, som bilder bör du lagra filerna så att de tas bort vid en innehållsuppdatering på sidan:
Placera bildfilen i samma mapp som sidan.
Använd följande namnformat för bildfilen:
<page file name>.<image file name>
Du kan till exempel lagra sidans rubrik myPage.html
i file myPage.title.gif
. Den här filen tas automatiskt bort om sidan uppdateras, så alla ändringar av sidans titel återspeglas automatiskt i cachen.
Bildfilen finns inte nödvändigtvis fysiskt på AEM. Du kan använda ett skript som skapar bildfilen dynamiskt. Dispatcher lagrar sedan filen på webbservern.
Om du använder bilder för navigeringsposterna är metoden i stort sett densamma som med titlar, men något mer komplex. Lagra alla navigeringsbilder med målsidorna. Om du använder två bilder för normal och aktiv användning kan du använda följande skript:
Det är viktigt att du skapar dessa bilder med samma namngivningshandtag som sidan, så att du är säker på att en innehållsuppdatering tar bort dessa bilder och sidan.
För sidor som inte ändras finns bilderna kvar i cacheminnet, även om själva sidorna är automatiskt ogiltiga.
Vi rekommenderar att du begränsar personaliseringen till där det är nödvändigt. Så här visar du varför:
Mer information om hur du konfigurerar Dispatcher-cachen finns i AEM Dispatcher Cache - självstudiekurs och dess avsnitt Cachelagra skyddat innehåll.
Om du anpassar varje sida genom att placera användarens namn i namnlisten (till exempel), har det en prestandaeffekt.
Information om cachelagring av skyddat innehåll finns i Cachelagra skyddat innehåll i Dispatcher-guiden.
När det gäller att blanda begränsat och offentligt innehåll på en sida bör du överväga en strategi där SSI (server side includes) används i Dispatcher, eller att klientsidan inkluderar via Ajax i webbläsaren.
Information om hur du hanterar blandat offentligt och begränsat innehåll finns i Konfigurera dynamisk SSLING-inkludering.
Fästanslutningar se till att dokumenten för en användare är sammansatta på samma server. Om en användare lämnar den här mappen och senare återgår till den, stannar anslutningen fortfarande kvar. Om du vill lagra alla dokument som kräver klisterlappar för webbplatsen, definierar du en mapp. Försök att inte ha med andra dokument i den. Det här scenariot påverkar belastningsutjämningen om du använder personaliserade sidor och sessionsdata.
Det finns två sätt som en webbläsare kan använda för att avgöra vilken typ av fil det är:
.html
, .gif
och .jpg
).För de flesta filer används MIME-typen i filtillägget. Det vill säga,
.html
, .gif
och .jpg
).Om filnamnet inte har något filtillägg visas det som oformaterad text.
Med Dispatcher version 4.1.11 kan du cachelagra svarshuvuden. Om du inte cachelagrar svarshuvuden för Dispatcher är MIME-typen en del av HTTP-huvudet. Om ditt AEM returnerar filer som inte har ett känt filslut, och i stället använder MIME-typen, kan dessa filer visas felaktigt.
Följ dessa riktlinjer för att vara säker på att filerna cachelagras korrekt:
download.jsp?file=2214
. Om du vill använda URL:er som innehåller filspecifikationen skriver du om skriptet. I föregående exempel är den här omskrivningen download.2214.pdf
.I det här avsnittet presenteras en serie prestandatester som används för att utvärdera AEM säkerhetskopiering och hur säkerhetskopiering påverkar programmets prestanda. AEM säkerhetskopieringar är mycket belastade på systemet medan det körs, och Adobe mäter effekten och effekterna av inställningarna för fördröjning av säkerhetskopieringen som försöker modulera dessa effekter. Målet är att tillhandahålla vissa referensdata om förväntade prestanda för säkerhetskopieringar i realistiska konfigurationer och kvantiteter av produktionsdata, och att ge vägledning om hur man beräknar säkerhetskopieringstider för planerade system.
De resultat som rapporteras i det här dokumentet har hämtats från referensvärden som körs i en referensmiljö med följande konfiguration. Den här konfigurationen liknar en typisk produktionsmiljö i ett datacenter:
Diskundersystemet på den här servern är snabbt och representativt för en RAID-konfiguration med höga prestanda som kan användas i en produktionsserver. Säkerhetskopieringsprestanda kan vara beroende av diskprestanda och resultatet i den här miljön avspeglar prestanda i en snabb RAID-konfiguration. VMWare-avbildningen är konfigurerad att ha en enda stor diskvolym som fysiskt finns i den lokala disklagringen på RAID-matrisen.
Den AEM konfigurationen placerar databasen och datalagret på samma logiska volym, tillsammans med operativsystemet och AEM. Målkatalogen för säkerhetskopieringar finns också i det här logiska filsystemet.
Följande tabell visar storleken på datavolymer som används i prestandatesterna för säkerhetskopiering. Det ursprungliga baslinjeinnehållet installeras först, sedan läggs ytterligare kända datamängder till för att öka storleken på det säkerhetskopierade innehållet. Säkerhetskopior skapas i specifika steg för att representera en stor ökning av innehållet och vad som kan produceras under en dag. Distributionen av innehåll (sidor, bilder, taggar) är i stort sett baserad på realistisk komposition av produktionsresurser. Sidor, bilder och taggar är begränsade till högst 800 underordnade sidor. Varje sida innehåller komponenterna title, Flash, text/image, video, bildspel, form, table, cloud och carousel. Bilder överförs från en pool med 400 unika filstorlekar från 37 kB till 594 kB.
Innehåll | Noder | Sidor | Bilder | Taggar |
---|---|---|---|---|
Grundinstallation | 69 610 | 562 | 256 | 237 |
Liten information för stegvis säkerhetskopiering | +100 | +2 | +2 | |
Stort innehåll för fullständig säkerhetskopiering | +10 000 | +100 | +100 |
Prestandatestvärdet för säkerhetskopiering upprepas med ytterligare innehållsuppsättningar som läggs till vid varje upprepning.
Referensvärdena för säkerhetskopiering omfattar två huvudscenarier: säkerhetskopierar när systemet är under en betydande programbelastning och säkerhetskopierar när systemet är inaktivt. Även om den allmänna rekommendationen är att säkerhetskopieringar ska utföras när AEM är så inaktiv som möjligt, finns det situationer då det är nödvändigt att säkerhetskopieringen måste köras när systemet är under laddning.
Tidpunkter och storlek för säkerhetskopieringen hämtas från AEM. Det rekommenderas normalt att säkerhetskopieringar schemaläggs i fel tider när AEM är ledig, till exempel mitt i natten. Detta scenario är representativt för den rekommenderade metoden.
Inläsningen består av sidor som skapats, sidor som tagits bort, bläddringar och frågor med de flesta inläsningar som kommer från sidbläddringar och frågor. Om du lägger till och tar bort för många sidor ökar arbetsytans storlek kontinuerligt och förhindrar att säkerhetskopiorna slutförs. Den lastfördelning som skriptet använder är 75 % sidvändningar, 24 % frågor och 1 % sidskapande (en nivå utan kapslade undersidor). Maximalt medelvärde för transaktioner per sekund i ett system som är inaktivt uppnås med fyra samtidiga trådar, som används vid testning av säkerhetskopior som läses in.
Inläsningens inverkan på säkerhetskopieringsprestanda kan uppskattas av skillnaden mellan prestanda med och utan den här programinläsningen. Effekten av säkerhetskopieringen på programmets dataflöde hittas genom att man jämför scenariogenomströmningen i transaktioner per timme med och utan en pågående samtidig säkerhetskopiering och med säkerhetskopieringar som körs med olika inställningar för fördröjning av säkerhetskopiering.
Det främsta resultatet av dessa prestandatester är att visa hur tiden för säkerhetskopiering varierar beroende på säkerhetskopieringstyp och total datamängd. I följande diagram visas den inhämtade säkerhetskopieringstiden med standardkonfigurationen för säkerhetskopiering, som en funktion av det totala antalet sidor.
Säkerhetskopieringstiderna för en inaktiv instans är relativt konsekventa, vilket är ett genomsnitt på 0,608 MB per sekund, oavsett fullständig eller stegvis säkerhetskopiering (se diagrammet nedan). Tidpunkten för säkerhetskopieringen är helt enkelt en funktion av mängden data som säkerhetskopieras. Tiden det tar att slutföra en fullständig säkerhetskopiering ökar tydligt med det totala antalet sidor. Tiden det tar att slutföra en stegvis säkerhetskopiering ökar också med det totala antalet sidor, men med en mycket lägre hastighet. Den tid det tar att slutföra den inkrementella säkerhetskopieringen är mycket kortare på grund av den relativt små mängden data som säkerhetskopieras.
Storleken på säkerhetskopian som skapas är den viktigaste faktorn för den tid det tar att slutföra en säkerhetskopiering. I följande diagram visas hur lång tid det tar som en funktion av den slutliga säkerhetskopieringsstorleken.
Diagrammet visar att både inkrementell och fullständig säkerhetskopiering följer ett enkelt storleksmönster jämfört med tidsmönster som Adobe kan mäta som genomströmning. Säkerhetskopieringstiderna för en inaktiv instans är relativt konsekventa, vilket ger ett genomsnitt på 0,61 MB per sekund oavsett fullständig eller inkrementell säkerhetskopiering i testmiljön.
Parametern för fördröjning av säkerhetskopiering anges för att begränsa i vilken utsträckning säkerhetskopiering kan påverka arbetsbelastningen i produktionen. Parametern anger en väntetid i millisekunder, vilket är inbäddat i säkerhetskopieringen fil för fil. Den övergripande effekten beror delvis på storleken på de filer som påverkas. Genom att mäta säkerhetskopieringsprestanda i MB/sek kan du jämföra fördröjningseffekterna för säkerhetskopieringen på ett rimligt sätt.
Som en jämförelse kan nämnas den genomströmning som erhålls med en säkerhetskopia av filsystemet ('tar') för att säkerhetskopiera samma databasfiler. Tjärans prestanda är jämförbar, men något högre än säkerhetskopian med fördröjningen inställd på noll. Även om du anger en liten fördröjning minskar säkerhetskopieringens genomströmning avsevärt och standardfördröjningen på 10 millisekunder resulterar det i avsevärt mindre genomströmning. I situationer där säkerhetskopieringar kan schemaläggas när den totala programanvändningen är låg eller programmet kan vara inaktivt, kan du minska fördröjningen under standardvärdet så att säkerhetskopieringen kan fortsätta snabbare.
Den faktiska effekten av applikationens genomströmning vid en pågående säkerhetskopiering beror på applikations- och infrastrukturinformationen. Fördröjningsvärdet bör väljas genom empirisk analys av programmet, men bör väljas så litet som möjligt så att säkerhetskopieringen kan slutföras så snabbt som möjligt. Eftersom det bara finns en svag korrelation mellan valet av fördröjningsvärde och effekten på applikationens genomströmning, bör fördröjning främja kortare övergripande säkerhetskopieringstider för att minimera den övergripande effekten av säkerhetskopieringar. En säkerhetskopiering som tar åtta timmar att slutföra men påverkar dataflödet med -20 % har troligen större total effekt än en som tar två timmar att slutföra men påverkar dataflödet med -30 %.