Lorsque je configurais une connexion à mon groupe ELASTICIDEARCH à l'aide d'ElasticSearch.net, j'utilise un bloc de code comme suit:
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);
3 Réponses :
Je n'ai rien vu dans la documentation pour en informer le contraire, mais cela me tromperais généralement du côté de la prudence et d'éviter le singleton au fur et à mesure que les Docs ne font aucune promesse sur la sécurité thread-sécurité. Assurez-vous de disposer n'importe quoi Idisposable , et si vous êtes inquiet de la performance ou de l'utilisation de la mémoire, utilisez un profileur pour déterminer où cibler vos efforts.
Nous avons remarqué que lorsque vous utilisez le reniflement prend entre 800 ms et 1,2 personnes plus longtemps pour la recherche dans un cluster à 5 nœuds. Nous avons pensé que nous ferions un singleton pour que nous ne renifions que une fois. et définir .Sniffonconnectionfault (true) alors si le nœud qu'il renifla disparaisse, il choisira un autre si je comprends que correctement.
Quelqu'un a-t-il utilisé ce modèle et y a-t-il une meilleure façon de renifler est si lent?
Est-ce 800 ms sur la première demande uniquement ou est-ce constamment 800 ms via plusieurs demandes? J'ai lu des postes de personnes mentionnant que le client doit se réchauffer pour la première demande qui prend beaucoup plus de temps.
Ceci est un ancien poste, mais cette information pourrait aider quelqu'un. La documentation Elasticsearch indique:
En général, nous conseillons aux gens d'enregistrer leurs instances d'élasticité comme singletons. Le client est le fil en toute sécurité, alors partageant une instance entre les threads est bien.
https: // www. elastic.co/guide/fr/elasticsearch/Client/net-api/2.x/lifetimes.html