Jorg, Ivan, Radu,
Thanks for replying to my question.
800ms is the time ES reports in the "took" field.
I'm still testing out different shard/replica set-ups, and thought I'd test
using 1 shard / n-replicas (since I have three machines, so use n=3) to
test the throughput (returning large resultsets, 90k-120k hits per query)
for my use-case.
I am only using a single field "tags" in each document, where tags are
stored as "verb1, verb2, verb3, verb4" and search is performed using
pyes.StringQuery("verb") , is there anything further I can tweak about this?
I've enabled http compression, and response times measured from the
application <-> elasticsearch seems to have improved by a little. The main
bottleneck still appears to be the 800ms ES reports in the "took" field.
Using Chrome dev tools, _search is 340.78KB after gzipped and 6.62MB
I wonder if its worth it to write a plugin specially for this use-case to
see how fast it can go.
On Tuesday, January 8, 2013 1:14:28 AM UTC+8, Jörg Prante wrote:
What time is 800ms, is it the response time, or the time ES reports in the
Note, only 1 shard is very uncommon setup, it makes query responses slow.
If you use more shards (default is 5 for very good reason) you will have
faster responses because query response generation can be executed on many
distributed indices in parallel. Selecting a replica level of 3 is also
very uncommon. Not that adding replica shards only scale at handling query
load in heavy concurrency situation (if the ES cluster is hammered by
thousands of queries per second), but it does not scale for your case of
creating and transporting large response sets.
You did not give an example about your index mapping and queries, so I
can't tell if your queries need optimization. I consider this most
important before tuning other knobs.
After index and query optimization, you could watch for other knobs to
optimize, here are some general hints.
If you measured the overall response time, there may be overhead in the
JSON serialization/deserialization. Which client do you use? Python?
(Python standard JSON is known to be very slow).
If you measured the "took" field, how large is the result set in kB/MB?
What is the number of TCP packets? Use tcpdump to monitor the network. Note
there is latency on the network, which is outside of the scope of ES. You
can use faster NICs (10gbit) or larger network buffering in your protocol
(HTTP) or compression in your data body to minimize latency (ES supports
HTTP compression, it mus be enabled).
If you can't bear the HTTP overhead (headers are always uncompressed and
mixing with compressed data creates some extra work on the wire protocol)
you can go for Thrift (or WebSocket) for gaining around another 15% benefit.