Windows Azure хранение таблицы, как включить поддерживать

Question

В настоящее время я ставлю лазурное хранение таблицы, как это:

public static void AzurePut(string Key, byte[] Value) 
{ 
    CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString); 
    CloudTableClient tableClient = storageAccount.CreateCloudTableClient(); 

    var keyhash = MyTable.CalculateMD5Hash(Key); 
    var tc = MyTable.GetBinFromHash(keyhash, AzureTables.TableCount); 
    CloudTable table = tableClient.GetTableReference("table" + tc); 

    var entity = new AzureEntity(); 
    entity.Key = keyhash; 
    entity.SetValue(Value); 

    TableOperation insertOperation = TableOperation.InsertOrReplace(entity); 
    table.Execute(insertOperation); 
} 

Я много кладет и они медленно. Когда я открываю fidller, они становятся примерно в 40 раз быстрее. После проверки, почему выясняется, что скрипач повторно использует соединения с подключением: заголовки keep-alive. Есть ли способ сделать это с помощью таблицы хранения api?

Answer 1

Short: Добавить это стартовый код приложения:

 ServicePointManager.DefaultConnectionLimit = 100; // Default 2 
     ServicePointManager.UseNagleAlgorithm = false; // Default true 

Объяснения

Вы не должны добавлять Keep-Alive заголовки, они уже здесь. Посмотрите на HttpWebRequestFactory (строка 86):

#if WINDOWS_DESKTOP && !WINDOWS_PHONE 
      request.KeepAlive = true; 

      // Disable the Expect 100-Continue 
      request.ServicePoint.Expect100Continue = false; 
#endif 

      return request; 
     } 

В верхней части этого HttpWebRequest использует HTTP 1.1 по умолчанию, которые makes connection persistent by default

Вы можете использовать TcpView видеть, что соединение используется повторно.

Скрипач настолько быстр в основном потому, что он очень умный в отношении повторного использования соединений, запросов на доработку и буферизацию, особенно когда ваше приложение выполняет множество параллельных запросов.

По умолчанию ServicePointManager.DefaultConnectionLimit - это 2, что означает, что вы можете иметь только два ожидающих запроса одновременно. Представьте, что у вас есть 8 потоков, пытающихся сделать запрос, 2 из них могут быть активны вовремя, остальные ждут. Повышение предела значительно улучшает одновременные запросы.

Другая проблема заключается в том, что по умолчанию включен ServicePointManager.UseNagleAlgorithm. Поскольку большинство запросов Azure Table относительно невелики (размер HTTP-сообщения < 1460 байт), они не нужны буферизированы. См. Гораздо более подробное объяснение этого at Microsoft Azure Storage Team Blog (Nagle’s Algorithm is Not Friendly towards Small Requests)