Assets hulplijn voor grootte wijzigen assets-sizing-guide
Wanneer het rangschikken van het milieu voor een Adobe Experience Manager Assets implementatie, is het belangrijk om ervoor te zorgen dat er voldoende middelen in termen van schijf, cpu, geheugen, IO, en netwerkproductie beschikbaar zijn. Als u veel van deze bronnen wilt vergroten, moet u weten hoeveel elementen in het systeem worden geladen. Als er geen betere maateenheid beschikbaar is, kunt u de grootte van de bestaande bibliotheek delen door de leeftijd van de bibliotheek om de snelheid te vinden waarmee elementen worden gemaakt.
Schijf disk
DataStore datastore
Een algemene fout die wordt gemaakt bij het instellen van de grootte van de vereiste schijfruimte voor een Assets -implementatie, is het baseren van de berekeningen op de grootte van de Raw-afbeeldingen die in het systeem worden opgenomen. Standaard maakt Experience Manager naast de oorspronkelijke afbeelding drie uitvoeringen voor gebruik bij het renderen van de gebruikersinterface-elementen van Experience Manager . In vorige implementaties, zijn deze vertoningen waargenomen tweemaal de grootte van de activa veronderstellen die worden opgenomen.
De meeste gebruikers definiëren aangepaste uitvoeringen naast de uitvoeringen buiten de box. Naast de uitvoeringen kunt u met Assets subelementen extraheren uit gangbare bestandstypen, zoals Adobe InDesign en Adobe Illustrator .
Tot slot worden bij versiemogelijkheden van Experience Manager dubbele bestanden van de elementen in de versiegeschiedenis opgeslagen. U kunt de versies configureren die vaak moeten worden gewist. Veel gebruikers kiezen er echter voor om de versies in het systeem lange tijd te behouden, wat extra opslagruimte verbruikt.
Gezien deze factoren, vereist u een methodologie om een aanvaardbare nauwkeurige opslagruimte te berekenen om gebruikersactiva op te slaan.
- Bepaal de grootte en het aantal elementen die in het systeem worden geladen.
- Hiermee krijgt u een representatief voorbeeld van de elementen die u wilt uploaden naar Experience Manager . Als u bijvoorbeeld PSD-, JPG-, AI- en PDF-bestanden in het systeem wilt laden, hebt u meerdere voorbeeldafbeeldingen van elke bestandsindeling nodig. Bovendien moeten deze monsters representatief zijn voor de verschillende bestandsgrootten en complexiteiten van afbeeldingen.
- Definieer de uitvoeringen die moeten worden gebruikt.
- Maak de uitvoeringen in Experience Manager met behulp van ImageMagick - of Adobe Creative Cloud -toepassingen. Naast de vertoningen die de gebruikers specificeren, creeer uit-van-de-doos vertoningen. Voor gebruikers die Dynamic Media implementeren, kunt u het binaire getal IC gebruiken om de PTIFF-uitvoeringen te genereren die in de Experience Manager moeten worden opgeslagen.
- Als u subassets wilt gebruiken, genereert u deze voor de juiste bestandstypen.
- Vergelijk de grootte van de uitvoerafbeeldingen, uitvoeringen en subelementen met de oorspronkelijke afbeeldingen. Hiermee kunt u een verwachte groeifactor genereren wanneer het systeem wordt geladen. Als u bijvoorbeeld uitvoeringen en subelementen genereert met een gecombineerde grootte van 3 GB na het verwerken van 1 GB aan elementen, is de groeifactor voor de uitvoering 3.
- Bepaal de maximumtijd gedurende welke elementversies in het systeem moeten worden onderhouden.
- Bepaal hoe vaak bestaande elementen in het systeem worden gewijzigd. Als Experience Manager wordt gebruikt als een samenwerkingshoofd in creatieve werkschema's, is de hoeveelheid veranderingen hoog. Als alleen voltooide elementen naar het systeem worden geüpload, is dit aantal veel lager.
- Bepaal hoeveel elementen elke maand in het systeem worden geladen. Als u niet zeker weet, controleert u het aantal elementen dat momenteel beschikbaar is en verdeelt u het getal door de leeftijd van het oudste element om een geschatte waarde te berekenen.
Door de bovenstaande stappen uit te voeren, kunt u het volgende bepalen:
- Onbewerkte grootte van te laden elementen.
- Aantal te laden elementen.
- Rendition growth factor.
- Aantal per maand aangebrachte wijzigingen in activa.
- Aantal maanden om elementversies te onderhouden.
- Aantal nieuwe elementen dat elke maand wordt geladen.
- Jaren van groei voor toewijzing van opslagruimte.
U kunt deze aantallen in het Netwerk het Rangschikken spreadsheet specificeren om de totale ruimte te bepalen die voor uw datastore wordt vereist. Het is ook een handig hulpmiddel om te bepalen wat de invloed is van het onderhoud van elementversies of het wijzigen van elementen in Experience Manager op schijfgroei.
De voorbeeldgegevens die in het gereedschap zijn ingevuld, tonen aan hoe belangrijk het is om de vermelde stappen uit te voeren. Als u de datastore alleen op basis van de te laden Raw-afbeeldingen (1 TB) wijzigt, hebt u de grootte van de opslagplaats mogelijk met een factor 15 onderschat.
Gedeelde datastores shared-datastores
Voor grote datastores, kunt u een gedeelde datastore of door een gedeelde dossierdatastore op een netwerk in bijlage aandrijving of door een datastore van Amazon S3 uitvoeren. In dit geval hoeft in afzonderlijke gevallen geen kopie van de binaire bestanden te worden bijgehouden. Bovendien vergemakkelijkt een gedeelde datastore binair-geen replicatie en helpt de bandbreedte verminderen die wordt gebruikt om activa aan publicatiemilieu's te herhalen.
Gebruik hoofdletters use-cases
De datastore kan tussen een primaire en reserve auteursinstantie worden gedeeld om de hoeveelheid tijd te minimaliseren die het vergt om de reserve instantie met veranderingen bij te werken die in de primaire instantie worden aangebracht. U kunt datastore tussen de auteur ook delen en instanties publiceren om het verkeer tijdens replicatie te minimaliseren.
Nadelen drawbacks
Door sommige valkuilen wordt het delen van een datastore niet in alle gevallen aanbevolen.
Eén foutpunt single-point-of-failure
Met een gedeelde datastore introduceert u één foutpunt in een infrastructuur. Overweeg een scenario waarin uw systeem één auteur en twee publiceer instanties heeft, elk met hun eigen datastore. Als één van hen crasht, kunnen de andere twee nog lopen. Nochtans, als datastore wordt gedeeld, kan één enkele schijfmislukking de volledige infrastructuur onderdrukken. Zorg er daarom voor dat u een back-up van de gedeelde datastore bijhoudt vanaf waar u de datastore snel kunt herstellen.
De voorkeur wordt gegeven aan de AWS S3-service voor gedeelde datastores, omdat hierdoor de kans op mislukking aanzienlijk afneemt in vergelijking met normale schijfarchitecturen.
Meer complexiteit increased-complexity
Gedeelde datastores verhogen ook de ingewikkeldheid van verrichtingen, zoals huisvuilinzameling. Normaal, kan de huisvuilinzameling voor een standalone datastore met één enkele klik in werking worden gesteld. Nochtans, vereisen de gedeelde datastores de verrichtingen van de marktopening op elk lid dat datastore gebruikt, naast het runnen van de daadwerkelijke inzameling op één enkele knoop.
Voor AWS-bewerkingen kan het implementeren van één centrale locatie (via Amazon S3) in plaats van een RAID-array van EBS-volumes te maken, de complexiteit en operationele risico's op het systeem aanzienlijk compenseren.
Prestatieproblemen performance-concerns
Een gedeelde datastore vereist dat de binaire getallen op een netwerk-opgezette aandrijving worden opgeslagen die tussen alle instanties wordt gedeeld. Omdat deze binaire getallen over een netwerk worden betreden, worden de systeemprestaties nadelig beïnvloed. U kunt het effect gedeeltelijk verlichten door een snelle netwerkverbinding aan een snelle serie van schijven te gebruiken. Dit is echter een kostbaar voorstel. Als er AWS-bewerkingen zijn, zijn alle schijven extern en vereisen ze netwerkconnectiviteit. Ephemeral-volumes verliezen gegevens wanneer de instantie start of stopt.
Latentie latency
De latentie in S3 implementaties wordt geïntroduceerd door de achtergrond schrijvend draden. Back-upprocedures moeten rekening houden met deze vertraging. Bovendien kunnen de indexen van Lucene onvolledig blijven wanneer het maken van een steun. Het is van toepassing op elk tijdgevoelig dossier dat aan S3 datastore wordt geschreven en van een andere instantie wordt betreden.
Node Store of document Store node-store-document-store
Het is moeilijk om exacte cijfers voor de grootte van een NodeStore of DocumentStore te bepalen vanwege de middelen die door het volgende worden verbruikt:
- Metagegevens van element
- Elementen
- Controlelogboeken
- Gearchiveerde en actieve workflows
Omdat de binaire getallen in de datastore worden opgeslagen, neemt elk binair getal wat ruimte in. De meeste opslagruimten zijn kleiner dan 100 GB. Er kunnen echter grotere opslagruimten zijn met een maximale grootte van 1 TB. Bovendien hebt u voldoende vrije ruimte op het volume nodig om de gecomprimeerde opslagplaats naast de vooraf gecomprimeerde versie te herschrijven om offline compacte compressie uit te voeren. Een goede regel-van-duim is de grootte van de schijf aan 1.5 keer de grootte die voor de bewaarplaats wordt verwacht.
Voor de opslagplaats, gebruik SSDs of schijven met een IOPS niveau groter dan 3000. Om de kans te elimineren dat IOPS prestatiesknelpunten introduceert, controleert cpu IO wachttijden niveaus op vroege tekenen van kwesties.
Netwerk network
Assets heeft verschillende gebruiksgevallen die netwerkprestaties belangrijker maken dan bij veel van onze Experience Manager -projecten. Een klant kan een snelle server hebben, maar als de netwerkverbinding niet groot genoeg is om de lading van de gebruikers te steunen die activa van het systeem uploaden en downloaden, dan zal het nog langzaam lijken. Er is een goede methode om het knooppunt in het netwerkverbinding van een gebruiker aan Experience Manager bij Assets overwegingen voor gebruikerservaring, instantie het rangschikken, werkschemaevaluatie, en netwerktopologiete bepalen.
Beperkingen limitations
Wanneer het rangschikken van een implementatie, is het belangrijk om systeembeperkingen in mening te houden. Als de voorgestelde implementatie deze beperkingen overschrijdt, kunt u creatieve strategieën gebruiken, zoals het verdelen van de elementen over meerdere Assets -implementaties.
Bestandsgrootte is niet de enige factor die bijdraagt aan problemen met onvoldoende geheugen (OOM). Het hangt ook van afmetingen van het beeld af. U kunt OOM-problemen voorkomen door een hogere heapgrootte op te geven wanneer u Experience Manager start.
Bovendien kunt u het bezit van de drempelgrootte van de com.day.cq.dam.commons.handler.StandardImageHandler component in de Manager van de Configuratie uitgeven om tussentijds tijdelijk dossier groter dan nul te gebruiken.
Maximumaantal activa maximum-number-of-assets
De limiet voor het aantal bestanden dat in een datastore kan bestaan, kan 2,1 miljard zijn vanwege bestandssysteembeperkingen. Het is waarschijnlijk dat de gegevensopslagruimte problemen tegenkomt vanwege een groot aantal knooppunten lang voordat de datastore-limiet wordt bereikt.
Gebruik de Camera Raw bibliotheek als de uitvoeringen onjuist zijn gegenereerd. In dit geval mag de langste zijde van de afbeelding echter niet groter zijn dan 65000 pixels. Bovendien mag de afbeelding niet meer dan 512 MP (512 x 1024 x 1024 pixels) bevatten. De grootte van het actief is niet van belang.
Het is moeilijk nauwkeurig de grootte te schatten van het dossier van de TIFF dat uit-van-de-doos met een specifieke heap voor Experience Manager wordt gesteund omdat extra factoren, zoals pixelgrootte verwerking beïnvloeden. Het is mogelijk dat Experience Manager een bestand van 255 MB buiten de box kan verwerken, maar geen bestandsgrootte van 18 MB kan verwerken omdat het laatste bestand een ongewoon groter aantal pixels bevat dan het eerste.
Omvang van elementen size-of-assets
Standaard kunt u met Experience Manager elementen van maximaal 2 GB uploaden. Om zeer grote activa in Experience Manager te uploaden, zie Configuratie om zeer grote activate uploaden.