为了继续我对这个答案的评论，我有以下设置：
使用read-heavy es-index（它也会获取索引请求，但比率为25:1）和使用1秒的刷新间隔，并尝试通过显式设置此参数来提高查询性能，以便缓存搜索查询 hits 但没有看到任何性能提升。
另外，我看到hits.total也在变化，因为我的索引也得到了写请求，我觉得这可能是原因，因为碎片正在刷新，缓存正在失效。
请确认我的假设是否正确，是否有任何方法可以使用es中的各种缓存设置来提高性能？
注意：我使用了中提到的监视缓存部分https://opensourceconnections.com/blog/2017/07/10/caching_in_elasticsearch/ 下面是我拿到的订单。
url:- http：//：9200/\u cat/nodes？v&h=querycachememory，querycacheevictions，requestcachememory，requestcachehitcount，requestcachemisscont，flushtottal，flushtottaltime
queryCacheMemory queryCacheEvictions flushTotal flushTotalTime
0b 0 353204 1.9h
0b 0 0 0s
0b 0 464814 2.2h
0b 0 292127 1.6h
0b 0 409013 2.1h
0b 0 394303 2h
0b 0 369545 2.1h
0b 0 0 0s
0b 0 0 0s请注意，即使在 requestCacheMemory , hit 以及 miss 算一下，它不包括在o/p中
2条答案
按热度按时间zxlwwiss1#
查询字符串参数
request_cache=true仅当请求缓存在索引级别被禁用时才有用，但由于它在默认情况下处于启用状态，因此指定该参数无效，除非您在索引级别显式禁用了缓存。此外，您确定总是发送完全相同的json查询吗？我之所以这么问是因为缓存键是在json查询中创建的，所以即使查询中有一个字符发生了变化，键也不会相同。
最后，您可以通过 checkout 这个端点来检查请求缓存是如何命中还是丢失的
什么在增加？这个
hit_count或者miss_count?qqrboqgw2#
另外，为什么刷新间隔保持在1秒？尝试30-60秒，这样可以降低负载，也不会创建那么多要合并的段-我最近正在研究合并，我认为它会使某些类型的缓存失效，尽管可能不是一般的查询缓存。