anchor.diff:  execution on a per shard level. Depending on the data in an index, a frozen index may execute searches in the seconds to minutes range, when the same index in an unfrozen state may execute the same search request in milliseconds.
   --
   
  -== Best Practices
  +[role="xpack"]
  +[testenv="basic"]
  +[[best_practices]]
  +== Best practices
   
   Since frozen indices provide a much higher disk to heap ratio at the expense of search latency, it is advisable to allocate frozen indices to
   dedicated nodes to prevent searches on frozen indices influencing traffic on low latency nodes. There is significant overhead in loading
  
positive.code: significant overhead associated with this pre-filter phase.
  ================================
  
  == Monitoring frozen indices
  
  Frozen indices are ordinary indices that use search throttling and a memory efficient shard implementation. For API's like the
  `<<cat-indices>>` frozen indicies may identified by an index's `search.throttled` property (`sth`).
  
  [source,js]
  --------------------------------------------------
  
negative.code: // CONSOLE
  // TEST[setup:twitter]
  
  [role="xpack"]
  [testenv="basic"]
  [[searching_a_frozen_index]]
  == Searching a frozen index
  
  Frozen indices are throttled in order to limit memory consumptions per node. The number of concurrently loaded frozen indices per node is
  limited by the number of threads in the <<search-throttled,search_throttled>> threadpool,  which is `1` by default. 
  Search requests will not be executed against frozen indices by default, even if a frozen index is named explicitly. This is 
  to prevent accidental slowdowns by targeting a frozen index by mistake. To include frozen indices a search request must be executed with
  the query parameter `ignore_throttled=false`.
  