Overzicht van verzending

OPMERKING

Dispatcher-versies zijn onafhankelijk van AEM. U bent mogelijk omgeleid naar deze pagina als u een koppeling naar de Dispatcher-documentatie hebt gevolgd die is ingesloten in de documentatie voor een vorige versie van AEM.

Dispatcher is een Adobe Experience Manager-programma voor caching en/of taakverdeling dat kan worden gebruikt in combinatie met een webserver op bedrijfsniveau.

Het proces voor de implementatie van de dispatcher is onafhankelijk van de webserver en het gekozen besturingssysteem-platform:

  1. Meer informatie over Dispatcher (deze pagina). Zie ook vaak gestelde vragen over dispatcher.
  2. Installeer een ondersteunde webserver volgens de documentatie van de webserver.
  3. Installeer de Dispatcher- module op uw webserver en configureer de webserver dienovereenkomstig.
  4. Configureer Dispatcher (het bestand dispatcher.any).
  5. Configureer AEM zodat de cache ongeldig wordt als de inhoud wordt bijgewerkt.
OPMERKING

Voor een beter inzicht in de werking van Dispatcher met AEM:

Gebruik de volgende informatie zoals vereist:

OPMERKING

Dispatcher wordt vooral gebruikt om de respons van een AEM Publish-instantie in de cache op te slaan, zodat u sneller kunt reageren en uw gepubliceerde, naar buiten gerichte website beter kunt beveiligen. Het grootste deel van de discussie gaat over deze zaak.

Maar de Dispatcher kan ook worden gebruikt om de reactiesnelheid van uw auteurinstantie te verhogen, met name als u een groot aantal gebruikers hebt die uw website uitgeven en bijwerken. Zie Een verzender gebruiken met een Auteur-server hieronder voor meer informatie over dit geval.

Waarom Dispatcher gebruiken om Caching uit te voeren?

Er zijn twee basisbenaderingen voor webpublicatie:

  • Statische webservers: zoals Apache of IIS zijn heel eenvoudig, maar snel.
  • Servers voor inhoudsbeheer: die dynamische, in real time, intelligente inhoud verstrekken, maar veel meer computertijd en andere middelen vereisen.

De Dispatcher helpt een omgeving te realiseren die zowel snel als dynamisch is. Het werkt als deel van een statische server van HTML, zoals Apache, met als doel:

  • het opslaan (of "in cache plaatsen") van zoveel mogelijk site-inhoud, in de vorm van een statische website
  • zo weinig mogelijk toegang krijgen tot de layout-engine.

Dit betekent dat:

  • statische inhoud die met exact dezelfde snelheid en versnelling wordt afgehandeld als op een statische webserver;daarnaast kunt u de beheer- en beveiligingsgereedschappen gebruiken die beschikbaar zijn voor uw statische webserver(s).

  • indien nodig dynamische inhoud wordt gegenereerd zonder dat het systeem verder wordt vertraagd dan absoluut noodzakelijk is.

Dispatcher bevat mechanismen voor het genereren en bijwerken van statische HTML op basis van de inhoud van de dynamische site. U kunt in detail specificeren welke documenten als statische dossiers worden opgeslagen en die altijd dynamisch worden geproduceerd.

In dit gedeelte worden de beginselen van deze richtlijn toegelicht.

Statische webserver

Een statische webserver, zoals Apache of IIS, levert statische HTML-bestanden aan bezoekers van uw website. Statische pagina's worden één keer gemaakt, dus voor elke aanvraag wordt dezelfde inhoud geleverd.

Dit proces is zeer eenvoudig en dus uiterst efficiënt. Als een bezoeker een bestand aanvraagt (bijvoorbeeld een HTML-pagina), wordt het bestand meestal rechtstreeks uit het geheugen genomen, in het slechtste geval vanaf het lokale station. Statische webservers zijn al geruime tijd beschikbaar, dus er is een breed scala aan hulpmiddelen voor beheer en beveiligingsbeheer, en ze zijn zeer goed geïntegreerd met netwerkinfrastructuur.

Servers voor inhoudsbeheer

Als u een server voor inhoudsbeheer gebruikt, zoals AEM, verwerkt een geavanceerde lay-outengine de aanvraag van een bezoeker. De engine leest inhoud uit een opslagplaats die, in combinatie met stijlen, indelingen en toegangsrechten, de inhoud omzet in een document dat is aangepast aan de behoeften en rechten van de bezoeker.

Hierdoor kunt u rijkere, dynamische inhoud maken, waardoor de flexibiliteit en functionaliteit van uw website toenemen. Voor de lay-outengine is echter meer verwerkingskracht nodig dan voor een statische server. Hierdoor kan deze installatie trager worden als veel bezoekers het systeem gebruiken.

Hoe de Verzender Caching uitvoert

De FolderFor caching van het Geheime voorgeheugen, de module van de Verzender gebruikt de capaciteit van de Webserver om statische inhoud te dienen. De verzender plaatst de cachedocumenten in de documenthoofdmap van de webserver.

OPMERKING

Als de configuratie voor HTTP-koptekstcache ontbreekt, slaat Dispatcher alleen de HTML-code van de pagina op - de HTTP-headers worden niet opgeslagen. Dit kan een probleem zijn als u verschillende coderingen binnen uw website gebruikt, omdat deze mogelijk verloren gaan. Om het Caching van de Kopbal van HTTP toe te laten, zie Vormend het Geheime voorgeheugen van de Verzender.

OPMERKING

Als u de hoofdmap van het document van uw webserver zoekt op NAS (Network-Attached Storage), neemt de prestaties af. Ook, wanneer een documentwortel die op NAS wordt gevestigd tussen veelvoudige Webservers wordt gedeeld, kunnen de intermitterende sloten voorkomen wanneer de replicatieacties worden uitgevoerd.

OPMERKING

De Dispatcher slaat het cachedocument op in een structuur die gelijk is aan de aangevraagde URL.

Er kunnen beperkingen op besturingssysteemniveau gelden voor de lengte van de bestandsnaam. Dit is bijvoorbeeld het geval als u een URL hebt met veel kiezers.

Methoden voor het in cache plaatsen

De Dispatcher beschikt over twee primaire methoden voor het bijwerken van de cacheinhoud wanneer wijzigingen in de website worden aangebracht.

  • Met Inhoud bijwerken worden de gewijzigde pagina's verwijderd, evenals bestanden die er direct aan zijn gekoppeld.
  • De auto- Invalidatie maakt automatisch die delen van het geheime voorgeheugen onbruikbaar die verouderd na een update kunnen zijn. Dit betekent dat relevante pagina's in feite als verouderd worden gemarkeerd, zonder dat er iets wordt verwijderd.

Inhoud bijwerken

In een inhoudsupdate veranderen een of meer AEM documenten. AEM verzendt een syndicatieverzoek naar de Dispatcher, die het geheime voorgeheugen dienovereenkomstig bijwerkt:

  1. Hiermee worden de gewijzigde bestanden verwijderd uit de cache.
  2. Alle bestanden die met dezelfde greep beginnen, worden uit de cache verwijderd. Als het bestand /en/index.html bijvoorbeeld wordt bijgewerkt, worden alle bestanden die beginnen met /nl/index weergegeven. worden geschrapt. Dankzij dit mechanisme kunt u cacheefficiënte sites ontwerpen, met name voor beeldnavigaties.
  3. Het touches het zogenaamde statfile; dit werkt het tijdstempel van het statusbestand bij om de datum van de laatste wijziging aan te geven.

Er zij op gewezen dat:

  • Updates van inhoud worden doorgaans gebruikt in combinatie met een ontwerpsysteem dat weet wat moet worden vervangen.
  • Bestanden die worden beïnvloed door een update van de inhoud, worden verwijderd, maar niet onmiddellijk vervangen. De volgende keer dat een dergelijk bestand wordt aangevraagd, haalt de Dispatcher het nieuwe bestand op van de AEM instantie en plaatst het in de cache, waardoor de oude inhoud wordt overschreven.
  • Gewoonlijk worden automatisch gegenereerde afbeeldingen die tekst van een pagina bevatten, opgeslagen in afbeeldingsbestanden die beginnen met dezelfde greep, zodat de koppeling bestaat voor verwijdering. U kunt bijvoorbeeld de titeltekst van de pagina mypage.html opslaan als de afbeelding mypage.titlePicture.gif in dezelfde map. Op deze manier wordt de afbeelding automatisch uit de cache verwijderd telkens wanneer de pagina wordt bijgewerkt, zodat u zeker weet dat de afbeelding altijd de huidige versie van de pagina weerspiegelt.
  • U hebt mogelijk meerdere statfiles, bijvoorbeeld één per taalmap. Als een pagina wordt bijgewerkt, zoekt AEM naar de volgende bovenliggende map die een statfile bevat en tikt op dat bestand.

Automatische ongeldigmaking

De auto-ongeldigverklaring maakt automatisch delen van het geheime voorgeheugen ongeldig - zonder fysieke het schrappen van om het even welke dossiers. Bij elke update van de inhoud wordt het zogenaamde statfile aangeraakt, zodat het tijdstempel de laatste update van de inhoud weergeeft.

Dispatcher bevat een lijst met bestanden die automatisch worden geannuleerd. Wanneer een document uit die lijst wordt gevraagd, vergelijkt de Dispatcher de datum van het cachedocument met de tijdstempel van het statusbestand:

  • als het document in de cache nieuwer is, retourneert de Dispatcher het.
  • Als deze ouder is, haalt de Dispatcher de huidige versie op van de AEM instantie.

Ook hier moeten enkele punten worden vermeld:

  • Automatische ongeldigmaking wordt doorgaans gebruikt wanneer de onderlinge relaties complex zijn, bijvoorbeeld voor HTML-pagina's. Deze pagina's bevatten koppelingen en navigatie-items, zodat deze gewoonlijk moeten worden bijgewerkt nadat de inhoud is bijgewerkt. Als u automatisch PDF- of afbeeldingsbestanden hebt gegenereerd, kunt u ook deze automatisch ongeldig maken.
  • De automatische ongeldigverklaring impliceert geen actie door de verzender bij updatetijd, behalve voor het aanraken van het statfile. Als u het bestand aanraakt, wordt de cacheinhoud echter automatisch verouderd, zonder dat de inhoud fysiek uit de cache wordt verwijderd.

Hoe de Verzender documenten terugkeert

Bepalen of een document in cache moet worden geplaatst

U kunt bepalen welke documenten de geheime voorgeheugens van de Verzender in het configuratiedossier. De verzender controleert het verzoek aan de lijst van cacheable documenten. Als het document niet in deze lijst staat, wordt het document door de Dispatcher opgevraagd bij het AEM.

De verzender vraagt altijd het document rechtstreeks van de AEM instantie in de volgende gevallen aan:

  • Als de aanvraag-URI een vraagteken "?" bevat. Dit geeft meestal een dynamische pagina aan, zoals een zoekresultaat, dat niet in de cache hoeft te worden opgeslagen.
  • De bestandsextensie ontbreekt. De webserver heeft de extensie nodig om het documenttype (het MIME-type) te bepalen.
  • De authentificatiekopbal wordt geplaatst (dit kan worden gevormd)
OPMERKING

De methoden GET of HEAD (voor de HTTP-header) kunnen door de Dispatcher in cache worden geplaatst. Zie de sectie HTTP-responsheaders in cache plaatsen voor aanvullende informatie over het in cache plaatsen van responsheaders.

Bepalen of een document in de cache is geplaatst

De Dispatcher slaat de cachebestanden op de webserver op alsof ze deel uitmaakten van een statische website. Als een gebruiker een cacheable document aanvraagt, controleert de Dispatcher of dat document bestaat in het bestandssysteem van de webserver:

  • Als het document in de cache is opgeslagen, retourneert Dispatcher het bestand.
  • Als het niet in de cache wordt opgeslagen, vraagt de Dispatcher het document van de AEM instantie.

Bepalen of een document up-to-date is

Als u wilt weten of een document up-to-date is, voert de Dispatcher twee stappen uit:

  1. Hiermee wordt gecontroleerd of het document automatisch wordt ongeldig gemaakt. Als dat niet het geval is, wordt het document als bijgewerkt beschouwd.
  2. Als het document is geconfigureerd voor automatische validatie, controleert de Dispatcher of het ouder of nieuwer is dan de laatste beschikbare wijziging. Als deze ouder is, vraagt de Dispatcher de huidige versie van de AEM instantie en vervangt de versie in het geheime voorgeheugen.
OPMERKING

Documenten zonder automatische ongeldigverklaring blijven in de cache totdat ze fysiek worden verwijderd; bijvoorbeeld door een inhoudsupdate op de website.

De voordelen van taakverdeling

Bij taakverdeling wordt de computerbelasting van de website over verschillende AEM verdeeld.

U wint:

  • verhoogde
    verwerkingscapaciteitIn de praktijk betekent dit dat de Verzender verzoeken om documenten deelt tussen verschillende AEM. Omdat elk exemplaar nu minder documenten te verwerken heeft, hebt u snellere reactietijden. Dispatcher houdt interne statistieken voor elke documentcategorie bij, zodat kan het lading schatten en de vragen efficiënt verspreiden.

  • verhoogde faalveilige
    dekkingAls de verzender geen reacties van een instantie ontvangt, zal het automatisch verzoeken aan één van andere instantie(s) aflossen. Als een instantie dus niet beschikbaar is, is het enige effect een vertraging van de site, in verhouding tot de verloren computerkracht. Alle services worden echter voortgezet.

  • u kunt ook verschillende websites beheren op dezelfde statische webserver.

OPMERKING

Terwijl de taakverdeling de belasting efficiënt spreidt, helpt het in cache plaatsen om de belasting te verminderen. Probeer daarom caching te optimaliseren en de totale lading te verminderen alvorens u opstellings lading het in evenwicht brengen. Een goede caching kan de prestaties van het taakverdelingsmechanisme verhogen of het in evenwicht brengen van de belasting onnodig maken.

LET OP

Terwijl één enkele Dispatcher gewoonlijk de capaciteit van de beschikbare Publish instanties zal kunnen verzadigen, voor sommige zeldzame toepassingen kan het zinvol zijn om de lading tussen twee instanties van de Verzender extra in evenwicht te brengen. Configuraties met meerdere verzenders moeten zorgvuldig worden overwogen, aangezien een extra verzender de belasting van de beschikbare publicatie-exemplaren verhoogt en de prestaties in de meeste toepassingen gemakkelijk kan verlagen.

Hoe de Dispatcher taakverdeling uitvoert

Prestatiestatistieken

Dispatcher houdt interne statistieken over hoe snel elke instantie van AEM documenten verwerkt. Gebaseerd op deze gegevens, schat de Verzender welke instantie de snelste reactietijd wanneer het beantwoorden van een verzoek zal verstrekken, en zo behoudt het de noodzakelijke computertijd op die instantie.

Verschillende typen aanvragen kunnen verschillende gemiddelde voltooiingstijden hebben, zodat u met de Dispatcher documentcategorieën kunt opgeven. Deze worden vervolgens meegenomen bij het berekenen van de tijdschattingen. U kunt bijvoorbeeld een onderscheid maken tussen HTML-pagina's en afbeeldingen, omdat de standaardresponstijden sterk kunnen verschillen.

Als u een uitgebreide zoekfunctie gebruikt, kunt u een nieuwe categorie voor zoekopdrachten maken. Hierdoor kan de Dispatcher zoekopdrachten verzenden naar de instantie die het snelst reageert. Hierdoor wordt voorkomen dat een tragere instantie stagneert wanneer deze meerdere "dure" zoekopdrachten ontvangt, terwijl de andere de "goedkopere" aanvragen ontvangt.

Persoonlijke inhoud (Vaste verbindingen)

De stevige verbindingen zorgen ervoor dat de documenten voor één gebruiker allen op de zelfde instantie van AEM samengesteld zijn. Dit is belangrijk als u gepersonaliseerde pagina's en zittingsgegevens gebruikt. De gegevens worden opgeslagen op de instantie, zodat de verdere verzoeken van de zelfde gebruiker aan die instantie moeten terugkeren of het gegeven wordt verloren.

Omdat de kleverige verbindingen de capaciteit van de Dispatcher beperken om de verzoeken te optimaliseren, zou u hen slechts moeten gebruiken wanneer nodig. U kunt de map opgeven die de "plakke" documenten bevat, zodat alle documenten in die map op hetzelfde exemplaar voor elke gebruiker worden samengesteld.

OPMERKING

Voor de meeste pagina's die kleverige verbindingen gebruiken, moet u caching uitschakelen - anders ziet de pagina het zelfde aan alle gebruikers, ongeacht de zittingsinhoud.

Voor weinig toepassingen, kan het mogelijk zijn om zowel kleverige verbindingen als caching te gebruiken; bijvoorbeeld als u een formulier weergeeft waarin gegevens naar de sessie worden geschreven.

Meerdere verzendingen gebruiken

In complexe instellingen kunt u meerdere verzenders gebruiken. U kunt bijvoorbeeld het volgende gebruiken:

  • één verzender om een website op het Intranet te publiceren
  • een tweede verzender, onder een ander adres en met verschillende beveiligingsinstellingen, om dezelfde inhoud op internet te publiceren.

In een dergelijk geval, zorg ervoor dat elk verzoek door slechts één Dispatcher gaat. Een Dispatcher behandelt geen verzoeken die afkomstig zijn van een andere Dispatcher. Zorg er daarom voor dat beide verzenders de AEM website rechtstreeks openen.

Dispatcher gebruiken met een CDN

Een CDN (Content Delivery Network), zoals Akamai Edge Delivery of Amazon Cloud Front, levert inhoud op een locatie die dicht bij de eindgebruiker ligt. Door

  • zorgt voor snellere responstijden voor eindgebruikers
  • start het laden van uw servers

Als de infrastructuurcomponent van HTTP, werkt een CDN heel erg als Dispatcher: wanneer een knoop CDN een verzoek ontvangt, dient het het verzoek van zijn geheime voorgeheugen indien mogelijk (het middel is beschikbaar in het geheime voorgeheugen en is geldig). Anders, bereikt het uit aan de volgende dichtstbijzijnde server om het middel terug te winnen en het voor verdere verzoeken in het voorgeheugen onder te brengen indien aangewezen.

De "eerstvolgende dichtstbijzijnde server" is afhankelijk van uw specifieke installatie. In een Akamai-configuratie kan het verzoek bijvoorbeeld het volgende pad volgen:

  • Het Edge-knooppunt Akamai
  • De laag Akamai Midgres
  • Uw firewall
  • Uw taakverdelingsmechanisme
  • Dispatcher
  • AEM

In de meeste gevallen is Dispatcher de volgende server die het document vanuit een cache kan aanleveren en de antwoordheaders kan beïnvloeden die aan de CDN-server worden geretourneerd.

CDN-cache beheren

Er zijn een aantal manieren om te controleren hoe lang een CDN een middel zal in het voorgeheugen onderbrengen alvorens het re-fetches van Dispatcher is.

  1. Expliciete configuratie
    Vorm, hoe lang de bijzondere middelen in het geheime voorgeheugen van CDN, afhankelijk van mime type, uitbreiding, verzoektype, enz. worden gehouden.

  2. Verlopen- en cachebeheerkoppen
    De meeste CDN's respecteren Expires: en Cache-Control: HTTP-headers als deze worden verzonden door de upstream-server. Dit kan bijvoorbeeld worden bereikt door de mod_validate Apache Module te gebruiken.

  3. Handmatige validatie
    CDNs staat middelen toe om uit het geheime voorgeheugen door Webinterfaces worden verwijderd.

  4. Op API gebaseerde validatie
    De meeste CDN's bieden ook een REST- en/of SOAP-API waarmee bronnen uit de cache kunnen worden verwijderd.

In een typisch AEM, configuratie door uitbreiding en/of weg, die door punten 1 en 2 hierboven kan worden bereikt, biedt mogelijkheden om redelijke caching periodes voor vaak gebruikte middelen te plaatsen die niet vaak veranderen, zoals ontwerpbeelden en cliëntbibliotheken. Wanneer de nieuwe versies worden opgesteld, typisch wordt een handongeldigverklaring vereist.

Als deze benadering wordt gebruikt om beheerde inhoud in het voorgeheugen onder te brengen, impliceert het dat de inhoudsveranderingen slechts aan eind zichtbaar zijn - gebruikers zodra de gevormde caching periode is verlopen en het document opnieuw van Dispatcher wordt opgehaald.

Voor fijnere controle, staat API gebaseerde ongeldigverklaring u toe om het geheime voorgeheugen van een CDN ongeldig te maken aangezien het geheime voorgeheugen van de Verzender ongeldig wordt gemaakt. Gebaseerd op CDNs API, kunt u uw eigen ContentBuilder en TransportHandler (als API niet REST-Gebaseerd is) uitvoeren en opstelling een Agent van de Replicatie die deze zal gebruiken om het geheime voorgeheugen van CDN ongeldig te maken.

OPMERKING

Een Dispatcher gebruiken met een Auteur-server

LET OP

Als u AEM met Touch UI gebruikt, zou u not de inhoud van de auteursinstantie van het geheime voorgeheugen moeten. Als caching voor de auteursinstantie werd toegelaten, moet u het onbruikbaar maken en de inhoud van de geheim voorgeheugenfolder schrappen. Als u caching wilt uitschakelen, moet u het author_dispatcher.any-bestand bewerken en de eigenschap /rule van de sectie /cache als volgt wijzigen:

/rules
{
/0000
{ /type "deny" /glob "*"}
}

Een Dispatcher kan vóór een auteurinstantie worden gebruikt om auteursprestaties te verbeteren. Ga als volgt te werk om een ontwerpDispatcher te configureren:

  1. Installeer een Dispatcher in een Webserver (dit zou Apache of IIS Webserver kunnen zijn, zie Installerend Dispatcher).

  2. Het is verstandig om de zojuist geïnstalleerde Dispatcher te testen op een werkende AEM publicatieexemplaar om te controleren of de juiste basislijn is geïnstalleerd.

  3. Zorg nu dat de Dispatcher via TCP/IP verbinding kan maken met uw auteurinstantie.

  4. Vervang het bestand sample dispatcher.any door de naam auteur_dispatcher.any in het bestand Dispatcher download.

  5. Open author_dispatcher.any in een tekstredacteur en breng de volgende veranderingen aan:

    1. Wijzig /hostname en /port van de sectie /renders om naar de auteurinstantie te verwijzen.
    2. Wijzig /docroot van de sectie /cache om naar een cachemap te verwijzen. Zie de bovenstaande waarschuwing voor het geval dat u AEM met Touch UI gebruikt.
    3. Sla de wijzigingen op.
  6. Verwijder alle bestaande bestanden in de map /cache > /docroot die u hierboven hebt geconfigureerd.

  7. Start de webserver opnieuw.

OPMERKING

Houd er rekening mee dat wanneer u met de meegeleverde author_dispatcher.any-configuratie een pakket met CQ5-functies, hotfix of toepassingscode installeert dat van invloed is op inhoud onder /libs of /apps, u de bestanden in de cache onder deze mappen in de cache moet verwijderen om ervoor te zorgen dat de nieuwe bestanden worden opgehaald en niet de oude bestanden in de cache.

LET OP

Als u de eerder gevormde auteur dispatcher hebt gebruikt en dispatcher flushing agent dan gelieve te doen het volgende:

  1. Verwijder of maak de flushing agent van de auteur op uw AEM auteursinstantie onbruikbaar.
  2. Voer de configuratie van de auteur-dispatcher opnieuw uit door de bovenstaande nieuwe instructies te volgen.

Op deze pagina