# Whether Nest5.2.0 and ElasticSearch.Net 5.2.0 can support elasticsearch6.7.1 query,aggregation,sort? **URL:** \ **Category:** Elasticsearch\ **Created:** [April 21, 2019, 1:17pm UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750 "2019-04-21T13:17:28Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![sunweiconfidence](https://avatars.discourse-cdn.com/v4/letter/s/58956e/32.png) [@sunweiconfidence](https://discuss.elastic.co/u/sunweiconfidence)\ **Post date:** [April 21, 2019, 1:17pm UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/1 "2019-04-21T13:17:28Z")
currently i use [elasticsearch.net](http://elasticsearch.net) 5.2.0 and Nest5.2.0 to call elasticsearch5.4.3 to get the search result, now i prepare to upgrade elasticsearch to version 6.7.1, whether i can use current elasticsearch.net5.2.0 and Nest5.2.0 to call elasticsearch6.7.1? any potential issue for this? or no problem？ thanks ---
**Author:** ![forloop](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/forloop/32/9021_2.png) [@forloop](https://discuss.elastic.co/u/forloop)\ **Post date:** [April 29, 2019, 9:52pm UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/2 "2019-04-29T21:52:50Z")
[Nest 5.x is compatible with Elasticsearch 5.x](https://github.com/elastic/elasticsearch-net#compatibility-matrix). If you're upgrading to Elasticsearch 6.x, you'll also need to upgrade NEST to 6.x too ---
**Author:** ![sunweiconfidence](https://avatars.discourse-cdn.com/v4/letter/s/58956e/32.png) [@sunweiconfidence](https://discuss.elastic.co/u/sunweiconfidence)\ **Post date:** [May 6, 2019, 2:05pm UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/3 "2019-05-06T14:05:16Z")
ok, thanks, another question is that why it will take 15 seconds at first time call using [elasticsearch.net](http://elasticsearch.net) 6.x search syntax like below: var searchResponse = lowlevelClient.Search("people", "person", PostData.Serializable(new { from = 0, size = 10, query = new { match = new { firstName = "Martijn" } } })); but second time call, it will take 77ms , i don't know why, do i need to do other things to let first time call search can have a short response time?, thanks`Preformatted text` ---
**Author:** ![forloop](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/forloop/32/9021_2.png) [@forloop](https://discuss.elastic.co/u/forloop)\ **Post date:** [May 7, 2019, 5:43am UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/4 "2019-05-07T05:43:20Z")
The very first call will be slower than others because the client caches a lot of type metadata on the first call that is needed for serialization. If this a problem for your application, you can initiate the first call during client setup, when the application starts. 15 seconds seems like a long time though, how have you measured/benchmarked that all or the majority of this time is spent by the client? ---
**Author:** ![sunweiconfidence](https://avatars.discourse-cdn.com/v4/letter/s/58956e/32.png) [@sunweiconfidence](https://discuss.elastic.co/u/sunweiconfidence)\ **Post date:** [May 7, 2019, 6:47am UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/5 "2019-05-07T06:47:36Z")
i found that have same issue in github, [https://github.com/elastic/elasticsearch-net/issues/3236](https://github.com/elastic/elasticsearch-net/issues/3236), [https://github.com/elastic/elasticsearch-net/pull/3608](https://github.com/elastic/elasticsearch-net/pull/3608),`Preformatted text` currently i use elasticsearch.net6.6 and Nest6.6, do i need to use 7.x branch to fix the problem? thanks`Preformatted text` ---
**Author:** ![forloop](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/forloop/32/9021_2.png) [@forloop](https://discuss.elastic.co/u/forloop)\ **Post date:** [May 7, 2019, 8:54am UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/6 "2019-05-07T08:54:14Z")
> [@sunweiconfidence](#): > > i found that have same issue in github, This is not the same issue as the one linked. The one linked is about a general performance difference between NEST 5.6.2 and 6.1.0, whereas the issue you describe is about the performance of the first request. The caching performed on the first request cannot be avoided in the client, because the majority of it is performed by [Json.NET](http://Json.NET), the JSON serializer used by the client. Without this caching, you would pay a performance cost on every request, so it helps all requests after the first one. As I mentioned, if there is an issue with the first request being made to a user initiated action within your application, you could prime the cache ahead of time by making the first request just after instantiating the client. Moving to 7.x will not change this behaviour much, as the serialized used within 7.x, Utf8Json, adopts similar caching strategies. Most serializers that I have seen in .NET do something similar. > [@forloop](#): > > 15 seconds seems like a long time though, how have you measured/benchmarked that all or the majority of this time is spent by the client? It would be good to know how you are benchmarking/measuring this ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 4, 2019, 9:00am UTC](https://discuss.elastic.co/t/whether-nest5-2-0-and-elasticsearch-net-5-2-0-can-support-elasticsearch6-7-1-query-aggregation-sort/177750/7 "2019-06-04T09:00:48Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.