Publish Instance Performance Tuning

A slow AEM site is rarely fixed by one clever setting. It's usually a handful of ordinary problems: a low cache hit ratio, a query that scans too much, a component doing work on every request, or oversized images. This post gives you a method for finding the real bottleneck, and a checklist of the fixes that matter most, for both AEM 6.5 and AEM as a Cloud Service.

Start with Measurement, Not Guesses

Before changing anything, establish a baseline:

• Response times for key pages, measured from outside (browser developer tools, synthetic monitoring) and inside (request logs)
• Dispatcher/CDN cache hit ratio, because every hit is a request Publish never serves
• Publish load: CPU, memory, thread usage and request rate
• Slow requests: which URLs take the longest, and how often they're requested

Change one thing at a time, and re-measure. Without a baseline you can't tell whether a change helped, hurt or did nothing.

The Performance Layers

Think of a request passing through layers, from cheapest to most expensive:

1. Browser cache: free
2. CDN: very cheap
3. Dispatcher cache: cheap
4. Publish rendering: expensive
5. Repository and queries: the most expensive part of Publish rendering

The strategy follows directly: push as many requests as possible to the earlier layers, and make whatever reaches Publish cheap.

Layer 1: Maximize Cache Hits

This delivers the largest improvements, so do it first.

• Check what isn't cached and why. Common reasons are query strings, missing file extensions, no-cache headers, authenticated requests and cache rules that deny the path (see Part 1)
• Use an allow-list for ignorable query parameters such as utm_*, so marketing links still hit the cache
• Set TTLs with Cache-Control headers so content that changes without activation still expires correctly, and so the CDN can cache effectively
• Tune /statfileslevel so one activation doesn't flush more than it needs to
• Keep personalization out of cached HTML. Load user-specific fragments client-side, or use Sling Dynamic Include so the page can be cached while small dynamic pieces are fetched separately
• Use versioned clientlibs and long TTLs for static assets

A site whose pages are mostly served from Dispatcher and the CDN may need only a modest Publish tier, whereas one with a poor hit ratio can overwhelm Publish regardless of tuning.

Layer 2: Make Publish Rendering Cheap

When a request does reach Publish, the cost is mostly your code.

Keep Sling Models Light

• Do only what the page needs. Don't compute things you won't render
• Avoid repository queries inside components that render on every request
• Don't call external services synchronously during rendering. If you must, add timeouts and caching
• Reuse results within a request, rather than recomputing in several places
• Use @Optional and lazy getters for expensive values that are only sometimes used

Cache Expensive Results

If a component needs data that's costly to compute and doesn't change often, cache it in an OSGi service with a sensible expiry, and invalidate it deliberately. Be careful that the cache doesn't grow without limit.

Avoid Resource Leaks

A classic cause of gradual slowdown and memory pressure is unclosed resource resolvers:

@Reference
private ResourceResolverFactory resolverFactory;

public String readTitle(String path) {
    Map<String, Object> auth = Map.of(ResourceResolverFactory.SUBSERVICE, "my-service");
    try (ResourceResolver resolver = resolverFactory.getServiceResourceResolver(auth)) {
        Resource resource = resolver.getResource(path);
        return resource != null ? resource.getValueMap().get("jcr:title", String.class) : null;
    } catch (LoginException e) {
        return null;
    }
}

Always open service resolvers in a try-with-resources block (or close them in finally), and use service users mapped through a subservice rather than shared admin sessions.

Layer 3: Queries and Indexes

Slow queries are the most frequent cause of slow Publish pages and heavy CPU.

How to Spot Them

• Query Performance (under Tools → Operations → Diagnosis on 6.5) lists recent and slow queries and lets you explain a query to see which index it uses
• Look for traversal warnings in the logs. A query that traverses the repository, rather than using an index, gets slower as content grows
• Check the Index Manager for the indexes in play

How to Fix Them

• Use an index. Add or extend an Oak index definition so the query's properties and node types are covered. On Cloud Service, ship index definitions as code
• Narrow the query. Restrict it by path (/content/mysite/...), node type and properties, rather than searching the whole repository
• Limit results. Add limits and paging
• Avoid wildcards at the start of a value (LIKE '%term'), which can't use indexes effectively
• Don't query at render time at all if you can avoid it. Use a pre-computed property, a tag-based navigation structure or a cache

An example of a well-scoped query:

SELECT * FROM [cq:Page] AS p
WHERE ISDESCENDANTNODE(p, '/content/mysite/en/blog')
AND p.[jcr:content/cq:tags] = 'mysite:topic/aem'

Run it through the explain tool, and confirm it uses an index and not traversal.

Layer 4: Frontend Weight

Backend tuning can't rescue a heavy page.

• Images: serve appropriately sized renditions, modern formats (such as WebP) and responsive srcset attributes. The Core Components Image component supports this
• Lazy-load images below the fold
• Clientlibs: minify and compress, combine where sensible, and load non-critical JavaScript with defer or async
• Compression: enable gzip or brotli at the CDN or web server
• Fewer third-party scripts, which are often the biggest slowdown after your own code

Platform-Specific Tuning

AEM 6.5 / AMS (you own the infrastructure)

• JVM: size the heap to the workload, choose a suitable garbage collector and monitor GC pauses rather than guessing
• Repository maintenance: run revision cleanup (online compaction) on a schedule so the segment store doesn't bloat, and plan data store garbage collection if you use a file or cloud data store
• Index maintenance: reindex only when needed, outside peak times
• Instances: add Publish instances behind the load balancer to raise capacity, and keep them identical
• Logging: keep log levels at INFO or above in production, since debug logging slows things down
• Request timing: the request log, and tools such as rlog, show how long each request took

AEM as a Cloud Service

• Scaling: Publish scales automatically with load, so your priority is making each request cheap, because inefficient code simply costs more compute
• No JVM or OS tuning: that's Adobe's side of the line
• Code quality gates: pay attention to the Cloud Manager performance and quality checks, which flag some problems before they reach production
• Dispatcher and CDN: your configuration is the main lever, so test it on Dev and Stage
• Observability: forward logs to your logging platform and watch response times, errors and cache behavior
• Load testing: run it against Stage and not Production, and check Adobe's current policy and guidance for testing Cloud Service environments before you start

Common Symptoms and Likely Causes

A Tuning Checklist

1. Measure the baseline (response times, hit ratio, load)
2. Raise the cache hit ratio (rules, params, TTLs, /statfileslevel)
3. Move personalization out of cached HTML
4. Find and fix slow queries with Query Performance and indexes
5. Remove work from rendering (queries, remote calls, repeated computation)
6. Fix resolver leaks and unbounded in-memory caches
7. Reduce frontend weight (images, clientlibs, compression, third parties)
8. On 6.5, review JVM, compaction and instance count
9. Re-measure, and keep the results so you know what worked
10. Load-test before major launches, in a non-production environment

Series Wrap-Up

That completes AEM Architecture & Operations. You should now be able to:

• Explain how the Dispatcher cache works and configure invalidation, including /statfileslevel, TTLs and query parameter rules
• Troubleshoot replication on both 6.5 (agents) and Cloud Service (content distribution)
• Describe the differences between AEM 6.5 and AEM as a Cloud Service, and plan a migration
• Find and fix performance bottlenecks on Publish, from caching to queries to frontend weight

The final series, Advanced AEM & Career, covers headless AEM with GraphQL, Edge Delivery Services, architect interview preparation and migration lessons.