Veelvoorkomende problemen met het opnemen van bedrijfsmiddelen en oplossingen

In dit artikel worden de meest voorkomende uitgiftescenario's beschreven voor het opnemen van AEM middelen en hoe u deze kunt analyseren, zoals een hoge verwerking, een hoog volume, grote DAM-opslagruimten en veel gelijktijdige auteurs.

Beschrijving description

Omgeving

Adobe Experience Manager (AEM)

Probleem

Dit artikel beschrijft de gemeenschappelijkste scenario's van de de elementenopname van AEM en hoe te om hen voor te analyseren:

Resolutie resolution

Ingestiescenario's en oplossingen

Scenario 1: Hoge verwerking

Situaties zoals bulkimport, zoals 2.000 afbeeldingen tegelijk, zorgen ervoor dat de auteur veel CPU en geheugen gebruikt.

Oplossing

Taken verschuiven naar een andere AEM. U kunt volledige workflows of slechts een paar zware stappen offloaden door verwerkingsinstanties aan te sluiten op de primaire auteur instanties via DAM-proxyworkers. De primaire auteurinstantie daardoor blijft vrij om andere gebruikers te dienen. DAM de volmachtsarbeiders zijn verantwoordelijk voor het controleren van verre taken, het verzamelen van de resultaten, en het voeren van hen aan de lokale werkschemauitvoering.

Scenario 2: ​ voor hoge volumes

Dit zijn instanties waar een gegevensbestand van weinig miljoen producten die 12.000 wijzigingen per dag hebben. De repository wordt het knelpunt in dergelijke scenario's. Er wordt geschreven, maar lezen wordt geblokkeerd ten behoeve van de consistentie.

Oplossing

Om deze situatie te voorkomen, scheidt u het importproces op een speciale auteurinstantie met een eigen opslagplaats. Na voltooiing, repliceer een volledige delta aan het auteursmilieu, met ketende replicatie aan het publicatiemilieu, indien nodig. Gebruik een gereserveerde replicatierij om belangrijke redactionele wijzigingen van publicatie te voorkomen.

Scenario 3: grote DAM-opslagplaatsen

Dit gebeurt met enorme opslagplaatsen, zoals meer dan 7 miljoen middelen, 20 miljoen knooppunten en 15 TB schijfgrootte. Dit is van invloed op de prestaties van de instantie.

Oplossing

Splits de blijvende opslag en de gegevensopslag (geoptimaliseerd voor het behandelen van grote binaire getallen). De persistente opslag vereist zeer lage latentie-I/O, waardoor lokale opslag het beste werkt. Voor de gegevensopslag, is een hogere latentie aanvaardbaar.

Scenario 4: Veel gelijktijdige auteurs

Veel gelijktijdige auteurs kunnen de prestaties en de verwerking beïnvloeden.

Oplossing

Gelijktijdige auteurs zijn gebruikers die actief aan het systeem werken. Ingeschreven maar inactieve auteurs plaatsen geen extra belasting op het systeem. Bewerkingen zoals bewerken, elementen uploaden, workflows activeren CPU-, geheugen-, zoek- en downloadmiddelen en metagegevens wijzigen.

Als u een cluster met auteurinstanties opmaakt met een verzender op de voorgrond, wordt de CPU-belasting gelijkmatig verdeeld. Met een groot aantal auteurs in actieve productie, wordt het geadviseerd om van elk project in een afzonderlijke auteursinstantie of een milieu te spinnen waarin het lopende werk plaatsvindt. Deze techniek wordt genoemd inhoud die verdelen.

stellen vragen in onze Gemeenschap van de Campagne van het Experience League

Als u om het even welke vragen hebt u over dit onderwerp zou willen antwoorden, of vorige beantwoord-vragen leest, nodigen wij u uit om ons ​ Communautaire blogpost van de Experience League ​ te bekijken die dit artikel omvat, ons uw vragen en commentaren te verzenden, en zich bij onze Gemeenschap van de Campagne van de Experience League aan te sluiten!