Aha, I find it under *cluster* stats, under the "indices" key: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-stats.html That's unexpected.
So next question: is there a way to get that information per-node? Otis, is the cluster stats info what you're charting there? Or do you get that from somewhere else? (The chart I see has some oddities, btw: count and evictions seem to sit on 0, which is unexpected while the size metric rises and falls.) Cheers, Tikitu On Tuesday, 28 January 2014 16:41:21 UTC+13, Otis Gospodnetic wrote: > > Hi Tikitu, > > Re 1. and filer cache size + eviction monitoring, here is an example: > https://apps.sematext.com/spm-reports/s/b5g0cSyGm0 > > Otis > -- > Performance Monitoring * Log Analytics * Search Analytics > Solr & Elasticsearch Support * http://sematext.com/ > > > On Monday, January 27, 2014 5:03:47 PM UTC-5, Tikitu de Jager wrote: >> >> Hi folks, >> >> I'm optimising our queries based on the advice in Zachary Tong's >> presentation: >> https://speakerdeck.com/polyfractal/elasticsearch-query-optimization >> So far just switching all our query elements to filters has given a 6x >> speedup on a monster query (65Kchars of compact json), which is very >> encouraging :-) >> >> All our queries are auto-generated from our own query syntax, though, so >> if we switch to filters it's gonna have to be pretty much across the board >> (all terminals in the query AST, or all boolean nodes, or some similarly >> blunt instrument). Which makes me worry about cache churn. >> >> Actually I have two questions: >> >> 1. Can I monitor the *filter* cache size and eviction rate somehow? >> (REST for preference, but jmx would be fine too.) I only seem to see >> documentation for the field data cache. >> >> 2. Any advice for caching/not caching the intermediate boolean nodes in a >> complex query? In our case many of these intermediate nodes *will* recur >> in other queries, so my default feeling is to cache them, but that has to >> be balanced against the extra cache usage (and risk of churn). So I guess >> the question is, just how fast is the bitset bool filter (we frequently >> have ANDs and ORs with 10 to 20 children) compared to caching the node? >> Should I even be considering caching these, or is the bitset combination >> fast enough to make it a no-brainer? >> >> Cheers, >> Tikitu >> > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c6227760-89fa-43c1-b326-ae0d875be344%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
