使用NEST ElasticSearch库进行连接池管理

Question

我目前正在使用NEST ElasticSearch C#库与ElasticSearch交互。我的项目是一个MVC 4 WebAPI项目，基本上构建了一个RESTful webservice来访问目录辅助信息。

我们刚刚开始使用NEST，并在缺乏文档方面遇到了一些困难。虽然有些内容是有用的，但是它有一些很大的漏洞。目前，我们需要的一切都可以正常工作，但是，我们遇到了连接有时需要长达一秒钟的问题。我们希望使用某种连接池，类似于与SQL Server进行交互的方式。

这是使用NEST连接的文档：http://mpdreamz.github.com/NEST/concepts/connecting.html 以下是我们项目中相关的代码片段：

public class EOCategoryProvider : IProvider
{
    public DNList ExecuteQuery(Query query)
    {
        //Configure the elastic client and it's settings
        ConnectionSettings elasticSettings = new ConnectionSettings(Config.server, Config.port).SetDefaultIndex(Config.index);
        ElasticClient client = new ElasticClient(elasticSettings);

        //Connect to Elastic
        ConnectionStatus connectionStatus;
        if (client.TryConnect(out connectionStatus))
        {
            // Elastic Search Code here ...
        } // end if
    } // end ExecuteQuery
} // end EOCategoryProvider

从文档中看，我没有看到任何有关连接池的规定。我一直在考虑实现自己的连接池（例如存储3或4个ElasticClient对象，并以轮询方式选择它们），但我想知道是否有更好的解决方案。如果没有，是否有建议手动实现连接池的最佳方法？有什么文章可以参考吗？

感谢你们提供的任何帮助。

更新：这似乎与每个请求调用TryConnect有关，以及特定的网络设置。当使用与Elastic盒子相同网络的机器时，问题完全消失了；我的开发机器（平均350ms到Elastic盒子）似乎有时无法建立http连接，这导致TryConnect的长时间。

- Chris Case

Answer 1

每次调用Elasticsearch时，您不必每次都调用TryConnect()。它基本上是一个用于应用程序启动时的健全性检查调用。

NEST是Elasticsearch的C# REST客户端，默认的IConnection使用WebRequest.Create已经池化了TCP连接。

请查看实际的实现：https://github.com/elastic/elasticsearch-net/blob/master/src/Elasticsearch.Net/Connection/HttpConnection.cs

重用ElasticClient并不会提供任何性能提升，因为每个调用已经得到了自己的HttpWebRequest。整个客户端是有意建立无状态的。

不过，我非常想知道为什么您的调用需要1秒钟的时间。您可以发布实际的NEST代码、如何测量调用以及描述数据的方法。

免责声明：我是NEST的作者。

- Martijn Laarman

---

是的，那将非常好。我想得到一些可重现的东西和一些关于调用的数据，比如它花费了X时间，但如果我使用类似Fiddler的东西来触发它，它需要Y时间。尝试在运行代码时同时启动Fiddler，这样您就可以轻松地重播它。（搜索可能会被Elasticsearch缓存，因此要小心虚假结果） - Martijn Laarman

我们的Elastic guru错误地告诉我NEST使用二进制协议，因此我想汇集连接。现在使用TryConnect更有意义（只是检查确保您的设置正确），但文档对此点并不完全清楚。至于为什么需要一秒钟，似乎与网络有关。同一数据中心的机器从未出现过问题。我使用Stopwatch进行测量，所有时间似乎都在TryConnect调用中。我到Elastic box的平均ping时间（在出现问题的机器上）为350ms。 - Chris Case

抱歉，评论系统出了些问题。在我完成之前不小心发布了。 - Chris Case

我很自豪地听到是你集群中的机器出了问题。感谢您更新问题！对于未来会浏览此帖子的谷歌用户来说，这总是很好的。如果您有任何问题/疑问/请求，请通过发布github问题的方式保持联系。 - Martijn Laarman