Grundlegendes zu Cloud Service-Inhaltsanfragen
Einführung introduction
Inhaltsanfragen umfassen an AEM Sites gesendete Anfragen. Diese Anfragen können über Edge Delivery Services oder kundenseitig bereitgestellte Caching-Systeme wie ein Content Delivery Network (CDN) weitergeleitet werden. Diese Anfragen liefern strukturierte Daten im HTML- oder JSON-Format und unterstützen Seitenansichten (z. B. Seiten und Experience Fragments) oder JSON-Rückgaben über APIs (Headless).
Das System zählt die Inhaltsanfragen, wenn eine Benutzerin oder ein Benutzer eine Seite mithilfe von HTML oder JSON anzeigt. Es erfasst die Anfrage dort, wo das erste Caching-System sie erhält. Bestimmte HTTP-Anfragen werden beim Zählen von Inhaltsanfragen ein- bzw. ausgeschlossen. Siehe die vollständige Liste der eingeschlossenen HTTP-Inhaltsanfragen und der ausgeschlossenen HTTP-Inhaltsanfragen.
Über Cloud Service-Inhaltsanfragen understanding-cloud-service-content-requests
Eine Seitenanfrage bezieht sich auf eine HTTP-Anfrage, die strukturierte Kerninhalte (z. B. HTML oder JSON) zum Rendern der Hauptseite abruft. Dazu gehören keine Anfragen für Assets wie Bilder oder Skripte.
Für Kundinnen und Kunden, die das vorkonfigurierte CDN verwenden, zählt AEM as a Cloud Service Inhaltsanfragen so, wie sie Server-seitig erfasst werden. Diese Messung erfolgt automatisch und ist nicht auf Client-seitiges Analyse-Tracking angewiesen.
AEM (Adobe Experience Manager) as a Cloud Service identifiziert Inhaltsanfragen anhand der von der AEM-Instanz generierten und im CDN empfangenen Antworttypen. Insbesondere werden Anfragen gezählt, die HTML (text/html) oder JSON (application/json) zurückgeben. Diese Formate liefern in der Regel primäre Seiteninhalte zum herkömmlichen Rendern von Sites oder zur Headless-Bereitstellung.
Anfragen für statische Assets wie JavaScript-Dateien, CSS-Stylesheets und Bilder werden nicht als Inhaltsanfragen gezählt.
Inhaltsanfragen werden unabhängig davon gemessen, ob die Antwort vom CDN-Cache bereitgestellt oder an die ursprüngliche AEM-Umgebung weitergeleitet wurde.
Abweichungen von Cloud Service-Inhaltsanfragen content-requests-variances
Inhaltsanfragen können Abweichungen von den Analyseberichts-Tools einer Organisation aufweisen, die in der folgenden Tabelle zusammengefasst sind. Vermeiden Sie im Allgemeinen die Verwendung von Analyse-Tools, die auf eine Client-seitige Instrumentation angewiesen sind, um die Anzahl der Inhaltsanfragen für eine Site zu melden. Bei diesen Tools wird häufig ein großer Teil des Traffics verpasst, da ihre Aktivierung von einer Benutzerzustimmung abhängt. Analyse-Tools, die Daten Server-seitig in Protokolldateien sammeln, oder CDN-Berichte für Kundinnen und Kunden, die zusätzlich zu AEM as a Cloud Service ihr eigenes CDN hinzufügen, bieten bessere Zählungen.
Informationen zum Anzeigen und Nachverfolgen der Nutzung von Inhaltsanfragen anhand Ihres Lizenz-Limits finden Sie im Lizenz-Dashboard.
Regeln für die Server-seitige Sammlung serverside-collection
AEM as a Cloud Service wendet Server-seitige Sammlungsregeln an, um Inhaltsanfragen zu zählen. Diese Regeln schließen bekannte Bots (wie Suchmaschinen-Crawler) und eine Reihe von Überwachungs-Services aus, die die Website regelmäßig pingen. Anderer synthetischer oder Monitoring-artiger Traffic, der nicht auf dieser Ausschlussliste steht, wird als abrechnungsfähige Inhaltsanfrage gezählt.
In der folgenden Tabelle sind die Typen der eingeschlossenen und ausgeschlossenen Inhaltsanfragen mit jeweils kurzen Beschreibungen aufgeführt.
Arten von enthaltenen Inhaltsanfragen included-content-requests
HTTP-Code 206: Diese Anfragen liefern nur einen Teil des gesamten Inhalts, z. B. ein Video oder ein großes Bild. Partielle Inhaltsanfragen werden eingeschlossen, wenn sie einen Teil einer HTML- oder JSON-Antwort bereitstellen, die beim Rendern des Seiteninhalts verwendet wird.
• Amazon CloudFront
• Apache Http Client
• Asynchronous HTTP Client
• Axios
• Azureus
• Curl
• GitHub Node Fetch
• Guzzle
• Go-http-client
• Headless Chrome
• Java™ Client
• Jersey
• Node Oembed
• okhttp
• Python Requests
• Reactor Netty
• Wget
• WinHTTP
• Fast HTTP
• GitHub Node Fetch
• Reactor Netty
Siehe Typen von ausgeschlossenen Inhaltsanfragen.
Beispiele dafür sind:
•
Amazon-Route53-Health-Check-Service• EyeMonIT_bot_version_0.1_(https://eyemonit.com/)
• Investis-Site24x7
• Mozilla/5.0+(compatible; UptimeRobot/2.0; https://uptimerobot.com/)
• ThousandEyes-Dragonfly-x1
• OmtrBot/1.0
• WebMon/2.0.0
<link rel="prefetch">-Anfragen<link rel="prefetch">), zählt das System diese Server-seitigen Anfragen. Denken Sie daran: Dadurch kann der Traffic zunehmen, abhängig davon, wie viele dieser Seiten vorab abgerufen werden.Siehe auch Lizenz-Dashboard.
Typen von ausgeschlossenen Inhaltsanfragen excluded-content-request
/libs/*/system/probes/healthBeispiele:
• AddSearchBot
• AhrefsBot
• Applebot
• Ask Jeeves Corporate Spider
• Bingbot
• BingPreview
• BLEXBot
• BuiltWith
• Bytespider
• CrawlerKengo
• Facebookexternalhit
• Google AdsBot
• Google AdsBot Mobile
• Googlebot
• Googlebot Mobile
• lmspider
• LucidWorks
•
MJ12bot• SemrushBot
• SiteImprove
• StashBot
• StatusCake
• YandexBot
• ContentKing
• Claudebot
/api/graphql. Um eine doppelte Zählung zu vermeiden, sind sie für den Cloud-Service nicht abrechenbar.manifest.json/etc.clientlibs/*/manifest.json nicht zählenfavicon.ico/content/experience-fragments/...) von Seiten, die auf derselben Domain gehostet werden (wie durch den Referrer-Header identifiziert, der mit dem Anfrage-Host übereinstimmt).Beispiel: Eine Homepage auf
aem.customer.com, die ein XF für ein Banner oder eine Karte aus derselben Domain abruft.・ URL stimmt überein mit /content/experience-fragments/…
・ Referrer-Domain stimmt überein mit
request_x_forwarded_hostHinweis: Wenn der Experience Fragment-Pfad angepasst wird (z. B. mithilfe von
/XFrags/... oder einem Pfad außerhalb von /content/experience-fragments/), wird die Anfrage nicht ausgeschlossen und kann gezählt werden, selbst wenn es sich um dieselbe Domain handelt. Es wird empfohlen, die standardmäßige XF-Pfadstruktur von Adobe zu verwenden, um sicherzustellen, dass die Ausschlusslogik korrekt angewendet wird.Verwalten von Inhaltsanfragen managing-content-requests
Wie im obigen Abschnitt Varianzen von Cloud Service-Inhaltsanfragen erwähnt, können Inhaltsanfragen aus mehreren Gründen höher als erwartet sein, wobei ein gemeinsamer Thread im CDN-Traffic auftritt. Als AEM-Kunde können Sie Ihre Inhaltsanfragen so überwachen und verwalten, dass sie in Ihr Lizenzbudget passen. Die Verwaltung von Inhaltsanfragen ist im Allgemeinen eine Kombination aus Implementierungstechniken Traffic-Filterregeln.
Implementierungstechniken für die Verwaltung von Inhaltsanfragen implementation-techniques-to-manage-crs
- Stellen Sie sicher, dass alle Antworten vom Typ „Seite nicht gefunden“ mit dem HTTP-Status 404 zugestellt werden. Wenn sie mit dem Status 200 zurückgegeben werden, werden sie für Inhaltsanfragen gezählt.
- Leiten Sie Konsistenzprüfungs- oder Überwachungs-Tools an die URL unter /system/probes/health oder verwenden Sie die HEAD-Methode anstelle von GET, um aufkommende Inhaltsanfragen zu vermeiden.
- Schaffen Sie ein ausgewogenes Verhältnis zwischen Ihren Anforderungen an die Aktualität von Inhalten und den AEM-Lizenzkosten für jeden benutzerdefinierten Such-Crawler, den Sie in Ihre Site integriert haben. Ein übermäßig aggressiver Crawler kann viele Inhaltsanfragen verarbeiten.
- Behandeln Sie alle Weiterleitungen als Server-seitig (Status 301 oder 302) und nicht Client-seitig (Status 200 mit JavaScript-Weiterleitung), um zwei separate Inhaltsanfragen zu vermeiden.
- Kombinieren oder reduzieren Sie API-Aufrufe, bei denen es sich um JSON-Antworten von AEM handelt, die geladen werden können, um die Seite zu rendern.
Traffic-Filterregeln zur Verwaltung von Inhaltsanfragen traffic-filter-rules-to-manage-crs
- Ein gängiges Bot-Muster besteht darin, einen leeren Benutzeragenten zu verwenden. Sie müssen Ihre Implementierung und Traffic-Muster überprüfen, um festzustellen, ob der leere Benutzeragent nützlich ist oder nicht. Wenn Sie diesen Traffic blockieren möchten, wird folgende (Syntax empfohlen:
trafficFilters:
rules:
- name: block-missing-user-agent
when:
anyOf:
- { reqHeader: user-agent, exists: false }
- { reqHeader: user-agent, equals: '' }
action: block
- Einige Bots haben eine Seite sehr schwer an einem Tag und verschwinden am nächsten Tag. Dies kann jeden Versuch vereiteln, eine bestimmte IP-Adresse oder einen Benutzeragenten zu blockieren. Ein generischer Ansatz besteht in der Einführung einer Regel für Limits. Sehen Sie sich die Beispiele an und erstellen Sie eine Regel, die Ihrer Toleranz für eine schnelle Anfragerate entspricht. Überprüfen Sie die Bedingungsstruktur-Syntax für alle Ausnahmen, die Sie möglicherweise zulassen möchten, um eine allgemeine Ratenbeschränkung zuzulassen.