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 the visibility-delay setting on a per content cluster basis. Default is 0 seconds.
  • 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 you can control whether the cache should be used or not by the nocache and nocachewrite parameters.

Content Node Summary Cache

The summary cache caches summary requests and is enabled by proton tuning configuration. When enabling a proton summary cache you 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>                      
                <read>directio</read>           
              </io>                     
              <store>                   
                <cache>
                  <maxsize>1073741824</maxsize><!--1GB -->
                </cache>                        
              </store>
            </summary>
          </searchnode>
        </tuning>
      </proton>
    </engine>
  ....
  </content>

Complete Example

Example below will configure a 20 MB cache with TTL of max 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>                      
                <read>directio</read>           
              </io>                     
              <store>                   
                <cache>
                  <maxsize>1073741824</maxsize><!--1GB -->
                </cache>                        
              </store>
            </summary>
          </searchnode>
        </tuning>
      </proton>
    </engine>
  ....
  </content>

Protocol phases caches

The 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 does not get any benefits but these caches saves container - content node(s) round-trips for a given query.