I figured it out. The queries executed by the straight Elasticsearch REST test and the Java test are not exactly identical. The difference is that the "current date" used by the straight Elasticsearch test is pulled from a randomized CSV file whereas the Java service always injects the actual current date down to the millisecond. So, even though I switched the query and the Java to leverage filters, the straight Elasticsearch REST test is the only test that takes advantage of the cache. The Java service query doesn't take advantage of the cache because the current date changes every millisecond.
To confirm this I hardcoded the milliseconds in both the REST test and the Java service. Once I did that, the CPU rates (and everything else) were identical. The other telltale sign that there was a problem was the indices filter cache graph in Marvel. Once straight REST test ran once, it could be re-run and never cause an increase in what is in the filter cache. The Java service, on the other hand, was populating the filter cache every time. Thanks to everyone that weighed in on this. Jeff -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/4a3e2981-7a3b-4e6e-a2f0-ed65fddc9150%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
