AEM Site users report that the web content pages render very slowly. An Architect notices that the CPU usages of the AEM Publish instances are spiking and reviews the following entry in the log…

Question

Options

• AReview and optimize the Dispatcher cache configuration
• BAdd additional AEM instances to the Publish Farm
• CCreate a cron job that will delete the dispatcher cache on a regular basis
• DAdd additional dispatcher servers

• A
  19% (12)
• B
  5% (3)
• C
  66% (41)
• D
  10% (6)

Explanation

Important note: The marked answer (C) appears to be incorrect. The correct answer is A.

Option A is correct because a 47.94% cache hit ratio means roughly half of all requests are bypassing the dispatcher and hitting the AEM Publish server directly - the root cause of the CPU spikes. Reviewing and optimizing the dispatcher cache configuration (e.g., expanding cacheable content rules, fixing cache-control headers, or correcting flush agent behavior) directly addresses both the low ratio and the downstream CPU load.

Why the distractors are wrong:

• C (marked correct - actually wrong): Scheduling a cron job to delete the dispatcher cache would lower the hit ratio further, forcing even more requests to reach the Publish instances. This is the opposite of what's needed.
• B: Adding more Publish instances distributes the load but doesn't fix the cache miss problem - the same proportion of requests would still bypass the cache, just spread across more servers.
• D: More dispatchers increase throughput capacity but don't improve the cache hit ratio; the underlying misconfiguration remains.

Memory tip: Think of the dispatcher cache as a shield protecting AEM Publish. A low hit ratio means the shield has holes - you fix holes by patching the configuration (A), not by scheduling demolitions (C). When you see CPU spikes + a low cache hit ratio in the same scenario, the answer is always about fixing what's being cached, not adding hardware.

No community discussion yet for this question.