Чего я должен ожидать от базового RPS для веб-API .NET Core 2, размещенного в качестве службы приложений Azure (P3)?

Question

Я пытаюсь измерить базовый RPS для веб-API, разработанного в .NET Core 2. Вот шаги, которые я выполнил до сих пор

• Создан новый / пустой проект веб-API от Microsoft, запеченный в шаблонах VS
• Добавлен новый контроллер, который выполняет базовый ответ «привет, ваш API работает, конечная точка работает» без логики и без дополнительной обработки ввода / вывода
• Развернуто в Azure как служба приложений. Для плана обслуживания выберите P3 (P3 = 400 всего ACU, 7 ГБ, 800 долл. США в месяц) и установите количество экземпляров максимум до 20.
• Загрузил JMeter и установил нагрузочный тест HTTP-запроса для имитации скачков нагрузки. Я обнаружил, что все, что превышает 530 одновременных запросов, и я начинаю получать сообщения об ошибках HTTP, сообщаемых JMeter, и отложенные ответы, если я пытаюсь сделать запрос в браузере во время этого всплеска.
• Меня смущает, почему настроенная мной вычислительная мощность / масштаб не может обработать более 530 одновременных запросов на базовом контроллере .net core 2. Я пытаюсь получить ответ, если это нормально. Интересно, возможно, есть какие-то точки оптимизации, которые я мог бы упустить? Я выбрал базовую реализацию веб-службы .NET Core, потому что хочу начать с базы кода, которая, как я знал, наверняка не может быть дополнительно оптимизирована, поэтому сначала я могу сосредоточиться на вычислительных потребностях.

Если это ожидаемые результаты для базовой веб-службы .NET Core 2, размещенной в Azure, то, похоже, нам придется потратить гораздо больше денег, поскольку мы надеемся справиться с более чем 3000 параллельный запрос без времени ответа / задержки, превышающий 30 секунд во время пиков. Что касается автоматической балансировки нагрузки, то в нашем случае выбросы происходят в случайное время. Я не могу вдаваться в подробности, но нет абсолютно никакого способа определить, когда эти шипы ударит, это довольно уникальный бизнес-пример, но неизбежный.

Мне также интересно, является ли JMeter лучшим инструментом для проверки этих результатов. Похоже, уважаемый инструмент. Если кому-то повезло с другими инструментами для нагрузочного тестирования, рекомендуем.

Вот все, что у меня происходит при запуске конфигурации / службы из Startup.cs

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseHsts();
    }

    // TO DO: build whitelist
    //    app.UseCors(
    //  options => options.WithOrigins("http://example.com").AllowAnyMethod() );
    app.UseCors(options => options.WithOrigins("*").AllowAnyMethod());
    app.UseHttpsRedirection();
    app.UseMvc();

}

а также

public void ConfigureServices(IServiceCollection services)
{
   // ADDCors during test stages
    services.AddCors();


    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);


}

Answer 1

.NET ядро ​​очень приличное с точки зрения обработки высоких RPS. Когда вы запускаете тесты такого типа и разрабатываете приложение, существует множество факторов, которые могут основываться на следующем, но не ограничиваются:

.NET Core версия

Вы просто упомянули, что используете .NET Core 2. Просто чтобы знать, что существует несколько версий .NET Core 2.X, и существует значительная разница в производительности между .NET 2.0 и .NET 2.2. Если вы хотите узнать больше о разнице в производительности, пожалуйста, следуйте инструкциям Джона Галлоуэя от Microsoft по следующей ссылке. https://www.youtube.com/watch?v=04SmFYwLPwM&feature=youtu.be&list=LLxfaEBq0Fa7eiKokf98ojxA&t=167

Скамьи

Вы можете найти различные контрольные показатели, основанные на личном опыте, но я предпочитаю techempower, которым управляет сообщество. https://www.techempower.com/benchmarks/

Инструменты тестирования производительности

JMeter - хороший инструмент для тестирования производительности, и упомянутое вами время отклика очень велико, и в идеале оно должно быть в миллисекундах, поэтому некоторые вещи не являются правильными и, безусловно, требуют изучения. Вы можете использовать инструмент тестирования производительности Azure для проверки ваших тестов. Инструмент тестирования производительности Azure предоставит вам более глубокое понимание. https://docs.microsoft.com/en-us/azure/devops/test/load-test/app-service-web-app-performance-test?view=vsts

Обработка шипов

Когда вы тестируете пики с помощью веб-приложений Azure, вам нужно знать о нескольких вещах. Веб-приложения Azure - это хороший выбор, если вы знаете о своей загрузке в Интернете. Обработка всплесков с помощью веб-приложений Azure может быть сложной задачей. Вы должны знать, что ваш скачок вызывает подготовку нового экземпляра, может потребоваться несколько минут для того, чтобы новая виртуальная машина обрабатывала запросы, и обычно вам приходится чрезмерно выделять виртуальные машины для обработки скачков, что может быть дорогостоящим выбором.

Вы бы предпочли Контейнеры (например, Docker) + Orchestrator (например, Azure Kubernetes) или Без сервера (функции Azure) или оба для обработки пиков, и они специально предназначены для этого и адаптируются к пикам практически мгновенно.

Когда вы разрабатываете приложение для обработки высокого RPS, оно может основываться на следующих, но не ограничиваясь выбранным вами Регионе, выборе облачной службы (Azure Web Apps, контейнеры, без сервера, VMS), интеллектуальном кэшировании, базе данных, метриках масштабирования и выборе языка. Здесь нет однозначного ответа, и он действительно зависит от того, чего вы пытаетесь достичь.

Дополнительные инструменты и тестирование

Информация о приложениях от Microsoft - очень мощный инструмент для более глубокого изучения результатов тестирования производительности. Когда вы тестируете с помощью Azure, всегда предоставляйте Application Insight для проверки ваших результатов.

Запуск различных тестовых комбинаций, таких как увеличение времени запуска пользователя, избыточное выделение экземпляров Azure Web Apps, выбор ОС (Linux и Windows), с комбинацией различных инструментов мониторинга для получения некоторых сопоставимых результатов.

Надеюсь, это поможет!