Недостаток производительности в Azure Storage - всего 200 RPS

Question

Я создал веб-приложение apnet с сетевым приложением Asp.Net Core (.NET Core), которое дает нам api/values ​​controller, и в сообщении я отправляю сообщение azure, используя библиотеку Windows Azure Storage v8.0. https://www.nuget.org/packages/WindowsAzure.Storage/8.0.0

В настоящее время, когда я делаю один запрос, очередь занимает около avg. 140 мс, чтобы завершить метод AddMessageAsync(), но когда я выполняю тест нагрузки на 200 запросов в секунду, тот же метод занимает в среднем 800 мс для завершения. В соответствии с лазурной очередью хранения он должен обрабатывать 2000 запросов в секунду, но я не могу получить 200 запросов в секунду.

Я был бы признателен, если бы кто-то предоставил некоторую информацию о том, почему веб-приложение api не работает должным образом.

Пожалуйста, смотрите ниже моего кода примера

Startup.cs - ConfigureServices()

// Add QueueAccessLayer. 
services.AddSingleton<IQueueAccessLayer, QueueAccessLayer>(); 

Emailcontroller.cs

[Route("api/[controller]")] 
public class EmailController : Controller 
{ 
    private IQueueAccessLayer _queue; 

    public EmailController(IQueueAccessLayer queue) 
    { 
     _queue = queue; 
    } 

    // POST api/values 
    [HttpPost] 
    public async Task<IActionResult> Post([FromBody]string value) 
    { 
     var emailMessage = "Message Id - " + Guid.NewGuid(); 
     await _queue.SendMessage(emailMessage); 
     return new EmptyResult(); 
    } 
} 

QueueAccessLayer.cs

public class QueueAccessLayer : IQueueAccessLayer 
{ 
    private CloudQueueClient _queueClient;   
    private CloudStorageAccount _storageAccount; 

    private CloudQueue _emailQueue; 
    private ILogger<QueueAccessLayer> _logger; 


    public QueueAccessLayer(ILogger<QueueAccessLayer> logger) 
    { 
     _storageAccount = CloudStorageAccount.Parse("DefaultEndpointsProtocol=https;AccountName=test1;AccountKey=#####;"); 
     _queueClient = _storageAccount.CreateCloudQueueClient(); 
     _emailQueue = _queueClient.GetQueueReference("emailqueue"); 
     _emailQueue.CreateIfNotExistsAsync().Wait(); 

     _logger = logger; 
    } 

    public async Task<bool> SendMessage(string msg) 
    { 
     Stopwatch watch = new Stopwatch(); 
     watch.Start(); 
     CloudQueueMessage message = new CloudQueueMessage(msg); 
     await _emailQueue.AddMessageAsync(message); 
     watch.Stop(); 

     _logger.LogInformation(msg + " - " + watch.ElapsedMilliseconds + "ms"); 
     return true; 
    } 
} 

public interface IQueueAccessLayer 
{ 
    Task<bool> SendMessage(string msg); 
} 

Answer 1

Убедитесь установить f при запуске приложения:

1. ServicePointManager.Expect100Continue = false;
2. ServicePointManager.UseNagleAlgorithm = false;

Expect100Continue установлен в ложном - уменьшат туда и обратно на стороне сервера при отправке запросов.

UseNagleAlgorithm установлен на false - отключит оптимизацию Nagle и значительно улучшит производительность.

Существует большой блог, который объясняет это: Nagle’s Algorithm is Not Friendly towards Small Requests .

Nagling является оптимизация TCP на отправителе и предназначен для уменьшения перегрузки сети путем коалесценции мелких запросов посыла в более крупные сегменты TCP ... Это достигается за счет сдерживая небольшие сегменты либо пока TCP не имеет достаточно данных для передачи сегмент полного размера или пока все выдающиеся данные не были подтверждены приемником ... Тест выполняется как рабочая роль, доступ к нашей учетной записи хранилища в том же географическом местоположении. Он вставляет сообщения длиной 480 байт. Результаты показывают, что средняя задержка улучшается более чем на 600% при отключении Nagling.