# Painfully slow queries **URL:** \ **Category:** Elasticsearch\ **Created:** [December 16, 2015, 11:41am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346 "2015-12-16T11:41:34Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![111106](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/111106/32/6665_2.png) [@111106](https://discuss.elastic.co/u/111106)\ **Post date:** [December 16, 2015, 11:41am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/1 "2015-12-16T11:41:34Z")
I'm experiencing problems with query time. The longer the word count gets in the query, the longer it takes, up to a whopping 30s when unwarmed. My config: i5, 8GB RAM ES 2.1.0 1 node, 1 shard, 0 replicas, 1 index (don't plan on having more) ES\_HEAP\_SIZE set to 4g All I have in elasticsearch.yml: script.engine.groovy.inline.search: on bootstrap.mlockall: true indices.cache.filter.size: 20% indices.memory.index\_buffer\_size: 30% index.refresh\_interval: 30s index.translog.durability: request My configuration (PHP): [http://pastebin.com/TXFVkd9T](http://pastebin.com/TXFVkd9T) My mapping (PHP): [http://pastebin.com/LFg71XSm](http://pastebin.com/LFg71XSm) There currently sit ~4000 documents. An example query: {"size":20,"query":{"filtered":{"query":{"bool":{"should":[{"multi\_match":{"query":" гостиница парковка","use\_dis\_max":false,"type":"cross\_fields","fuzziness":"1","slop":"1","operator":"and","fields":["specializationsNames","address^3","city","name^8","description^2","subcategoriesNames^3","categoryName^3","tags^5","services^3"]}},{"multi\_match":{"use\_dis\_max":false,"type":"best\_fields","fuzziness":"2","slop":"1","operator":"and","fields":["specializationsNames","address^3","city","name^8","description^2","subcategoriesNames^3","categoryName^3","tags^5","services^3"],"query":" gostinica parkovka"}}]}},"filter":{"bool":{"must":[{"bool":{"should":[{"range":{"filter.price":{"le":500}}}]}}]}}}},"sort":[{"\_score":{"order":"desc"}}]} I really need help here. Been trying to tackle what's wrong for two days now. Appreciate any help I can get. Thank you. ---
**Author:** ![111106](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/111106/32/6665_2.png) [@111106](https://discuss.elastic.co/u/111106)\ **Post date:** [December 17, 2015, 7:18am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/2 "2015-12-17T07:18:07Z")
Anyone? Still can't figure out what's wrong. ---
**Author:** ![inzanez](https://avatars.discourse-cdn.com/v4/letter/i/7ea924/32.png) [@inzanez](https://discuss.elastic.co/u/inzanez)\ **Post date:** [December 17, 2015, 7:53am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/3 "2015-12-17T07:53:39Z")
Well I don't know about the whole query stuff you're doing there, but just to check nevertheless: Is your machine swapping by any chance? ---
**Author:** ![111106](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/111106/32/6665_2.png) [@111106](https://discuss.elastic.co/u/111106)\ **Post date:** [December 17, 2015, 8:47am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/4 "2015-12-17T08:47:30Z")
No, the swapping is turned off, the `free -m` shows me zeroes for swap, plus there's the `mlockall`. The indexing is also kinda slow, to be honest. ---
**Author:** ![inzanez](https://avatars.discourse-cdn.com/v4/letter/i/7ea924/32.png) [@inzanez](https://discuss.elastic.co/u/inzanez)\ **Post date:** [December 17, 2015, 9:02am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/5 "2015-12-17T09:02:08Z")
Could you install hq plugin to watch the performance metrics in there for once? I find that quite useful,...I see what's going on on the different machines regarding indexing, queries, I/O, memory usage and so on, maybe that will give you some hint on what's going on? I for one thing had disk i/o problems with my cluster, and it was really slow,...and I saw that in the HQ,... ---
**Author:** ![jimczi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimczi/32/47985_2.png) [@jimczi](https://discuss.elastic.co/u/jimczi)\ **Post date:** [December 17, 2015, 10:00am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/6 "2015-12-17T10:00:52Z")
That's strange. Can you share the current mapping of your index/type: [https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-get-field-mapping.html](https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-get-field-mapping.html) I would also suggest to try without the fuzziness to see if it speed up the query. ---
**Author:** ![111106](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/111106/32/6665_2.png) [@111106](https://discuss.elastic.co/u/111106)\ **Post date:** [December 17, 2015, 10:22am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/7 "2015-12-17T10:22:51Z")
Sure. Here're the current mappings. The filter property is dynamic, so not all documents have the same nested fieldset there. [http://pastebin.com/McgXawHu](http://pastebin.com/McgXawHu) The fuzziness indeed affects the response time very positively, but I'm not sure if I'll be able to do without it. (Though any tips here will help). ---
**Author:** ![jimczi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimczi/32/47985_2.png) [@jimczi](https://discuss.elastic.co/u/jimczi)\ **Post date:** [December 17, 2015, 11:27am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/8 "2015-12-17T11:27:57Z")
The fuzzy part of your query seems problematic. You try to apply a fuzzy query on all fields but some fields use the ngram tokenizer with a min size of 4 (tags for instance). For small words, a fuzzy query with a max distance of 2 has a big chance to match a large number of entries. You may want to change the max\_expansions parameter in order to limit the number of expanded words in your query: [https://www.elastic.co/guide/en/elasticsearch/guide/2.x/fuzzy-query.html](https://www.elastic.co/guide/en/elasticsearch/guide/2.x/fuzzy-query.html) Though a fuzzy query on a field with ngrams is not a good idea, what are you trying to solve here ? I guess you could apply a fuzzy query only on a subset of your fields (the ones that use a standard tokenizer) by adding another should clause. ---
**Author:** ![111106](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/111106/32/6665_2.png) [@111106](https://discuss.elastic.co/u/111106)\ **Post date:** [December 17, 2015, 11:37am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/9 "2015-12-17T11:37:01Z")
While max expansions didn't do anything in terms of query time, your suggestions got me thinking. I guess what I'm essentially doing here is putting the burden of error correction in user input on query time. Now that I think about it, maybe it's not the best idea (especially since it's also a slow idea). Do you think it would be more reasonable to put this responsibility on autocomplete/suggest functionality instead? Maybe I can implement a better analyzer setup instead of doing a fuzzy search? ---
**Author:** ![jimczi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jimczi/32/47985_2.png) [@jimczi](https://discuss.elastic.co/u/jimczi)\ **Post date:** [December 17, 2015, 11:41am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/10 "2015-12-17T11:41:47Z")
Exactly, the autocomplete/suggest is what you're looking for, it's fast and it provides fuzziness support out of the box. ---
**Author:** ![111106](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/111106/32/6665_2.png) [@111106](https://discuss.elastic.co/u/111106)\ **Post date:** [December 17, 2015, 11:44am UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/11 "2015-12-17T11:44:28Z")
Thank you! ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 11:30pm UTC](https://discuss.elastic.co/t/painfully-slow-queries/37346/12 "2017-07-05T23:30:12Z")