Optimalisatie van prestaties
- Onderwerpen:
- Configureren
Gemaakt voor:
- Beheerder
NOTEEen belangrijk probleem is de tijd die uw website nodig heeft om te reageren op bezoekersverzoeken. Hoewel deze waarde voor elke aanvraag varieert, kan een gemiddelde doelwaarde worden bepaald. Zodra deze waarde zowel haalbaar als houdbaar is, kan deze worden gebruikt om de prestaties van de website te controleren en de ontwikkeling van potentiële problemen aan te geven.
De responstijden die u wilt opgeven, verschillen per auteur- en publicatieomgeving en weerspiegelen de verschillende kenmerken van het doelpubliek:
Auteursomgeving
Deze omgeving wordt gebruikt door auteurs die inhoud invoeren en bijwerken. Er moet rekening worden gehouden met een paar gebruikers die elk een groot aantal prestatie-intensieve aanvragen genereren bij het bijwerken van inhoudspagina's en de afzonderlijke elementen op die pagina's.
Publish-omgeving
Deze omgeving bevat inhoud die u beschikbaar maakt voor uw gebruikers. Hier is het aantal verzoeken nog groter en de snelheid is net zo belangrijk. Maar omdat de aard van de verzoeken minder dynamisch is, kunnen er aanvullende mechanismen voor prestatieverbetering worden toegepast, zoals het in cache plaatsen van de inhoud of taakverdeling.
NOTE- Na het vormen voor prestatiesoptimalisering, volg de procedures in Dag van de Stevigeom het milieu onder zware lading te testen.
- Zie ook het stemmen van Prestaties uiteinden.
Methode voor optimalisatie van prestaties
Een prestatiesoptimaliseringsmethodologie voor AEM Projecten kan in vijf eenvoudige regels worden samengevat die kunnen worden gevolgd om prestatieskwesties van begin te vermijden:
Deze regels gelden voor webprojecten in het algemeen en zijn relevant voor projectbeheerders en systeembeheerders om ervoor te zorgen dat hun projecten niet worden geconfronteerd met prestatieproblemen wanneer de starttijd aankomt.
Planning voor Optimalisatie
Plan ongeveer 10% van de projectinspanning voor de prestatiesoptimaliseringsfase. De werkelijke optimalisatievereisten voor de prestaties zijn afhankelijk van de complexiteit van een project en de ervaring van het ontwikkelingsteam. Hoewel uw project (uiteindelijk) niet de toegewezen tijd kan vereisen, is het goed om altijd voor prestatiesoptimalisering in het voorgestelde gebied te plannen.
Waar mogelijk moet een project eerst worden gelanceerd aan een beperkt publiek om praktijkervaring te vergaren en verdere optimalisaties uit te voeren, zonder de extra druk die volgt op een volledige aankondiging.
Nadat u "live" bent, is de optimalisatie van de prestaties nog niet voorbij. Het is nu wanneer u de "echte" lading op uw systeem ervaart. Het is belangrijk om na de lancering aanvullende aanpassingen te plannen.
Aangezien de systeembelasting verandert en de prestatieprofielen van uw systeem in de loop der tijd verschuiven, moet een 'afstelling' van de prestaties of 'health check' met tussenpozen van 6 tot 12 maanden worden gepland.
Realiteit simuleren
Als u live gaat met een website en u na de lancering ontdekt dat u prestatieproblemen ondervindt, is dit waarschijnlijk omdat uw belasting- en prestatietests de realiteit niet nauwkeurig genoeg hebben gesimuleerd.
Het simuleren van de realiteit is moeilijk en hoeveel moeite je wilt investeren om 'echt' te worden hangt af van de aard van je project. "Reëel" betekent niet alleen "echte code" en "echt verkeer", maar ook "echte inhoud", met name met betrekking tot de grootte en structuur van de inhoud. Uw sjablonen gedragen zich mogelijk anders, afhankelijk van de grootte en structuur van de opslagplaats.
Effen doelen vaststellen
Het belang van een correcte vaststelling van prestatiedoelen mag niet worden onderschat. Vaak is het moeilijk om deze doelen achteraf te wijzigen, ook al zijn ze gebaseerd op veronderstellingen.
Het vaststellen van goede, stevige prestatiesdoelstellingen is echt één van de moeilijkste gebieden. Het is vaak het beste om logboeken en benchmarks uit de praktijk te verzamelen van een vergelijkbare website (bijvoorbeeld de voorganger van de nieuwe website).
Relevant blijven
Het is belangrijk om één knelpunt tegelijk te optimaliseren. Als u dingen tegelijkertijd probeert te doen zonder de impact van de ene optimalisatie te valideren, kunt u het spoor kwijtraken waarvan de optimalisatiemaatregel heeft bijgedragen.
Agile-iteratiecycli
Prestaties afstemmen is een herhalend proces dat betrekking heeft op meten, analyseren, optimaliseren en valideren totdat het doel is bereikt. Om rekening te houden met dit aspect, implementeert u een flexibel validatieproces in de optimalisatiefase in plaats van een zwaarder testproces na elke herhaling.
Dit betekent dat de ontwikkelaar die de optimalisatie implementeert, snel moet kunnen zien of de optimalisatie al het doel heeft bereikt. Deze informatie is waardevol, omdat wanneer het doel wordt bereikt, optimalisering voorbij is.
Basisrichtsnoeren voor prestaties
In het algemeen, houd uw uncaching HTML- verzoeken aan minder dan 100 milliseconden. Meer in het bijzonder kan het volgende als richtsnoer dienen:
- 70% van de aanvragen voor pagina's moet binnen 100 milliseconden worden beantwoord.
- 25% van de aanvragen voor pagina's moet een antwoord krijgen binnen 100 milliseconden - 300 milliseconden.
- 4% van de aanvragen voor pagina's moet een antwoord krijgen binnen 300 milliseconden - 500 milliseconden.
- 1% van de aanvragen voor pagina's moet een antwoord krijgen binnen 500 milliseconden - 1000 milliseconden.
- Geen pagina's mogen langzamer reageren dan 1 seconde.
De bovenstaande getallen voldoen aan de volgende voorwaarden:
- Gemeten bij publicatie (geen algemene kosten in verband met een ontwerpomgeving)
- Gemeten op de server (geen netwerkoverhead)
- Niet in cache geplaatst (geen AEM uitvoercache, geen Dispatcher-cache)
- Alleen voor complexe items met veel afhankelijkheden (HTML, JS, PDF, …)
- Geen andere belasting op het systeem
Er zijn enkele problemen die vaak tot prestatieproblemen leiden, zoals:
- Dispatcher caching inefficiëntie
- Het gebruik van query's in normale weergavesjablonen.
Afstemming op JVM- en OS-niveau leidt gewoonlijk niet tot aanzienlijke prestatieverschillen en moet daarom aan het einde van de optimalisatiecyclus worden uitgevoerd.
De manier waarop een opslagplaats voor inhoud gestructureerd is, kan ook van invloed zijn op de prestaties. Voor de beste prestaties, zou het aantal kindknopen in bijlage aan individuele knopen in een inhoudsbewaarplaats niet 1.000 (als regel) moeten overschrijden.
Uw beste vrienden tijdens een gebruikelijke optimalisatie van de prestaties zijn:
- De
request.log - Op componenten gebaseerde timing
- Een Java™ profiler.
Prestaties bij het laden en bewerken van Digital Assets
Vanwege het grote gegevensvolume dat bij het laden en bewerken van digitale elementen is vereist, kunnen prestaties een probleem worden.
Twee dingen beïnvloeden de prestaties hier:
- CPU - meerdere kernen zorgen voor vloeiender werk bij transcodering
- Harde schijf - parallelle RAID-schijven bereiken hetzelfde
Houd rekening met het volgende om de prestaties te verbeteren:
- Hoeveel middelen worden per dag geüpload? Een goede schatting kan gebaseerd zijn op:
- Het tijdsbestek waarin bewerkingen worden uitgevoerd (doorgaans de duur van de werkdag, meer voor internationale operaties).
- De gemiddelde grootte van geüploade afbeeldingen (en de grootte van de uitvoeringen die per afbeelding worden gegenereerd) in megabytes.
- Bepaal de gemiddelde gegevenssnelheid:
- 80% van alle bewerkingen worden uitgevoerd in 20% van de tijd, dus in piektijd hebt u vier keer de gemiddelde gegevenssnelheid. Dergelijke prestaties zijn uw doel.
Prestatiebewaking
Prestaties (of het ontbreken ervan) zijn een van de eerste dingen die uw gebruikers opmerken. Prestaties zijn dus net als bij elke toepassing met een gebruikersinterface van essentieel belang. Om de prestaties van uw AEM installatie te optimaliseren, controleert u verschillende kenmerken van de instantie en het gedrag ervan.
Voor informatie over hoe te om prestaties controle uit te voeren, zie Prestaties van de Controle.
De problemen die prestatieproblemen veroorzaken, zijn vaak moeilijk op te sporen, zelfs als de effecten ervan gemakkelijk te zien zijn.
Een basisuitgangspunt is een goede kennis van uw systeem wanneer het zoals normaal werkt. Tenzij u weet hoe uw omgeving eruit ziet en zich gedraagt wanneer deze goed functioneert, is het moeilijk om het probleem op te sporen wanneer de prestaties achteruitgaan. Besteed tijd aan het onderzoeken van uw systeem wanneer het regelmatig loopt en zorg ervoor dat het verzamelen van prestatiesinformatie een voortdurende taak is. Dit biedt u een basis voor vergelijking als de prestaties hieronder lijden.
Het volgende diagram illustreert het pad dat een verzoek om AEM inhoud kan innemen, en dus het aantal verschillende elementen die de prestaties kunnen beïnvloeden.
De prestaties zijn ook een evenwicht tussen volume en capaciteit:
- Volume - de hoeveelheid output die wordt verwerkt en door het systeem geleverd.
- Capaciteit - de capaciteit van het systeem om het volume te leveren.
Prestaties kunnen op verschillende locaties in de hele webketen worden geïllustreerd.
Er zijn verschillende functionele gebieden die vaak van invloed zijn op de prestaties:
- Caching
- Toepassingscode (uw project)
- Zoekfunctionaliteit
Basisregels voor prestaties
Bij het optimaliseren van prestaties moet rekening worden gehouden met bepaalde regels:
- Prestaties het stemmen moet deel van elk project uitmaken.
- Niet vroeg optimaliseren in de ontwikkelingscyclus.
- Prestaties zijn slechts even goed als de zwakste schakel.
- Denk altijd aan capaciteit versus volume.
- Belangrijke zaken eerst optimaliseren.
- Optimaliseer nooit zonder realistische doelstellingen.
NOTEConfigureren voor prestaties
Bepaalde aspecten van AEM (en/of de onderliggende opslagplaats) kunnen worden geconfigureerd om de prestaties te optimaliseren. Hieronder vindt u mogelijkheden en suggesties. Voordat u wijzigingen aanbrengt, moet u zeker weten of en hoe u de desbetreffende functionaliteit gebruikt.
NOTEIndexering zoeken
Vanaf AEM 6.0 gebruikt Adobe Experience Manager een op Oak gebaseerde opslagarchitectuur.
Hier vindt u de bijgewerkte indexeringsgegevens:
Gelijktijdige workflowverwerking
Om de prestaties te verbeteren, beperkt u het aantal werkstroomprocessen die tegelijkertijd worden uitgevoerd. De workflowengine verwerkt standaard evenveel workflows als er processors beschikbaar zijn voor de Java™ VM. Wanneer workflowstappen grote hoeveelheden verwerkingsbronnen (RAM of CPU) vereisen, kan het uitvoeren van meerdere van deze workflows tegelijk hoge eisen stellen aan de beschikbare serverbronnen.
Wanneer bijvoorbeeld afbeeldingen (of DAM-elementen in het algemeen) worden geüpload, worden de afbeeldingen door de workflows automatisch in DAM geïmporteerd. Afbeeldingen hebben vaak een hoge resolutie en kunnen eenvoudig honderden MB heap-bestanden voor verwerking verbruiken. Door deze afbeeldingen parallel af te handelen, wordt er veel belasting gelegd op het geheugensubsysteem en de afvalophaler.
De workflowengine gebruikt Apache Sling-taakwachtrijen voor het verwerken en plannen van de verwerking van werkitems. De volgende taakrijservices zijn standaard gemaakt in de Apache Sling Job Queue Configuration-service factory voor het verwerken van werkstroomtaken:
- De Rij van het Werkschema van Granite: De meeste werkschemastappen, zoals degenen die activa DAM verwerken, gebruiken de dienst van de Rij van de Werkstroom van Granite.
- De Externe Rij van de Baan van het Proces van Granite Werkschema: Deze dienst wordt gebruikt voor speciale externe werkschemastappen die typisch voor contact met een extern systeem en opiniepeiling voor resultaten worden gebruikt. De stap Proces voor het uitpakken van media uit het InDesign wordt bijvoorbeeld geïmplementeerd als een extern proces. De workflowengine gebruikt de externe wachtrij voor het verwerken van de opiniepeiling. (Zie com.day.cq.workflow.exec.WorkflowExternalProcess.)
Vorm deze diensten om het maximumaantal gelijktijdig lopende werkschemaprocessen te beperken.
NOTEConfiguratie in de opslagplaats
Als u de diensten vormt gebruikend een helling:Knoop OsgiConfig, moet u PID van de bestaande diensten, bijvoorbeeld vinden: org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f7 05. U kunt de PID ontdekken gebruikend de Console van het Web.
Configureer de eigenschap met de naam queue.maxparallel .
Configuratie in de webconsole
Om deze diensten te vormen gebruikend de Console van het Web, bepaal de plaats van de bestaande configuratiepunten onder de Apache het Verdelen de dienstfabriek van de Configuratie van de Rij van de Rij van de Rij.
Vorm het bezit genoemd Maximum Parallelle Banen.
Vorm de Rij voor een Specifieke Werkstroom
Maak een taakwachtrij voor een specifiek workflowmodel, zodat u de verwerking van taken voor dat workflowmodel kunt configureren. Op deze manier, beïnvloeden uw configuraties de verwerking voor een specifiek werkschema, terwijl de configuratie van de standaard Rij van het Werkschema van Granite de de verwerking van andere werkschema's controleert.
Wanneer workflowmodellen worden uitgevoerd, creëren ze verschuivende taken voor een bepaald onderwerp. Door gebrek, past het onderwerp de onderwerpen aan die voor de algemene Rij van het Werkschema van Granite, of de Externe Rij van de Baan van het Proces van het Werkschema van Granite van het Werkschema worden gevormd:
com/adobe/granite/workflow/job*com/adobe/granite/workflow/external/job*
Werkelijke taakonderwerpen die workflowmodellen genereren, zijn modelspecifiek achtervoegsel. Bijvoorbeeld, produceert het werkschemamodel van de Activa van de Update 0} DAM {banen met het volgende onderwerp:
com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
Daarom kunt u een baanrij voor het onderwerp tot stand brengen dat de baanonderwerpen van uw werkschemamodel aanpast. Het vormen van de op prestaties betrekking hebbende eigenschappen van de rij beïnvloedt slechts het werkschemamodel dat de banen produceert die het rijonderwerp aanpassen.
De volgende procedure leidt tot een baanrij voor een werkschema, gebruikend het werkschema van de Activa van de Update DAM als voorbeeld.
-
Voer het werkschemamodel uit waarvoor u de baanrij wilt tot stand brengen, zodat de onderwerpstatistieken worden geproduceerd. Bijvoorbeeld, voeg een beeld aan Assets toe om het DAM werkschema van de Activa van de Update uit te voeren.
-
Open de Sling Job Console (
https://<host>:<port>/system/console/slingevent). -
Ontdek de werkschemagerelateerde onderwerpen in de console. Voor DAM Update Asset, zijn de volgende onderwerpen gevonden:
com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/modelcom/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/modelcom/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model
-
Creeer één baanrij voor elk van deze onderwerpen. Als u een taakwachtrij wilt maken, maakt u een fabrieksconfiguratie voor de Apache Sling Job Queue-fabrieksservice.
De fabrieksconfiguraties zijn gelijkaardig aan de Gerichte Rij van het Werkschema die in wordt beschreven Gelijktijdige Verwerking van het Werkschema, behalve het bezit van Onderwerpen past het onderwerp van uw werkschemabanen aan.
DAM Asset Synchronization Service AEM
AssetSynchronizationService wordt gebruikt om elementen te synchroniseren van gekoppelde repositories (waaronder LiveLink, Documentum®). Standaard wordt bij deze synchronisatie elke 300 seconden (5 minuten) regelmatig gecontroleerd, dus als u geen gekoppelde opslagplaatsen gebruikt, kunt u deze service uitschakelen.
Het onbruikbaar maken van de dienst wordt gedaan door te vormen de dienst OSGiCQ DAM de Dienst van de Synchronisatie van Activa om de Synchronisatie periode ( scheduler.period) aan (een minimum van) één jaar (bepaald in seconden) te plaatsen.
Meerdere DAM-instanties
De implementatie van meerdere DAM-instanties kan de prestaties verbeteren als bijvoorbeeld:
- U hebt een hoge belasting door regelmatig te uploaden van vele middelen voor de auteursomgeving; hier kan een afzonderlijke instantie DAM aan het onderhouden van auteur worden gewijd.
- U hebt meerdere teams op wereldwijde locaties (bijvoorbeeld VS, Europa, Azië).
Aanvullende overwegingen zijn:
- Scheiding "werk in uitvoering" op auteur van "final" bij publicatie
- Interne gebruikers op auteur scheiden van externe bezoekers/gebruikers bij het publiceren (bijvoorbeeld, agenten, persvertegenwoordigers, klanten, en studenten).
Beste praktijken voor kwaliteitsborging
Prestaties zijn van het grootste belang voor uw publicatieomgeving. Daarom moet u de prestatietests zorgvuldig plannen en analyseren u voor het publicatiemilieu terwijl het uitvoeren van uw project maakt.
Deze sectie is bedoeld om een gestandaardiseerd overzicht van de kwesties te geven betrokken bij het bepalen van een testconcept specifiek voor prestatietests op uw publiceer milieu. Deze informatie is hoofdzakelijk van belang voor ingenieurs QA, projectmanagers, en systeembeheerders.
Het volgende behandelt een gestandaardiseerde benadering van prestatietests voor een AEM toepassing op het milieu van Publish. Deze prestatietest omvat de volgende vijf fasen:
De controle is een extra, allesomvattend proces - noodzakelijk maar niet beperkt tot het testen.
Verificatie van kennis
Een eerste stap bestaat uit het documenteren van de basisgegevens die u moet weten voordat u kunt beginnen met testen:
- De architectuur van uw testomgeving
- Een toepassingskaart met de interne elementen die moeten worden getest (zowel afzonderlijk als gecombineerd)
Testarchitectuur
Documenteer de architectuur van de testomgeving die wordt gebruikt voor het testen van de prestaties.
U hebt een reproductie nodig van uw geplande Publish-productieomgeving, samen met Dispatcher en Load Balancer.
Toepassingsoverzicht
Krijg een duidelijk overzicht waarvan u een kaart van de volledige toepassing kunt creëren (u kunt deze kaart van tests op het milieu van de Auteur reeds hebben).
Een diagram waarin de interne elementen van de toepassing worden weergegeven, kan een overzicht geven van de testvereisten. Met kleurcodering kan de toepassing ook fungeren als basis voor rapportage.
Toepassingsdefinitie
Een toepassing heeft gewoonlijk een selectie van gebruiksgevallen. Sommige gebruiksgevallen zijn belangrijk, andere minder.
Adobe raadt u aan het volgende te definiëren om het bereik van de prestatietests tijdens het publiceren te bepalen:
- De belangrijkste zaken van het bedrijfsgebruik
- Meest kritieke gevallen van technisch gebruik
Het aantal gebruiksgevallen is aan u, maar het zou tot een gemakkelijk handelbaar aantal moeten worden beperkt (bijvoorbeeld, tussen 5 tot 10).
Zodra de belangrijkste gebruiksgevallen zijn geselecteerd, kunnen de belangrijkste prestatie-indicatoren (KPI) en de instrumenten die worden gebruikt om deze te meten voor elk geval worden bepaald. Voorbeelden van veelvoorkomende KPI's zijn:
- Reactietijd van einde tot einde
- Responstijd servlet
- Responstijd voor één component
- Responstijd voor de services
- Aantal nutteloze draden in de draadpool
- Aantal gratis verbindingen
- Systeembronnen zoals CPU- en I/O-toegang
Testmethoden
Dit concept heeft vier scenario's die voor het bepalen van en het testen van de prestatiesdoelstellingen worden gebruikt:
- Tests met één component
- Gecombineerde componenttests
- Going Levend scenario
- Foutscenario's
Gebaseerd op de volgende beginselen.
Onderdeelpunten
- Elke component heeft een specifiek breekpunt wanneer gerelateerd aan prestaties. Met andere woorden, een component kan laten zien dat goede prestaties tot een bepaald punt is bereikt, waarna de prestaties snel afnemen.
- Voor een volledig overzicht van de toepassing, moet u eerst uw componenten verifiëren wanneer het breekpunt van elk wordt bereikt.
- Om het breekpunt te vinden dat u een ladingstest kunt uitvoeren waar, over een tijdspanne, u het aantal gebruikers verhoogt om een stijgende lading tot stand te brengen. Door deze lading, en de reactie van de componenten te controleren, ontmoet u specifiek prestatiesgedrag wanneer het breekpunt van de component wordt bereikt. Het punt kan door het aantal gezamenlijke transacties per seconde, samen met het aantal gezamenlijke gebruikers worden gekwalificeerd (als de component voor dit KPI gevoelig is).
- Deze informatie kan dan als benchmark voor verbeteringen dienen, de doeltreffendheid van de gebruikte maatregelen aangeven en helpen bij het definiëren van testscenario's.
Transacties
- De term transactie wordt gebruikt om het verzoek van een volledige Web-pagina, met inbegrip van de pagina zelf en alle verdere vraag te vertegenwoordigen. Namelijk het paginaverzoek, om het even welke AJAX vraag, beelden, en andere voorwerpen Boorboor neer van het Verzoek.
- Om elk verzoek volledig te analyseren, kunt u elk element van de vraagstapel vertegenwoordigen, dan totaal de gemiddelde verwerkingstijd voor elk.
De prestatiedoelstellingen definiëren
Nadat het werkingsgebied en verwante KPIs worden bepaald, worden de specifieke prestatiesdoelstellingen geplaatst. Dit proces omvat het ontwerpen van testscenario's, samen met streefwaarden.
Testprestaties onder zowel gemiddelde als piekomstandigheden. Daarnaast hebt u tests met live-scenario's nodig om ervoor te zorgen dat u meer interesse krijgt in uw website wanneer deze voor het eerst beschikbaar wordt gesteld.
Elke ervaring of statistische gegevens die u op een bestaande website hebt verzameld, kan ook nuttig zijn bij het bepalen van toekomstige doelen. Bijvoorbeeld, hoogste verkeer van uw levende website.
Tests met één component
Kritieke onderdelen moeten worden getest - zowel onder gemiddelde als onder piekomstandigheden.
In beide gevallen kunt u het verwachte aantal transacties per seconde definiëren wanneer een vooraf gedefinieerd aantal gebruikers het systeem gebruikt.
Gecombineerde componenttests
Wanneer u de componenten in combinatie test, wordt het gedrag van de toepassingen beter weerspiegeld. Ook hier moeten de gemiddelde en piekomstandigheden worden getest.
Live tests uitvoeren
In de eerste dagen nadat uw website beschikbaar is gemaakt, kunt u een hogere mate van belangstelling verwachten. Dit scenario is zelfs groter dan de piekwaarden u voor test. Adobe raadt u aan Going Live-scenario's te testen om ervoor te zorgen dat het systeem op deze situatie kan inspelen.
Scenario-tests fout
Test foutscenario's om ervoor te zorgen dat het systeem correct en correct reageert. Niet alleen in hoe de fout zelf wordt behandeld, maar het effect het op prestaties kan hebben. Bijvoorbeeld:
- Wat gebeurt er als de gebruiker een ongeldige zoekterm in het zoekvak probeert in te voeren
- Wat gebeurt er als de zoekterm zo algemeen is dat deze een buitensporig aantal resultaten oplevert
Bij het opstellen van deze tests moet men niet vergeten dat niet alle scenario's regelmatig voorkomen. Het is echter van belang dat de gevolgen voor het hele systeem worden beïnvloed.
Duurzaamheidstests
Bepaalde problemen worden pas aangetroffen nadat het systeem gedurende een ononderbroken periode, uren of dagen wordt uitgevoerd. Een duurtest wordt gebruikt om een constante gemiddelde belasting over een vereiste periode te testen. Elke verslechtering van de prestaties kan vervolgens worden geanalyseerd.
Optimalisatie
In de latere stadia van de implementatie optimaliseert u de toepassing om de prestatiedoelen te halen en te maximaliseren.
Eventuele optimalisaties moeten worden getest om na te gaan of zij:
- De functionaliteit wordt niet beïnvloed
- Met de belastingtests zijn geverifieerd voordat ze worden vrijgegeven
U kunt kiezen uit verschillende gereedschappen voor het genereren van de belasting, het controleren van de prestaties en het analyseren van de resultaten. Enkele van deze gereedschappen zijn:
Na optimalisering, test opnieuw om het effect te bevestigen.
Rapportage
De voortdurende rapportering houdt iedereen op de hoogte van de status. Zoals eerder vermeld bij kleurcodering, kan de architectuurkaart voor deze status worden gebruikt.
Nadat alle tests zijn afgerond, rapporteren over het volgende:
- Eventuele kritieke fouten aangetroffen
- Niet-kritische kwesties die nog nader onderzoek behoeven
- Eventuele aannames tijdens de tests
- Eventuele aanbevelingen die uit de tests voortvloeien
Prestaties optimaliseren bij gebruik van de Dispatcher
Dispatcheris het caching van de Adobe en/of lading-in evenwicht brengend hulpmiddel. Als u de Dispatcher gebruikt, kunt u uw website optimaliseren voor de prestaties van de cache.
NOTEDe Dispatcher biedt verschillende ingebouwde mechanismen die u kunt gebruiken om de prestaties te optimaliseren als uw website er gebruik van maakt. In deze sectie wordt uitgelegd hoe u uw website kunt ontwerpen om de voordelen van caching te maximaliseren.
NOTEDe Dispatcher-cacheverhouding berekenen
De formule van de geheim voorgeheugenverhouding schat het percentage verzoeken die door het geheime voorgeheugen uit het totale aantal verzoeken worden behandeld die in het systeem komen. Voor het berekenen van de cacheratio hebt u het volgende nodig:
-
Het totale aantal aanvragen. Deze informatie is beschikbaar in de Apache
access.log. Voor meer details, zie de officiële documentatie Apache. -
Het aantal aanvragen dat de Publish-instantie heeft betekend. Deze informatie is beschikbaar in
request.logvan de instantie. Voor verdere details, zie Interpreting the request.logen Vindend de logboekDossiers.
De formule voor het berekenen van de cacheverhouding is:
- (Het totale aantal verzoeken minus het aantal verzoeken op Publish) verdeeld door het totale aantal verzoeken.
Bijvoorbeeld, als het totale aantal verzoeken 129491 is en het aantal verzoeken door de instantie Publish 58959 is is het geheim voorgeheugenverhouding: (129491 - 58959)/129491 = 54.5%.
Als u geen één-op-één uitgever/verzender-telegrafering hebt, voeg verzoeken van alle verzenders en uitgevers samen om een nauwkeurige meting te krijgen. Zie ook Geadviseerde Inzet.
NOTEConsistente paginacodering gebruiken
Met Dispatcher versie 4.1.11 kunt u responsheaders in cache plaatsen. Als u geen antwoordheaders in cache plaatst op Dispatcher, kunnen er problemen optreden als u pagina-coderingsgegevens opslaat in de koptekst. Als Dispatcher dan een pagina uit het cachegeheugen bedient, wordt de standaardcodering van de webserver gebruikt voor de pagina. Dit probleem kan op twee manieren worden voorkomen:
- Als u slechts één codering gebruikt, moet u ervoor zorgen dat de codering die op de webserver wordt gebruikt, gelijk is aan de standaardcodering van de AEM website.
- Als u de codering wilt instellen, gebruikt u een
<META>-tag in de sectie HTMLhead, zoals in het volgende voorbeeld:
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
URL-parameters vermijden
Vermijd indien mogelijk URL-parameters voor pagina's die u in cache wilt plaatsen. Bijvoorbeeld, als u een beeldgalerij hebt, wordt volgende URL nooit in het voorgeheugen ondergebracht (tenzij Dispatcher dienovereenkomstig wordt gevormd):
www.myCompany.com/pictures/gallery.html?event=christmas&page=1
U kunt deze parameters echter als volgt in de pagina-URL plaatsen:
www.myCompany.com/pictures/gallery.christmas.1.html
gallery.html . In de sjabloondefinitie kunt u opgeven welk script de pagina rendert of u kunt hetzelfde script voor alle pagina's gebruiken.Aanpassen via URL
Als u gebruikers toestaat de fontgrootte (of een andere lay-outaanpassing) te wijzigen, moet u ervoor zorgen dat de verschillende aanpassingen worden weerspiegeld in de URL.
Cookies worden bijvoorbeeld niet in de cache opgeslagen. Als u de fontgrootte opslaat in een cookie (of een vergelijkbaar mechanisme), blijft de fontgrootte dus niet behouden voor de pagina in de cache. Als gevolg hiervan retourneert Dispatcher willekeurige documenten van een willekeurige tekengrootte.
Door de tekengrootte als kiezer in de URL op te nemen voorkomt u dit probleem:
www.myCompany.com/news/main.large.html
www.myCompany.com/news/main.print.htmlAls titels gebruikte afbeeldingsbestanden ongeldig maken
Als u paginatitels of andere tekst als afbeeldingen rendert, is het raadzaam de bestanden op te slaan, zodat deze worden verwijderd bij een update van de inhoud op de pagina:
-
Plaats de afbeelding in dezelfde map als de pagina.
-
Gebruik de volgende naamgevingsindeling voor het afbeeldingsbestand:
<page file name>.<image file name>
U kunt bijvoorbeeld de titel van de pagina myPage.html opslaan in de file myPage.title.gif . Dit bestand wordt automatisch verwijderd als de pagina wordt bijgewerkt. Wijzigingen in de paginatitel worden dus automatisch doorgevoerd in de cache.
NOTEBeeldbestanden die voor navigatie worden gebruikt ongeldig maken
Als u afbeeldingen gebruikt voor de navigatie-items, is de methode in principe hetzelfde als bij titels, maar iets complexer. Sla alle navigatieafbeeldingen op de doelpagina's op. Als u twee afbeeldingen gebruikt voor normaal en actief, kunt u de volgende scripts gebruiken:
- Een script waarmee de pagina als normaal wordt weergegeven.
- Een script dat ".normal"-verzoeken verwerkt en het normale beeld retourneert.
- Een script dat ".active"-aanvragen verwerkt en het geactiveerde beeld retourneert.
Het is belangrijk dat u deze afbeeldingen maakt met dezelfde naamgevingsgreep als de pagina om ervoor te zorgen dat deze afbeeldingen en de pagina worden verwijderd bij het bijwerken van de inhoud.
Voor pagina's die niet worden gewijzigd, blijven de afbeeldingen in het cachegeheugen staan, hoewel de pagina's zelf automatisch ongeldig worden gemaakt.
Personalization
U wordt aangeraden de personalisatie te beperken tot de plaats waar dat nodig is. Ter illustratie:
- Als u een vrij aanpasbare startpagina gebruikt, moet die pagina telkens worden samengesteld wanneer een gebruiker erom vraagt.
- Als u daarentegen een keuze hebt uit tien verschillende startpagina's, kunt u elk van deze in cache plaatsen, waardoor de prestaties verbeteren.
TIPAls u elke pagina personaliseert door de naam van de gebruiker in de titelbar (bijvoorbeeld) te zetten, heeft het een prestatieseffect.
TIPMet betrekking tot het mengen van beperkte en openbare inhoud op één pagina, overweeg een strategie die serverinclude-bestanden in de Dispatcher gebruikt, of cliëntinclude-bestanden als Ajax in de browser.
TIPVaste verbindingen
de Vaste verbindingenzorgen ervoor dat de documenten voor één gebruiker allen op de zelfde server samengesteld zijn. Als een gebruiker deze map verlaat en er later weer naar terugkeert, blijft de verbinding behouden. Als u alle documenten wilt bewaren waarvoor kleverige verbindingen voor de website nodig zijn, definieert u één map. Probeer er geen andere documenten in op te nemen. Dit scenario beïnvloedt lading-in evenwicht brengend als u gepersonaliseerde pagina's en zittingsgegevens gebruikt.
MIME-typen
Er zijn twee manieren waarop een browser het type bestand kan bepalen:
- Met de extensie (bijvoorbeeld
.html,.gifen.jpg). - Door het MIME-type dat de server met het bestand verzendt.
Voor de meeste bestanden wordt het MIME-type geïmpliceerd in de bestandsextensie. Dat wil zeggen:
- Met de extensie (bijvoorbeeld
.html,.gifen.jpg). - Door het MIME-type dat de server met het bestand verzendt.
Als de bestandsnaam geen extensie heeft, wordt deze weergegeven als onbewerkte tekst.
Met Dispatcher versie 4.1.11 kunt u responsheaders in cache plaatsen. Als u geen antwoordheaders in de cache plaatst op Dispatcher, maakt het MIME-type deel uit van de HTTP-header. Als uw AEM-toepassing bestanden retourneert die geen herkend bestand hebben dat eindigt en in plaats daarvan afhankelijk is van het MIME-type, worden deze bestanden mogelijk onjuist weergegeven.
Volg de onderstaande richtlijnen om ervoor te zorgen dat bestanden correct in het cachegeheugen worden opgeslagen:
- Zorg ervoor dat bestanden altijd de juiste extensie hebben.
- Vermijd generieke serverscripts, die URL's zoals
download.jsp?file=2214hebben. Als u URL's met de bestandsspecificatie wilt gebruiken, moet u het script opnieuw schrijven. In het vorige voorbeeld is dit herschrijvendownload.2214.pdf.
Back-upprestaties
Deze sectie bevat een reeks benchmarks die worden gebruikt om de prestaties van AEM back-ups en de effecten van back-upactiviteiten op de prestaties van de toepassing te beoordelen. AEM back-ups veroorzaken een aanzienlijke belasting voor het systeem terwijl het wordt uitgevoerd en de Adobe meet dit effect en het effect van de instellingen voor back-upvertraging die proberen deze effecten te moduleren. Het doel is om enkele referentiegegevens te bieden over de verwachte prestaties van back-ups in realistische configuraties en hoeveelheden productiegegevens, en om u te helpen bij het schatten van de back-uptijden voor geplande systemen.
Referentiemilieu
Fysiek systeem
De resultaten die in dit document worden gerapporteerd, zijn verkregen uit benchmarks die in een referentieomgeving met de volgende configuratie worden uitgevoerd. Deze configuratie is gelijkaardig aan een typische productiemilieu in een gegevenscentrum:
- HP ProLiant DL380 G6, 8 CPU's x 2,533 GHz
- Serial Attached SCSI 300 GB harde schijven (10.000 rpm)
- RAID-controller voor hardware; acht schijven in een RAID0+5-array
- VMware image CPU x 2 Intel Xeon® E5540 @ 2,53 GHz
- Red Hat® Linux® 2.6.18-194.el5; Java™ 1.6.0_29
- Single Author-instantie
Het schijfsubsysteem op deze server is snel en vertegenwoordigt een krachtige RAID-configuratie die in een productieserver kan worden gebruikt. Back-upprestaties kunnen gevoelig zijn voor schijfprestaties en de resultaten in deze omgeving weerspiegelen de prestaties bij een snelle RAID-configuratie. Het VMWare-image is geconfigureerd voor één groot schijfvolume dat zich fysiek in de lokale schijfopslag op de RAID-array bevindt.
De AEM configuratie plaatst de opslagplaats en datastore op hetzelfde logische volume, naast het besturingssysteem en de AEM. De doelmap voor back-ups bevindt zich ook op dit logische bestandssysteem.
Gegevensvolumes
De volgende tabel illustreert de grootte van gegevensvolumes die worden gebruikt in de back-upbenchmarks. De initiële basislijninhoud wordt eerst geïnstalleerd, waarna extra bekende hoeveelheden gegevens worden toegevoegd om de inhoud waarvan een back-up wordt gemaakt, groter te maken. Back-ups worden gemaakt in specifieke stappen, zodat de inhoud van de back-up aanzienlijk toeneemt en het resultaat per dag groter wordt. De distributie van inhoud (pagina's, afbeeldingen, tags) is ruwweg gebaseerd op een realistische compositie van productieelementen. Pagina's, afbeeldingen en tags zijn beperkt tot maximaal 800 onderliggende pagina's. Elke pagina bevat de volgende onderdelen: titel, Flash, tekst/afbeelding, video, presentatie, formulier, tabel, cloud en carrousel. Afbeeldingen worden geüpload uit een groep van 400 unieke bestanden, van 37 kB tot 594 kB.
De reservebenchmark wordt herhaald met de extra inhoudssets die bij elke herhaling worden toegevoegd.
Benchmark Scenarios
De back-upbenchmarks hebben betrekking op twee hoofdscenario's: back-ups wanneer het systeem onder aanzienlijke toepassingsbelasting staat en back-ups wanneer het systeem niet actief is. Hoewel de algemene aanbeveling is dat back-ups moeten worden uitgevoerd wanneer AEM zo inactief mogelijk is, zijn er situaties waarin het nodig is dat de back-up moet worden uitgevoerd wanneer het systeem onder belasting is.
- Niet-actieve Staat - de steunen worden uitgevoerd met geen andere activiteit op AEM.
- onder Lading - de steunen worden uitgevoerd terwijl het systeem onder 80% lading van online processen is. De back-upvertraging varieerde om de impact op de belasting te zien.
De back-uptijden en -grootte van de resulterende back-up worden opgehaald uit de AEM serverlogboeken. Het wordt normaal aanbevolen dat back-ups worden gepland voor 'off-times' wanneer AEM inactief is, bijvoorbeeld 's nachts. Dit scenario is representatief voor de aanbevolen aanpak.
De lading bestaat uit gecreeerde pagina's, verwijderde pagina's, traversals, en vragen met de meeste lading die uit paginalandangen en vragen komt. Door te veel pagina's toe te voegen en te verwijderen wordt de werkruimte steeds groter en wordt voorkomen dat de back-ups worden voltooid. De verdeling van het laden die het script gebruikt, is 75% pagina-traversals, 24% query's en 1% pagina-ontwerpen (één niveau zonder geneste subpagina's). De piekgemiddelde transacties per seconde op een nutteloos systeem worden bereikt met vier gezamenlijke draden, die wanneer het testen van file-ups onder lading wordt gebruikt.
De impact van de belasting op de back-upprestaties kan worden geschat door het verschil tussen prestaties met en zonder deze toepassingsbelasting. De impact van de back-up op de doorvoer van de toepassing wordt gevonden door de doorvoerscenario's per uur te vergelijken met en zonder een gelijktijdige back-up aan de gang, en met back-ups die werken met verschillende instellingen voor "back-upvertraging".
- het Plaatsen van de Vertraging - voor verscheidene van de scenario's, werd de reservevertraging het plaatsen ook gevarieerd, gebruikend waarden van 10 milliseconden (gebrek), 1 milliseconden, en 0 milliseconden, om te onderzoeken hoe dit plaatsen de prestaties van steunen beïnvloedde.
- Reservekopype - Alle steunen waren externe steunen van de bewaarplaats die aan een reservefolder zonder het creëren van een ritssluiting wordt gemaakt, behalve in één geval voor vergelijking waar het teerbevel direct werd gebruikt. Aangezien incrementele back-ups niet naar een ZIP-bestand kunnen worden gemaakt of wanneer de voorafgaande volledige back-up een ZIP-bestand is, wordt de back-upmapmethode het meest gebruikt in productiesituaties.
Samenvatting van de resultaten
Back-uptijd en -doorvoer
Het belangrijkste resultaat van deze benchmarks is te laten zien hoe de back-uptijden variëren afhankelijk van het back-uptype en de totale hoeveelheid gegevens. In het volgende diagram wordt de verkregen back-uptijd weergegeven met de standaardback-upconfiguratie, als een functie van het totale aantal pagina's.
De reservetijden op een nutteloze instantie zijn vrij verenigbaar, die gemiddelde 0.608 MB per seconde, ongeacht volledige, of stijgende steunen (zie grafiek hieronder). De back-uptijd is gewoon een functie van de hoeveelheid gegevens waarvan een back-up wordt gemaakt. De tijd om een volledige steun te voltooien neemt duidelijk met het totale aantal pagina's toe. De tijd om een stijgende steun te voltooien klimt ook met het totale aantal pagina's, maar bij een veel lager tarief. De tijd die nodig is om de incrementele back-up te voltooien is veel korter vanwege de relatief kleine hoeveelheid gegevens waarvan een back-up wordt gemaakt.
De grootte van de gemaakte back-up is de belangrijkste bepalende factor voor de tijd die nodig is om de back-up te voltooien. In het volgende diagram wordt de tijd weergegeven die is ingenomen als functie van de uiteindelijke back-upgrootte.
Dit diagram illustreert dat zowel stijgende als volledige steunen een eenvoudig grootte tegenover tijdpatroon volgen dat de Adobe als productie kan meten. Back-uptijden op een inactieve instantie zijn redelijk consistent, met een gemiddelde van 0,61 MB per seconde, ongeacht de volledige of incrementele back-ups op de benchmarkomgeving.
Back-upvertraging
De parameter van de reservevertraging wordt verstrekt om de mate te beperken tot welke steunen productiewerklasten kunnen interfereren. De parameter geeft een wachttijd in milliseconden aan, die per bestand in de back-upbewerking wordt afgedrukt. Het algemene effect hangt gedeeltelijk af van de grootte van de betrokken bestanden. Het meten van back-upprestaties in MB/sec biedt een redelijke manier om de effecten van vertraging op de back-up te vergelijken.
- Als u een back-up tegelijkertijd uitvoert met de normale belasting van de toepassing, heeft dit een negatieve invloed op de doorvoer van de normale laadbewerking.
- De invloed kan gering zijn (maar niet minder dan 5%) of significant, waardoor de productie met maar liefst 75% afneemt. Het hangt waarschijnlijk het meest van de toepassing af.
- Back-up is geen zware belasting voor de CPU en dus zouden CPU-intensieve productiewerklasten minder worden beïnvloed door back-up dan I/O-intensieve werklasten.
Ter vergelijking: de doorvoer die wordt verkregen via een back-up van een bestandssysteem ('tar') om back-ups te maken van dezelfde opslagplaats. De prestaties van het teer zijn vergelijkbaar, maar iets hoger dan de back-up met een vertraging die op nul is ingesteld. Zelfs een kleine vertraging verlaagt de back-updoorvoer aanzienlijk en de standaardvertraging van 10 milliseconden resulteert in een sterk verminderde doorvoer. In situaties waarin back-ups kunnen worden gepland wanneer het totale gebruik van de toepassing laag is of wanneer de toepassing inactief kan zijn, verlaagt u de vertraging tot onder de standaardwaarde, zodat de back-up sneller kan worden uitgevoerd.
De daadwerkelijke impact van de doorvoer van toepassingen van een continue back-up is afhankelijk van de toepassings- en infrastructuurdetails. De vertragingswaarde moet worden gekozen door een empirische analyse van de toepassing, maar moet zo klein mogelijk worden gekozen, zodat de back-ups zo snel mogelijk kunnen worden voltooid. Omdat er slechts een zwakke correlatie is tussen de keuze van vertragingswaarde en de invloed op de doorvoer van de toepassing, zou de keuze van vertraging kortere algemene back-uptijden moeten begunstigen om de algemene impact van back-ups te minimaliseren. Een back-up die acht uur duurt, maar die invloed heeft op de doorvoer met -20%, heeft waarschijnlijk een groter algemeen effect dan een back-up die twee uur duurt, maar die invloed heeft op de doorvoer met -30%.