ElasticSearch.NET Connection / Client Management Lifecycle

When I set up a connection to my ElasticSearch cluster using ElasticSearch.NET, I use a code block, for example:

var uris = settingsProvider.ElasticSearchUri.Split(';').Select(x => new Uri(x)); var sniffingConnectionPool = new SniffingConnectionPool(uris); var connectionConfiguration = new ConnectionConfiguration(sniffingConnectionPool) .SniffOnConnectionFault() .SniffOnStartup(); var client = new ElasticsearchClient(settings: connectionConfiguration); 

Do I recommend memoize / make static / make singleton wrapper for ElasticsearchClient , ConnectionConfiguration or SniffingConnectionPool so that they do not need to be restored every time I search?

+6
source share
3 answers

I did not see anything in the documentation to advise otherwise, but in general I would be mistaken with caution and avoid a singleton, since the documents also did not have promises about thread safety. Be sure to delete anything IDisposable , and if you are concerned about performance or memory usage, use the profiler to determine where you can customize your efforts.

0
source

We noticed that when using Sniffing, it takes from 800 ms to 1.2 s longer to search in a 5 node cluster. We thought we would make a singleton so that we would only smell once. and set .SniffOnConnectionFault (true), then if he sniffs the node, it will select another, if I understand correctly.

Has anyone used this pattern, and is there a better way since sniffing is so slow?

0
source

This is an old post, but this information may help someone. Elasticsearch documentation says:

In general, we advise people to register their ElasticClient instances as single. The client is thread safe, so sharing an instance between threads is fine.

https://www.elastic.co/guide/en/elasticsearch/client/net-api/2.x/lifetimes.html

0
source

Source: https://habr.com/ru/post/970810/


All Articles