{"took":1910,"timed\_out":false,"\_shards":{"total":4,"successful":4,"failed":0},"hits":{"total":9485
{"took":986,"timed\_out":false,"\_shards":{"total":4,"successful":4,"failed":0},"hits":{"total":9485,
{"took":704,"timed\_out":false,"\_shards":{"total":4,"successful":4,"failed":0},"hits":{"total":9483,
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [January 14, 2016, 6:38am UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/2 "2016-01-14T06:38:45Z")
You haven't really described what the problem is here, you just seem to be asking for recommendations on things to change without providing the full context of what's you think is not working and why.
> [@Jayme](#):
>
> I want to keep the number of segments to the lowest as possible:
> What are the best setting "merge" settings for the index?(knowing that the size of the merges will be relatively low and the server is running on SSD)
> Having the latest data is less crucial, so everything can be aggregated in a translog first and only merged after a while, as long as searches go fast enough.
We suggest _not_ touching merge settings, most of the time it'll work against you.
> [@Jayme](#):
>
> I know that everything in ES 2.1 is now stored as "doc\_values" by default, I'm a bit afraid that some of the speed benefits are lost with this approach, Do you think using "fielddata" again for some field would be benefitial in terms of search speed?
Nope, that's why we moved to doc values 😉
> [@Jayme](#):
>
> The store that is used for elastic on linux is now niofs or mmapfs, would explictely defining "index.store.type: "mmapfs" be any beneficial in my case? (answer here was to leave these settings as is as much as possible - [Mmapfs vs niofs?](https://discuss.elastic.co/t/mmapfs-vs-niofs/27965))
I believe `mmapfs` should be picked by default on most systems, even non-Windows.
---
### Author:  [@Jayme](https://discuss.elastic.co/u/Jayme)
#### Post date: [January 14, 2016, 7:43am UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/3 "2016-01-14T07:43:00Z")
Well my main question is: what merge settings do I need to use to not have that many segments in my index as I see that searches are much slower compared to older versions of elastic, and when I run manually \_optimize=max\_segments=1 it all goes faster again.. I can put this in cronjob to run every hour but this should be adjustable by changing these merge settings to trigger faster, so which settings do I use?
---
### Author:  [@jpountz](https://discuss.elastic.co/u/jpountz)
#### Post date: [January 14, 2016, 9:03am UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/4 "2016-01-14T09:03:30Z")
For the record I suspect that the main reason why you get better performance on 1-segment indices is that you are using several range queries in your query, which are terms-dictionary intensive queries. So the fewer segments you have, the fewer terms dictionaries the range queries need to resolve matching terms against.
---
### Author:  [@Jayme](https://discuss.elastic.co/u/Jayme)
#### Post date: [January 14, 2016, 9:21am UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/5 "2016-01-14T09:21:33Z")
@jpountz, thanks! That's what I also saw is that when I removed the :
```
{
"range": {
"lastlogindate": {
"gte": "2015-01-13 00:00",
"lte": "2016-01-13 10:00"
}
}
}
```
part in my query performance increased from avg 1000ms to sub 100ms.
so performance increase of times 10.
Also in 2.1 it states that only the 256 most active filters are cached,
what setting allows me to increase this/ are there insights in what these 256 filters are?
---
### Author:  [@jpountz](https://discuss.elastic.co/u/jpountz)
#### Post date: [January 14, 2016, 4:51pm UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/6 "2016-01-14T16:51:24Z")
This can't be configured, but I don't think caching is the problem here, especially given that ranges are cached more aggressively due to their cost.
---
### Author:  [@Jayme](https://discuss.elastic.co/u/Jayme)
#### Post date: [January 14, 2016, 4:59pm UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/7 "2016-01-14T16:59:17Z")
Ok - I've opened an issue for it. [https://github.com/elastic/elasticsearch/issues/15994](https://github.com/elastic/elasticsearch/issues/15994) - I can fix my queries to do the range queries in the post\_filter but it's weird behaviour for sure.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 5, 2017, 11:24pm UTC](https://discuss.elastic.co/t/optimize-elastic-2-x-for-fast-searches-as-much-as-possible-on-a-relatively-small-index-what-are-the-best-practices/39096/8 "2017-07-05T23:24:26Z")