Dispatcher-versionerna är oberoende av AEM. Du kan ha omdirigerats till den här sidan om du har följt en länk till Dispatcher-dokumentationen som är inbäddad i dokumentationen för en tidigare version av AEM.
Dispatcher är ett Adobe Experience Manager verktyg för cachelagring och belastningsutjämning som används med en webbserver i företagsklass.
Processen för att distribuera Dispatcher är oberoende av webbservern och den OS-plattform som valts:
Så här får du en bättre förståelse för hur Dispatcher fungerar med AEM:
Använd följande information efter behov:
Det vanligaste användningsområdet för Dispatcher är att cachelagra svar från en AEM-publiceringsinstans för att minska svarstiden och öka säkerheten för den externt adresserade publicerade webbplatsen. Det mesta av diskussionen fokuserar på detta fall.
Men Dispatcher kan också användas för att öka svarstiden för dina författarinstans, särskilt om du har ett stort antal användare som redigerar och uppdaterar din webbplats. Mer information om det här fallet finns i Använda en Dispatcher med en författarserver, nedan.
Det finns två grundläggande strategier för webbpublicering:
Dispatcher hjälper till att förverkliga en miljö som är både snabb och dynamisk. Den fungerar som en del av en statisk HTML-server, som Apache, med syftet att:
Detta innebär att
statiskt innehåll hanteras med samma hastighet och enkelhet som på en statisk webbserver. Du kan även använda de administrations- och säkerhetsverktyg som är tillgängliga för dina statiska webbservrar.
dynamiskt innehåll genereras efter behov, utan att systemet blir långsammare än vad som är absolut nödvändigt.
Dispatcher innehåller mekanismer för att generera och uppdatera statiskt HTML baserat på den dynamiska platsens innehåll. Du kan ange i detalj vilka dokument som lagras som statiska filer och som alltid genereras dynamiskt.
I det här avsnittet illustreras principerna bakom den här processen.
En statisk webbserver, som Apache eller IIS, skickar statiska HTML-filer till besökare på webbplatsen. Statiska sidor skapas en gång, så samma innehåll levereras för varje begäran.
Denna process är enkel och effektiv. Om en besökare begär en fil, t.ex. en HTML-sida, hämtas filen direkt från minnet. i värsta fall läses den från den lokala enheten. Statiska webbservrar har varit tillgängliga under en lång tid, så det finns ett brett utbud av verktyg för administration och säkerhetshantering, och de är väl integrerade med nätverksinfrastrukturer.
Om du använder en CMS (Content Management Server), till exempel AEM, bearbetar en avancerad layoutmotor besökarens begäran. Motorn läser innehåll från en databas som tillsammans med format, format och åtkomsträttigheter omvandlar innehållet till ett dokument som är anpassat efter besökarens behov och rättigheter.
Med det här arbetsflödet kan du skapa mer avancerat dynamiskt innehåll, vilket ökar flexibiliteten och funktionaliteten på webbplatsen. Layoutmotorn kräver dock mer bearbetningskraft än en statisk server, så den här konfigurationen kan försämras om många besökare använder systemet.
Cachekatalogen För cachelagring använder Dispatcher-modulen webbserverns möjlighet att hantera statiskt innehåll. Dispatcher placerar de cachelagrade dokumenten i dokumentroten på webbservern.
Om konfigurationen för HTTP Header Caching saknas lagrar Dispatcher bara HTML-koden för sidan - den lagrar inte HTTP-rubrikerna. Detta scenario kan vara ett problem om du använder olika kodningar på webbplatsen, eftersom dessa sidor kan gå förlorade. Information om hur du aktiverar cachelagring av HTTP-huvud finns i Konfigurerar Dispatcher Cache.
Om du hittar dokumentroten på webbservern i nätverksansluten lagring (NAS) försämras prestandan. När en dokumentrot på NAS delas mellan flera webbservrar kan dessutom intermittenta lås inträffa när replikeringsåtgärder utförs.
Dispatcher lagrar det cachelagrade dokumentet i en struktur som motsvarar den begärda URL:en.
Det kan finnas begränsningar på operativsystemsnivå för filnamnets längd. Det vill säga om du har en URL med flera väljare.
Dispatcher har två primära metoder för att uppdatera cacheinnehållet när ändringar görs på webbplatsen.
I en innehållsuppdatering ändras ett eller flera AEM dokument. AEM skickar en syndikeringsbegäran till Dispatcher, som uppdaterar cachen enligt detta:
Följande punkter bör noteras:
Automatisk ogiltigförklaring gör automatiskt att delar av cacheminnet blir ogiltiga - utan att några filer tas bort fysiskt. Vid varje innehållsuppdatering ändras den s.k. statusfilen så att tidsstämpeln återspeglar den senaste innehållsuppdateringen.
Dispatcher har en lista över filer som kan ogiltigförklaras automatiskt. När ett dokument från den listan begärs jämför Dispatcher datumet för det cachelagrade dokumentet med statusfilens tidsstämpel:
Även här bör vissa punkter noteras:
Du kan definiera vilka dokument som Dispatcher cachelagrar i konfigurationsfilen. Dispatcher kontrollerar begäran mot listan med cachelagrade dokument. Om dokumentet inte finns med i den här listan begär Dispatcher dokumentet från AEM.
Dispatcher begär alltid dokumentet direkt från AEM i följande fall:
?
". Detta scenario indikerar vanligtvis en dynamisk sida, till exempel ett sökresultat, som inte behöver cachas.Metoderna GET eller HEAD (för HTTP-huvudet) kan nås av Dispatcher. Mer information om cachelagring av svarshuvuden finns i Cachelagra HTTP-svarshuvuden -avsnitt.
Dispatcher lagrar de cachelagrade filerna på webbservern som om de vore en del av en statisk webbplats. Om en användare begär ett tillgängligt dokument kontrollerar Dispatcher om dokumentet finns i webbserverns filsystem:
För att ta reda på om ett dokument är uppdaterat utför Dispatcher två steg:
Dokument utan automatisk ogiltigförklaring finns kvar i cachen tills de tas bort fysiskt. Till exempel en innehållsuppdatering på webbplatsen.
Belastningsutjämning innebär att distribuera webbplatsens beräknade belastning till flera instanser av AEM.
Du vinner:
högre bearbetningskraft
I praktiken innebär den ökade bearbetningskapaciteten att Dispatcher delar dokumentförfrågningar mellan flera instanser av AEM. Eftersom varje instans nu har färre dokument att behandla har du snabbare svarstider. Dispatcher sparar intern statistik för varje dokumentkategori så att den kan beräkna inläsningen och distribuera frågorna effektivt.
ökad felsäker täckning
Om Dispatcher inte tar emot svar från en instans vidarebefordrar den automatiskt begäranden till en av de andra instanserna. Om en instans blir otillgänglig är den enda effekten att sajten tar längre tid, vilket står i proportion till den förlorade datorkraften. Alla tjänster fortsätter dock.
Du kan också hantera olika webbplatser på samma statiska webbserver.
Belastningsutjämningen sprider belastningen effektivt, men cachelagring bidrar till att minska belastningen. Försök därför att optimera cachning och minska den totala belastningen innan du konfigurerar belastningsutjämning. Bra cachelagring kan öka belastningsutjämnarens prestanda eller återge onödig belastningsutjämning.
Även om en enskild Dispatcher kan mätta kapaciteten för de tillgängliga Publish-instanserna kan det för vissa sällsynta program vara bra att även balansera belastningen mellan två Dispatcher-instanser. Konfigurationer med flera utskickare måste övervägas noggrant eftersom en extra utskickare kan öka belastningen på de tillgängliga publiceringsinstanserna och enkelt kan minska prestandan i de flesta program.
Dispatcher lagrar intern statistik om hur snabbt varje instans av AEM bearbetar dokument. Utifrån dessa data uppskattar Dispatcher vilken instans som kan ge den snabbaste svarstiden när en begäran besvaras, och reserverar därför den nödvändiga beräkningstiden för den instansen.
Olika typer av förfrågningar kan ha olika genomsnittliga slutförandetider, så med Dispatcher kan du ange dokumentkategorier. Dessa kategorier beaktas sedan när tidsberäkningarna beräknas. Du kan till exempel skilja mellan HTML sidor och bilder, eftersom svarstiderna ofta är olika.
Om du använder en avancerad sökfunktion kan du skapa en kategori för sökfrågor. Med den här metoden kan Dispatcher skicka sökfrågor till den instans som svarar snabbast. Det förhindrar också att en långsammare instans slingrar sig när den tar emot flera"dyra" sökfrågor, medan de andra får de"billigare" förfrågningarna.
Med fästiga anslutningar säkerställs att dokument för en användare består av samma instans av AEM. Den här punkten är viktig om du använder personaliserade sidor och sessionsdata. Data lagras på instansen, så efterföljande förfrågningar från samma användare måste returnera till instansen annars går data förlorade.
Eftersom häftiga anslutningar begränsar Dispatcher möjlighet att optimera förfrågningar bör du bara använda dem när det behövs. Du kan ange den mapp som innehåller de"klisterlappande" dokumenten, så att alla dokument i mappen är sammansatta på samma instans för varje användare.
För de flesta sidor som använder klisterlappande anslutningar måste du stänga av cachelagring, annars ser sidan likadan ut för alla användare, oavsett sessionsinnehåll.
För få applikationer, det kan vara möjligt att använda både klibbiga anslutningar och cachning, Om du till exempel visar ett formulär som skriver data till sessionen.
I komplexa inställningar kan du använda flera Dispatcher. Du kan till exempel använda:
I så fall måste du se till att varje begäran endast går igenom en Dispatcher. En Dispatcher hanterar inte begäranden som kommer från en annan Dispatcher. Kontrollera därför att båda utskickarna har direktåtkomst till den AEM webbplatsen.
Ett leveransnätverk (CDN), som Akamai Edge Delivery eller Amazon Cloud Front, levererar innehåll från en plats nära slutanvändaren. På det viset
Som en HTTP-infrastrukturkomponent fungerar ett CDN ungefär som Dispatcher. När en CDN-nod tar emot en begäran, skickar den om möjligt begäran från cache-minnet (resursen är tillgänglig i cache-minnet och är giltig). Annars kommer den till nästa närmaste server för att hämta resursen och cachelagra den för ytterligare begäranden om det behövs.
Nästa närmaste server beror på din konfiguration. I en Akamai-konfiguration kan begäran till exempel ha följande sökväg:
Vanligtvis är Dispatcher nästa server som kan hantera dokumentet från en cache och påverka de svarshuvuden som returneras till CDN-servern.
Det finns flera sätt att styra hur länge ett CDN cachelagrar en resurs innan det hämtar om den från Dispatcher.
Explicit konfiguration
Konfigurera, hur länge vissa resurser ska hållas i CDN:ens cache, beroende på MIME-typ, tillägg, begärandetyp och så vidare.
Rubriker för förfallodatum och cachekontroll
De flesta CDN:er Expires:
och Cache-Control:
HTTP-huvuden om de skickas av den överordnade servern. Den här metoden kan till exempel uppnås med mod_expirres Apache Module.
Manuell ogiltigförklaring
Med CDN:er kan resurser tas bort från cachen via webbgränssnitt.
API-baserad ogiltigförklaring
De flesta CDN:er har också ett REST- och/eller SOAP-API som gör att resurser kan tas bort från cachen.
I en typisk AEM ger konfiguration via tillägg, via sökväg eller både och - vilket kan uppnås med punkterna 1 och 2 ovan - möjlighet att ange rimliga cachelagringsperioder för resurser som används ofta och som inte ändras så ofta, till exempel designbilder och klientbibliotek. När nya versioner distribueras krävs vanligtvis en manuell ogiltigförklaring.
Om den här metoden används för att cachelagra hanterat innehåll innebär det att innehållsändringar endast är synliga för slutanvändarna när den konfigurerade cachelagringsperioden har gått ut och dokumentet hämtas från Dispatcher igen.
Om du vill ha mer detaljerad kontroll kan du med API-baserad ogiltigförklaring ogiltigförklara ett CDN-cacheminne när Dispatcher-cachen ogiltigförklaras. Beroende på CDNs API kan du implementera egna ContentBuilder och TransportHandler (om API:t inte är REST-baserat), och konfigurera en replikeringsagent som använder dessa delar för att göra CDN:ens cache ogiltig.
Se även AEM (CQ) Dispatcher Security och CDN+Browser Caching och dokumenterad presentation Dispatcher Caching.
Om du använder AEM med Touch UI, do not innehåll för författarinstans i cache. Om cachelagring har aktiverats för författarinstansen måste du inaktivera den och ta bort innehållet i cachekatalogen. Om du vill inaktivera cachelagring redigerar du author_dispatcher.any
och ändra /rule
egenskapen för /cache
enligt följande:
/rules
{
/0000
{ /type "deny" /glob "*"}
}
En Dispatcher kan användas framför en författarinstans för att förbättra redigeringsprestanda. Så här konfigurerar du en Dispatcher för redigering:
Installera en Dispatcher på en webbserver (en Apache- eller IIS-webbserver), se Installerar Dispatcher).
Testa den nyligen installerade Dispatcher mot en fungerande AEM-publiceringsinstans. På så sätt säkerställs att en installation som är korrekt vid baslinjen utfördes.
Kontrollera nu att Dispatcher kan ansluta via TCP/IP till din författarinstans.
Ersätt exemplet dispatcher.any
filen med author_dispatcher.any
filen finns i Nedladdning av Dispatcher.
Öppna author_dispatcher.any
i en textredigerare och gör följande ändringar:
/hostname
och /port
i /renders
så att de pekar på din författarinstans./docroot
i /cache
så att de pekar på en cachekatalog. Om du använder AEM med Touch UI, se varningen ovan.Ta bort alla befintliga filer i /cache
> /docroot
som du konfigurerade ovan.
Starta om webbservern.
Med den angivna author_dispatcher.any
konfiguration, när du installerar ett CQ5-funktionspaket, snabbkorrigering eller programkodspaket som påverkar innehåll under /libs
eller /apps
måste du ta bort de cachelagrade filerna under katalogerna i Dispatcher-cachen. Om du gör det ser du till att de nyuppgraderade filerna hämtas nästa gång de begärs, och inte de gamla cachelagrade.
Om du har använt den tidigare konfigurerade författaren Dispatcher och aktiverat en Flyttningsagent gör du följande: