Vanliga problem med tillgångsintag och lösningar

I den här artikeln beskrivs de vanligaste scenarierna för AEM av tillgångsintag och hur du analyserar dem, inklusive hög bearbetning, stora volymer, stora DAM-databaser och många samtidiga författare.

Beskrivning description

Miljö

Adobe Experience Manager (AEM)

Problem

I den här artikeln beskrivs de vanligaste scenarierna för AEM av tillgångsintag och hur du analyserar dem för:

Upplösning resolution

Inmatningsscenarier och lösningar

Scenario 1: Hög bearbetning

Om du till exempel importerar stora volymer, till exempel 2 000 bilder samtidigt, blir författarinstanserna höga processornivåer och mycket minne.

Lösning

Avlasta jobb till en annan AEM. Du kan avlasta hela arbetsflöden eller bara några få tunga steg genom att ansluta bearbetningsinstansen till de primära författarinstanserna via DAM-proxyarbetare. Den primära författarinstansen är därmed fortfarande fri att betjäna andra användare. DAM-proxyarbetare ansvarar för att övervaka fjärraktiviteter, samla in resultaten och mata in dem till den lokala arbetsflödeskörningen.

Scenario 2: ​

Detta är fall där det finns en databas med ett fåtal miljoner produkter som har 12 000 ändringar per dag. Databasen blir flaskhalsen i sådana scenarier. Medan skrivningar pågår blockeras läsningar av konsekvensskäl.

Lösning

Om du vill förhindra den här situationen ska du dela upp importprocessen på en dedikerad författarinstans med en egen databas. När du är klar replikerar du ett fullständigt delta i redigeringsmiljön, med kedjad replikering till publiceringsmiljön om det behövs. Använd en reserverad replikeringskö för att undvika att viktiga redaktionella ändringar fördröjs från publiceringen.

Scenario 3: Stora DAM-databaser

Detta händer med stora databaser, till exempel över 7 miljoner resurser, 20 miljoner noder och 15 TB diskstorlek. Detta påverkar instansens prestanda.

Lösning

Dela det beständiga arkivet och datalagret (optimerat för hantering av stora binärfiler). Den beständiga lagringsplatsen kräver I/O med mycket låg latens, vilket innebär att lokal lagring fungerar bäst. För datalagret accepteras en högre fördröjning.

Scenario 4: Många samtidiga författare

Många samtidiga författare kan påverka prestanda och bearbetningen.

Lösning

Samtidiga författare är användare som arbetar aktivt i systemet. Inloggad men inaktiva författare lägger inte till ytterligare belastning på systemet. Åtgärder som redigering, överföring av resurser, utlösande arbetsflöden, processor, minne, sökning och hämtning av resurser samt ändring av metadata.

Genom att skapa ett kluster med författarinstanser med en dispatcher framför, kan CPU-belastningen fördelas jämnt. Med ett stort antal författare i aktiv produktion bör du skapa en separat författarinstans eller miljö där det pågående arbetet utförs. Den här tekniken kallas innehållspartitionering.

Ställ frågor i vår Experience League Campaign-community

Om du har några frågor som du vill ha svar på om det här ämnet, eller om du vill läsa tidigare besvarade frågor, bjuder vi in dig till vårt Experience League Community-blogginlägg som innehåller den här artikeln, skickar frågor och kommentarer till oss och går med i vår Experience League Campaign Community!