Последствия использования AzureSearch SDK со статическим словарем 30-40 ISearchIndexClients

Question

У меня есть веб-приложение ASP.NET, которое использует 30-40 различных поисковых индексов в 5-6 поисковых службах (различные клиенты находятся в разных ценовых уровнях).

В настоящее время я выстраивая новый экземпляр ISearchServiceClient с последующим соответствующим ISearchIndexClient для конкретного индекса необходимости, исходя из клиента, делающего вызов.

В целях повышения производительности, я думал о том, выстраивая до ВСЕХ ISearchIndexClients при запуске приложения и поместить их в словаре объекта:

public static Dictionary<String, SearchIndexClient> SearchIndexes; 

так, что любой конкретный индекс может быть вызван непосредственно от статического словаря и используется как так:

SearchIndexes["IndexName"].Documents.Search(searchText, searchParameters); 

Моя надежда состоит в том, что это ускорит запросов и обновление индекса раз, особенно на "hot" индекс. Я обеспокоен тем, что это может привести к утечкам памяти, проблемам производительности и другим неизвестным.

Я не видел никаких примеров использования статически доступные SearchServiceClient или SearchIndexClient поэтому я немного неловко идти вперед с этим подходом. Мои вопросы для сообщества:

1. Является ли мой план звуком?
2. Будет ли это на самом деле повышать производительность.
3. Каковы недостатки или последствия (если есть?)
4. Если количество индексов увеличивается с течением времени (например, до 60-70), тогда я начну видеть недостатки?

5. бы больше смысла, чтобы мобилизовывать вверх SearchServiceClients в словарь и подключить к соответствующему SearchIndexClient оттуда по мере необходимости, как так:

   public static Dictionary<String, SearchServiceClient> SearchServices; 
   
   var searchIndexClient = SearchServices["ServiceName"].Indexes.GetClient("IndexName"); 
   searchIndexClient.Documents.Search(searchText, searchParameters); 
   

Answer 1

Эта стратегия, вероятно, не масштабируется к числу индексов, которые вы хотите. Наиболее вероятным результатом является то, что вы исчерпаете пул доступных TCP-соединений. Лучшим подходом было бы реализовать кеш из SearchIndexClient экземпляров с ключом по имени индекса. В случае промаха в кеше вы можете получить эксклюзивный доступ к последнему используемому клиенту и вызвать на нем TargetDifferentIndex. Этот метод был добавлен в SearchIndexClient для этого сценария.

Вы можете найти больше дискуссий и справочную информацию о последствиях распространения SearchIndexClients на GitHub, в MSDN forums и this related StackOverflow question.