Richtlijnen voor hardwareaanpassing hardware-sizing-guidelines

Deze het rangschikken richtlijnen bieden een benadering van de hardwaremiddelen die worden vereist om een AEM project op te stellen. Het rangschikken van ramingen hangt van de architectuur van het project, de ingewikkeldheid van de oplossing, het verwachte verkeer en de projectvereisten af. Deze gids helpt u om de hardwarebehoeften voor een specifieke oplossing te bepalen, of een hogere en lagere schatting voor de hardwarevereisten te vinden.

De belangrijkste factoren die in aanmerking moeten worden genomen zijn (in deze volgorde):

Architectuur architecture

Een standaardinstelling voor AEM bestaat uit een auteur en een publicatieomgeving. Deze omgevingen hebben verschillende vereisten met betrekking tot de onderliggende hardwaregrootte en systeemconfiguratie. De gedetailleerde overwegingen voor beide milieu's worden beschreven in auteursomgeving en publicatieomgeving secties.

In een typisch projectopstelling, hebt u verscheidene milieu's waarop aan de fasen van het werkgebiedproject:

Bovendien kunnen de omgevingen variëren, variërend van een systeem met één server en een toepassingsserver tot een zeer geschaalde set van multi-server, multi-CPU geclusterde instanties. Wij adviseren dat u een afzonderlijke computer voor elk productiesysteem gebruikt en dat u geen andere toepassingen op deze computers in werking stelt.

Algemene overwegingen voor hardwaregrootte generic-hardware-sizing-considerations

In de volgende secties wordt uitgelegd hoe u de hardwarevereisten kunt berekenen, rekening houdend met verschillende overwegingen. Voor grote systemen stellen wij voor dat u een eenvoudige reeks interne benchmarktests op een verwijzingsconfiguratie uitvoert.

Optimalisering van prestaties is een fundamentele taak die moet worden uitgevoerd voordat benchmarking voor een specifiek project kan worden uitgevoerd. Pas het advies van het Documentatie over optimalisatie van prestaties voordat u benchmarktests uitvoert en de resultaten ervan gebruikt voor berekeningen voor het aanpassen van de hardwaregrootte.

De vereisten voor het aanpassen van de hardwaregrootte voor gevallen van geavanceerd gebruik moeten gebaseerd zijn op een gedetailleerde prestatiebeoordeling van het project. Kenmerken van gevallen van geavanceerd gebruik waarvoor uitzonderlijke hardwarebronnen nodig zijn, zijn onder meer combinaties van:

Schijfruimte/vaste schijf disk-space-hard-drive

De vereiste schijfruimte hangt sterk af van zowel het volume als het type van uw webtoepassing. Bij de berekeningen moet rekening worden gehouden met:

De schijfruimte wordt onophoudelijk gecontroleerd tijdens Online, en Off-line, de Opruiming van de Revisie. Als de beschikbare schijfruimte onder een kritieke waarde daalt, wordt het proces geannuleerd. De kritieke waarde is 25% van de huidige schijfvoetafdruk van de opslagplaats en kan niet worden geconfigureerd. Het wordt aanbevolen de schijf minstens twee of drie keer groter te maken dan de grootte van de opslagplaats, inclusief de geschatte groei.

Overweeg een installatie van redundante arrays van onafhankelijke schijven (RAID, bijvoorbeeld RAID10) voor gegevensredundantie.

Virtualisatie virtualization

AEM werkt goed in gevirtualiseerde omgevingen, maar er kunnen factoren zijn zoals CPU of I/O die niet rechtstreeks kunnen worden gelijkgesteld met fysieke hardware. Een aanbeveling is om een hogere I/O-snelheid (in het algemeen) te kiezen, aangezien dit in de meeste gevallen een cruciale factor is. Benchmarking van uw omgeving is nodig om precies te begrijpen welke bronnen nodig zijn.

Parallelisatie van AEM instanties parallelization-of-aem-instances

Misbruikszekerheid fail-safeness

Een faalveilige website wordt opgesteld op minstens twee afzonderlijke systemen. Als één systeem afbreekt, kan een ander systeem overnemen en zo de systeemmislukking compenseren.

Schaalbaarheid van systeembronnen system-resources-scalability

Terwijl alle systemen actief zijn, zijn er betere computerprestaties beschikbaar. Die extra prestaties zijn niet noodzakelijkerwijs lineair met het aantal clusterknooppunten, aangezien de relatie sterk afhankelijk is van de technische omgeving; zie Clusterdocumentatie voor meer informatie .

De schatting van het aantal clusterknooppunten dat nodig is, is gebaseerd op de basisvereisten en de specifieke gebruiksgevallen van het specifieke webproject:

Omgevingsspecifieke berekeningen van auteur author-environment-specific-calculations

Voor benchmarkingdoeleinden heeft Adobe enkele benchmarktests ontwikkeld voor op zichzelf staande auteur-instanties.

Uit bovenstaande twee tests blijkt duidelijk dat de productie varieert naargelang het type activiteit. Gebruik de activiteiten in uw omgeving als basis voor het aanpassen van de grootte van uw systeem. U krijgt betere productie met minder intensieve acties zoals wijzigen (wat ook gemeenschappelijker is).

Caching caching

In de auteursomgeving is de caching efficiency typisch veel lager, omdat de veranderingen in de website frequenter zijn en ook de inhoud hoogst interactief en gepersonaliseerd is. Met behulp van de verzender kunt u AEM bibliotheken, JavaScripts, CSS-bestanden en lay-outafbeeldingen in cache plaatsen. Hierdoor worden sommige aspecten van het ontwerpproces versneld. Als u de webserver configureert om extra headers in te stellen voor het in cache plaatsen van de browser op deze bronnen, wordt het aantal HTTP-aanvragen verminderd en wordt de systeemresponsiviteit van de auteurs verbeterd.

Auteurs die parallel werken authors-working-in-parallel

In de auteursomgeving zijn het aantal auteurs die parallel werken en de lading hun interactie aan het systeem toevoegen de belangrijkste beperkende factoren. Daarom adviseren wij dat u uw systeem schrapt dat op de gedeelde productie van gegevens wordt gebaseerd.

Voor dergelijke scenario's voert Adobe benchmarktests uit op een twee knooppunten die geen cluster van auteursinstanties delen.

Uit de bovenstaande twee tests blijkt duidelijk dat AEM schaalbaar is voor auteurs die elementaire bewerkingen met AEM uitvoeren. Over het algemeen is AEM het meest effectief bij het schalen van leesbewerkingen.

Op een typische website, gebeurt het meeste creatie tijdens de projectfase. Nadat de website live is gegaan, gooit het aantal auteurs die parallel werken doorgaans naar een lager (operationele modus) gemiddelde.

U kunt het aantal computers (of CPU's) dat vereist is voor de ontwerpomgeving als volgt berekenen:

n = numberOfParallelAuthors / 30

Deze formule kan als algemene richtlijn voor het schrapen van cpu's dienen wanneer de auteurs basishandelingen met AEM uitvoeren. Hierbij wordt ervan uitgegaan dat het systeem en de toepassing zijn geoptimaliseerd. De formule geldt echter niet voor geavanceerde functies zoals MSM of Elementen (zie de onderstaande secties).

Zie ook de aanvullende opmerkingen over Parallelisatie en Optimalisatie van prestaties.

Hardware Recommendations hardware-recommendations

Gewoonlijk kunt u voor uw auteursomgeving dezelfde hardware gebruiken als voor uw het publiceren milieu wordt geadviseerd. Websiteverkeer is doorgaans veel lager op ontwerpsystemen, maar de efficiëntie van de cache is ook lager. De fundamentele factor hierbij is echter het aantal auteurs dat parallel werkt, en het soort acties dat in het systeem wordt ondernomen. In het algemeen is AEM clustering (van de auteursomgeving) het meest effectief bij het schalen van leesbewerkingen; met andere woorden , een AEM cluster kan goed worden geschaald met auteurs die elementaire bewerkingen uitvoeren .

De benchmarktests bij Adobe zijn uitgevoerd met het RedHat 5.5-besturingssysteem, dat wordt uitgevoerd op een Hewlett-Packard ProLiant DL380 G5-hardwareplatform met de volgende configuratie:

AEM instanties werden uitgevoerd met een minimale heapgrootte van 256M, een maximale heapgrootte van 1024M.

Omgevingsspecifieke berekeningen publiceren publish-environment-specific-calculations

Efficiëntie en verkeer in cache caching-efficiency-and-traffic

Efficiëntie van de cache is van cruciaal belang voor de snelheid van de website. In de volgende tabel wordt aangegeven hoeveel pagina's per seconde een geoptimaliseerd AEM kan verwerken met een reverse-proxy, zoals de verzender:

De cacheratio is het percentage pagina's dat de verzender kan retourneren zonder toegang te hebben tot AEM. 100% geeft aan dat de verzender alle aanvragen beantwoordt, 0% betekent dat elke pagina AEM wordt berekend.

Complexiteit van sjablonen en toepassingen complexity-of-templates-and-applications

Als u complexe sjablonen gebruikt, heeft AEM meer tijd nodig om een pagina te renderen. Dit heeft geen invloed op pagina's die uit de cache zijn genomen, maar de paginagrootte is nog steeds relevant als u de totale responstijd in aanmerking neemt. Het weergeven van een complexe pagina kan eenvoudig tien keer langer duren dan het weergeven van een eenvoudige pagina.

Formule formula

Met de volgende formule kunt u een schatting berekenen van de totale complexiteit van uw AEM oplossing:

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

Op basis van de complexiteit kunt u als volgt bepalen hoeveel servers (of CPU-cores) u nodig hebt voor de publicatieomgeving:

n = (traffic * complexity / 1000 ) * activations

De variabelen in de vergelijking zijn als volgt:

Als u een complexere website hebt, hebt u ook krachtigere webservers nodig, zodat AEM een verzoek binnen een aanvaardbare tijd kan beantwoorden.

Aanvullende gebruiksspecifieke berekeningen additional-use-case-specific-calculations

Naast de berekening voor een standaardwebtoepassing moet u wellicht rekening houden met specifieke factoren voor de volgende gebruiksgevallen. De berekende waarden worden toegevoegd aan de standaardberekening.

Specifieke overwegingen voor activa assets-specific-considerations

Voor een uitgebreide verwerking van digitale elementen zijn geoptimaliseerde hardwarebronnen nodig. De belangrijkste factoren zijn de beeldgrootte en de maximale doorvoer van verwerkte afbeeldingen.

Wijs minstens 16 GB heap toe en configureer de DAM Update Asset-workflow om de Camera Raw pakket voor de opname van onbewerkte afbeeldingen.

Beheer van meerdere sites multi-site-manager

Het hulpmiddelverbruik wanneer het gebruiken van AEM MSM op een auteursmilieu hangt sterk van de specifieke gebruiksgevallen af. Basisfactoren zijn:

Het testen van het geplande gebruiksgeval met een representatief inhoudsuittreksel kan u helpen uw begrip van het middelgebruik verbeteren. Als u de resultaten met de geplande productie extrapoleert, kunt u de extra middelen beoordelen die voor AEM MSM worden vereist.

Houd er ook rekening mee dat auteurs die parallel werken, nadelige gevolgen voor de prestaties zullen waarnemen als AEM MSM-gebruiksgevallen meer middelen verbruiken dan gepland.

Overwegingen voor AEM Communities-formaat aem-communities-sizing-considerations

AEM sites die AEM Communities-functies (communitysites) bevatten, ervaren veel interactie van sitebezoekers (leden) in de publicatieomgeving.

De rangschikkingsoverwegingen voor een communautaire plaats hangen van de verwachte interactie door communautaire leden af en of optimale prestaties voor paginacontent van hoger belang is.

Door de gebruiker gegenereerde inhoud (UGC) wordt apart van de pagina-inhoud opgeslagen. Terwijl het AEM platform een knoopopslag gebruikt die plaatsinhoud van auteur aan publicatie herhaalt, gebruikt AEM Communities één enkele, gemeenschappelijke opslag voor UGC die nooit wordt herhaald.

Voor de opslag UGC, is het noodzakelijk om een leverancier van het opslagmiddel (SRP) te kiezen, die de gekozen plaatsing beïnvloedt.
Zie