# Caches in Vespa

## Container result cache

This cache is caching first phase (hits) and second phase (summary) data and is enabled on a per content cluster basis by:

• Cache time to live (TTL) is controlled by visibility-delay on a per content cluster basis
• Cache size is controlled by defining a type local provider. Default size is 1MB
This cache saves both CPU, network and IO as it caches both first phase result data and second phase summary data. Note that the container jvm heap size might be adjusted as well for optimal performance. During run-time, control whether the cache should be used or not using nocache and nocachewrite.

## Content node summary cache

The summary cache caches summary requests and is enabled by proton tuning configuration. When enabling a proton summary cache, one should also change the way proton reads summary data from mmap to directio as done below. The summary cache saves IO and cpu spent on decompressing of chunked blocks (default 64KB) of summary data. Note that the summary cache is shared across multiple document types.

<content id="music" version="1.0">
<search>
<visibility-delay>30.0</visibility-delay>
</search>
<engine>
<proton>
<tuning>
<searchnode>
<summary>
<io>
</io>
<store>
<cache>
<maxsize>1073741824</maxsize><!--1GB -->
</cache>
</store>
</summary>
</searchnode>
</tuning>
</proton>
</engine>
....
</content>

This example configures a 20 MB cache with TTL of 30 seconds and a summary cache of 1GB:
<container id="container" version="1.0">
<search>
<provider id="music" type="local" cachesize="20M"  cluster="music"/>
</search>
...
</container>

<content id="music" version="1.0">
<search>
<visibility-delay>30.0</visibility-delay>
</search>
<engine>
<proton>
<tuning>
<searchnode>
<summary>
<io>
</io>
<store>
<cache>
<maxsize>1073741824</maxsize><!--1GB -->
</cache>
</store>
</summary>
</searchnode>
</tuning>
</proton>
</engine>
....
</content>


## Protocol phases caches

ranking.queryCache and groupingSessionCache described in the search api reference are only caching data in between phases for a given a query, hence other queries do not get any benefits, but these caches saves container - content node(s) round-trips for a given query.