# Preventing slow queries on public APIs **URL:** \ **Category:** Elasticsearch\ **Created:** [April 17, 2013, 6:40pm UTC](https://discuss.elastic.co/t/preventing-slow-queries-on-public-apis/11617 "2013-04-17T18:40:01Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Greg\_Brown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/greg_brown/32/1373_2.png) [@Greg\_Brown](https://discuss.elastic.co/u/Greg_Brown)\ **Post date:** [April 17, 2013, 6:40pm UTC](https://discuss.elastic.co/t/preventing-slow-queries-on-public-apis/11617/1 "2013-04-17T18:40:01Z")
Howdy, I'm working on exposing the ES Query DSL on a public API and am looking at filtering certain parts of the DSL to prevent some of the more obvious performance problems that could be created. I'm trying to find a good balance between allowing the full flexibility and power that the DSL provides while preventing users from inadvertently (or intentionally) interfering with each other's queries. So far the list of things I'm thinking of filtering out are: parameters disallowed anywhere: \_cache (I think I'd prefer that we retain control over the caching) script (from what I can tell there is nothing stopping someone from creating an infinite loop, or other very costly script) match/multi\_match query: max\_expansions \< 15 for phrase queries mlt, flt queries: max\_query\_terms \< 30 fuzzy query: max\_expansions is set and \< 10 prefix\_length \> 1 Completely Disallow: custom\_score query (requires a script) query\_string query (lots of ways to write queries that fail) top\_children query (our data doesn't have any publicly available children/parents right now) wildcard query indices query text query (just cause it is deprecated) script filter has\_child filter has\_parent filter Facets are also not allowed Anyone else looked at doing something similar? Any other types of queries or edge cases that you've seen cause performance problems? I'll hopefully remove some of these restrictions over time, but I'd rather start out without worrying too much about it. Thanks -Greg -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [April 17, 2013, 7:29pm UTC](https://discuss.elastic.co/t/preventing-slow-queries-on-public-apis/11617/2 "2013-04-17T19:29:41Z")
Thanks for the wrapup of the cases. One additional case that comes to my mind are phrase queries on frequent words. See also [http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-1](http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-1) and [http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-2](http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-2) (old but good) Jörg Am 17.04.13 20:40, schrieb Greg Brown: > Anyone else looked at doing something similar? Any other types of > queries or edge cases that you've seen cause performance problems? -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Greg\_Brown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/greg_brown/32/1373_2.png) [@Greg\_Brown](https://discuss.elastic.co/u/Greg_Brown)\ **Post date:** [April 17, 2013, 8:47pm UTC](https://discuss.elastic.co/t/preventing-slow-queries-on-public-apis/11617/3 "2013-04-17T20:47:14Z")
Hi Jörg, Thanks for those links, they were really helpful. I am using stopwords for all languages for which they are available which should help in those cases. At the cost of queries like "to be or not to be" failing. I hadn't seen the new cutoff\_frequency parameter now available in 0.90 which looks like it would mitigate this problem. Will have to reevaluate whether to reindex with stopwords at some point. Feels like a big change that could have other implications (faceting, other query types). Looking at the match query again though I should probably impose a cap for slop on phrase queries. Probably require it to be less than 4. This discussion also reminds me that I once ran into a case where the max number of boolean clauses in an AND filter was hit (1024). Will probably add a limit of 50 clauses for: and filter or filter bool filter bool query Also should have a max query depth when nesting a bunch of query DSL statements. Start with 10. On Wednesday, April 17, 2013 1:29:41 PM UTC-6, Jörg Prante wrote: > Thanks for the wrapup of the cases. One additional case that comes to my > mind are phrase queries on frequent words. > > See also > > [http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-1](http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-1) > and > > [http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-2](http://www.hathitrust.org/blogs/large-scale-search/slow-queries-and-common-words-part-2) > (old but good) > > Jörg > > Am 17.04.13 20:40, schrieb Greg Brown: > > > Anyone else looked at doing something similar? Any other types of > > queries or edge cases that you've seen cause performance problems? -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [April 17, 2013, 11:19pm UTC](https://discuss.elastic.co/t/preventing-slow-queries-on-public-apis/11617/4 "2013-04-17T23:19:00Z")
Just to add, this is also true for a "terms" query. The default clause limit is 1024 in Lucene, but it can be raised. Jörg Am 17.04.13 22:47, schrieb Greg Brown: > This discussion also reminds me that I once ran into a case where the > max number of boolean clauses in an AND filter was hit (1024). -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:40am UTC](https://discuss.elastic.co/t/preventing-slow-queries-on-public-apis/11617/5 "2017-07-06T02:40:42Z")
Closed on July 6, 2017, 2:40am UTC