I have two JMeter tests. Let's call them "Straight Elasticsearch Test" and "Service Test". Both tests use the same settings in terms of number of threads (users), number of times the URL is invoked (loops), and randomized CSV-based data set.
The difference between the two tests is that the Straight Elasticsearch Test just makes HTTP requests against my cluster whereas the Service Test makes HTTP requests against my Java service layer. Both tests invoke the same Elasticsearch query. I've verified this by comparing what the Straight Elasticsearch Test posts to what the Java service creates using the SearchRequestBuilder. Here is the query and the search invocation via the Java API: https://gist.github.com/jpotts/feaf0cedc2eea29a8aa7 I'm running both tests with 10 concurrent users and 2000 iterations for a total of 20,000 hits against either Elasticsearch directly or the Java service depending on the test. Here's the puzzling thing: The Straight Elasticsearch Test causes the CPU on my single-node cluster to go to around 50% for the duration of the test. But the Service Test causes it to go to twice that. So the same number of concurrent users, the same number of total hits, and the same query are causing drastically different CPU utilization rates. What could be causing this? I've tested with the Java service using the Transport Client as well as the Node Client, the results are the same. I'm thinking it must be something different in how the server handles HTTP request versus Node/Transport Client requests. This is Elasticsearch 1.3.4 and the index is a single shard with no replicas and about 100k docs. 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/63fd9d8e-ec67-4c6c-817f-4201d5f18ea9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
