# Performance issues around \_source and large page size **URL:** \ **Category:** Elasticsearch\ **Created:** [August 15, 2016, 8:38pm UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066 "2016-08-15T20:38:14Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![MDavisHomeAway](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mdavishomeaway/32/11380_2.png) [@MDavisHomeAway](https://discuss.elastic.co/u/MDavisHomeAway)\ **Post date:** [August 15, 2016, 8:38pm UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066/1 "2016-08-15T20:38:14Z")
We're running a ES 1.7 cluster with an index of ~1.5 million documents, averaging around 20k in size. Our searches generally use a page size of 1000, as we do secondary sorting with live data that isn't available in our ES Index. We currently have \_source disabled for performance reasons. We're interested in turning it on, but we're seeing a significant performance hit from our current field-based approach. I created mirrored indices, one with \_source enabled, one disabled. Both include stored fields, as we would want those for a transitional period. For one of our sample queries (filtered, heavily faceted), we see response times like: * * * ## Index \_source disabled Query returns Fields 120ms response time ## Index \_source enabled Query returns Fields 430ms response time ## Index \_source enabled Query returns Filtered Source 750ms response time Even when we don't query for the \_source, response times tripled just because there was \_source stored in the index. Beyond that, when we do return filtered \_source, rather than stored fields, response times almost double again. Has anyone else seen issues like this? Any recommendations for mitigating the perf hit? ---
**Author:** ![taras](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/taras/32/507_2.png) [@taras](https://discuss.elastic.co/u/taras)\ **Post date:** [August 16, 2016, 7:11pm UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066/2 "2016-08-16T19:11:49Z")
Way back when, I did observe similar behavior, but didn't do formal tests. Would be curious to see if you observe same issue on 2.x code base. ---
**Author:** ![MDavisHomeAway](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mdavishomeaway/32/11380_2.png) [@MDavisHomeAway](https://discuss.elastic.co/u/MDavisHomeAway)\ **Post date:** [August 16, 2016, 7:43pm UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066/3 "2016-08-16T19:43:16Z")
Did you see a performance improvement when moving to 2.x? We're hoping to make the move before terribly long, but I haven't seen a whole lot of info on performance comparisons between the major versions. ---
**Author:** ![taras](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/taras/32/507_2.png) [@taras](https://discuss.elastic.co/u/taras)\ **Post date:** [August 16, 2016, 7:49pm UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066/4 "2016-08-16T19:49:04Z")
Your mileage may vary is the answer. When comparing apples to apples, yes. Some people are hit by default values that cause more write consistency on replicas, transaction log writes, etc. We use a lot of geo functionality and that received a very healthy performance boost. Overall, I find that the server is a lot more stable and that is worth it by itself. ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 17, 2016, 7:15am UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066/5 "2016-08-17T07:15:25Z")
> [@MDavisHomeAway](#): > > I haven't seen a whole lot of info on performance comparisons between the major versions. This will improve over time. We run [nightly benchmarks of the latest master version](https://elasticsearch-benchmarks.elastic.co/geonames/index.html). I also try to add numbers for the latest versions of past releases (i.e. 1.7.5 and 2.3.5 release). However, performance can depend on a lot of factors and the best you can do is to set up an environment and run performance tests there with your own data. We develop and use [Rally](https://github.com/elastic/rally) for our benchmarks and it can help you with some tasks related to benchmarking Elasticsearch. Daniel ---
**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, 10:27pm UTC](https://discuss.elastic.co/t/performance-issues-around--source-and-large-page-size/58066/6 "2017-07-05T22:27:22Z")