Thymeleaf Template Caching vs. Memory Overhead for Low-Traffic JVM Workloads

Question

In a low-traffic Java application using Thymeleaf, there is a trade-off between CPU utilization and JVM heap consumption regarding the spring.thymeleaf.cache configuration.

Enabling the template cache reduces the CPU overhead by storing parsed TemplateModel objects, but it increases the memory footprint. Conversely, disabling the cache forces the engine to re-parse HTML files on every request, which consumes more CPU cycles but minimizes heap usage.

For environments where memory is the primary constraint and request volume is minimal, it is unclear if the CPU cost of constant re-parsing outweighs the benefit of a smaller memory footprint.

Does disabling the template cache in a low-traffic production environment introduce unacceptable latency spikes?
  At what threshold of template complexity or request volume does the memory overhead of the cache become more efficient than the CPU cost of re-parsing?

Tasadduq Burney · Answer

Direct answer
For a low-traffic production JVM workload, disabling spring.thymeleaf.cache does not reliably produce unacceptable latency spikes for very small, simple templates, but it does introduce per-request parse and I/O cost that becomes noticeable with template complexity or request bursts. The memory overhead of the cache is typically small and proportional to the number of unique templates, not request volume.
Confirmed facts: With spring.thymeleaf.cache=true Thymeleaf 3.x stores parsed TemplateModel structures in memory after first load and reuses them. With spring.thymeleaf.cache=false the engine resolves, reads and parses the template source on every request.
Likely explanation
Memory overhead is dominated by the set of distinct templates, fragments and layouts loaded. In low-traffic apps this is usually negligible compared to JVM baseline. CPU cost of re-parsing is low for trivial pages and rises with nesting, fragments, conditionals and expressions. A burst of concurrent requests can amplify that cost because parsing is CPU bound and involves file I/O.
When caching pays off

Complex templates with many fragments and expressions.
Any production traffic pattern with bursts, even if average RPS is low.
Memory is not the hard constraint.

When cache off can be acceptable

Very few unique templates, each small and simple.
Strict memory cap and consistently single-digit requests per minute with no bursts.
Latency SLOs allow occasional tens to hundreds of milliseconds of extra TTFB.

Verification steps for this case

Measure heap with cache on vs off using JVisualVM or JConsole after warm-up. Compare old gen after steady state.
Measure TTFB for a representative complex page under a small load with Apache Benchmark or JMeter, first with cache on then off.
Enable Thymeleaf debug logging and check template loading events when cache is off.

Missing diagnostic detail that changes the recommendation: the number of unique templates and their average size/complexity. That determines the actual heap delta and the parse cost.

Thymeleaf Template Caching vs. Memory Overhead for Low-Traffic JVM Workloads

1 answer

Direct answer

Likely explanation

When caching pays off

When cache off can be acceptable

Verification steps for this case

Your perspective belongs here.

0 question comments