ElasticSearch.NET gestione delle connessioni client/ciclo di vita

Question

Quando ho creato un collegamento al mio gruppo elasticsearch utilizzando ElasticSearch.NET, sto usando un blocco di codice come il seguente:

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); 

E 'raccomandato che ho Memoize/rendere statico/creare un wrapper singleton per lo ElasticsearchClient, lo ConnectionConfiguration o lo SniffingConnectionPool in modo che non debbano essere ricostruiti ogni volta che cerco?

Answer 1

Non ho visto nulla nella documentazione per consigliare il contrario, ma in generale vorrei sbagliare sul lato della cautela ed evitare il singleton in quanto i documenti non promettono nulla sulla sicurezza del thread. Assicurati di smaltire qualsiasi cosa IDisposable e, se sei preoccupato per le prestazioni o l'utilizzo della memoria, utilizza un profiler per determinare dove indirizzare i tuoi sforzi.

Answer 2

Abbiamo notato che quando si utilizza lo Sniffing richiede più tempo tra 800ms e 1.2s per la ricerca in un cluster a 5 nodi. Pensavamo di fare un singleton in modo da annusare solo una volta. e imposta .SniffOnConnectionFault (true) se il Node che annusa si spegne ne sceglierà un altro se lo capisco correttamente.

Qualcuno ha usato questo modello e c'è un modo migliore dal momento che lo sniffing è così lento?

Answer 3

Questo è un vecchio post, ma questa informazione potrebbe aiutare qualcuno. La documentazione di Elasticsearch dice:

In generale si consiglia alla gente di registrare le istanze di ElasticClient come singleton. Il client è thread-safe, quindi la condivisione di un'istanza tra i thread va bene.

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