Comments 9
Осталось непонятным где именно проседает производительность, что это за «алгоритм соответствия имен, который отбирает очень много ресурсов»? Как вообще выглядит само приложение изнутри?
@Zaphkiel@Drag13производительность безусловно низкая. Под капотом EntityFramework, которым я пользуюсь в первый раз, ну и в целом программирование для меня это хобби. Поэтому тут проблемы не в Azure, а в не оптимальном коде. Его я собираюсь пересмотреть и улучшить. А сейчас по крайней мере я смог сравнить тарифы между собой и попробовать разные стратегии тестирования на Azure
Используемый в статье вариант — безусловно гибкий, консольное приложение + SQL можно развернуть где угодно, но в этом же и проблема этого теста.
Если же подходить к вопросу с точки зрения «cloud-first», можно было бы:
1) Вместо AppService, воспользоваться Static Web Apps, которые на порядок дешевле. Как понимаю по описанию, какой-то сложной логики на серверной части *клиентского приложения* — нет.
2) Вместо классического SQL — взять Azure Blob Storage, либо CosmosDB. Consumption-based планы обойдутся дешевле при ограниченной аудитории приложения. Да и при большой, чтение одного блоба с данными с Blob Storage — будет дешевле запросов к SQL.
3) Обновление данных с сайтов магазинов — сделать через Azure Function. Из коробки Durability, триггеры срабатывающие по расписанию, опять же Consumption-based биллинг. Учитывая что джоб выполняется раз в сутки и не CPU-heavy — ценник будет небольшой.
Привет! Тестовый агент с SoapUI запускался на локальной станции, на ноутбуке?
Результат в RPS мог получиться скромным из-за запуска теста через интернет. По ряду причин:
исчерпание TCP-подключений, проблема TCP Time Wait в Windows также актуальна, как и в Linux
лимиты сетевого провайдера, иногда это троттлинг (защита от DoS со стороны абонента) иногда просто ограничение пропускной способности
лимиты Azure (защита от DDoS/DoS на стороне площадки)
Скорее всего первая причина
Стоит проверить рекомендации из статьи базы знаний Microsoft:
https://docs.microsoft.com/ru-ru/windows/client-management/troubleshoot-tcpip-port-exhaust
и по возможности повторить замер. Или провести замер, подавая нагрузку со станции внутри кластера.
Также некоторые инструменты не закрывают TCP-подключение к серверу, поэтому они иногда заявляют, что обгоняют по производительности инструменты которые закрывают и открывают снова.
Инструменты, которые закрывают подключения после каждого теста:
Apache.JMeter, но если в конфигурационный файл jmeter.properties внести настройку httpclient.reset_state_on_thread_group_iteration=false, то тоже не будет закрывать
Gatling, но если в настройки http-протокола добавить shareConnections , то тоже не будут, пример.
Инструменты, которые не закрывают подключения:
k6
ab
Как поступает Soap UI не знаю, и не знаю если ли у него настройки для изменения поведения.
Резюмируя: изменение инструмента или его настроек также можно повысить RPS
Добрый день, спасибо за коммент,
Soapui запускался с ноутбука и доводы, которые вы привели действительно важные. Но в моем случае они скорей всего не актуальны по следующим причинам:
Я выставлял на том же приложении статическую страницу и получал по ней несколько десятков rps
Загрузка процессора в службе приложения была близкой к максимуму. Можно посмотреть на сравнительной таблице выше в статье
Может ли быть, что производительность по статической странице выполнялось в ограниченном количестве tcp/ip соединений. Думаю да. Но загрузка процессора службы приложений говорит, что дело в загрузке процессора на серверной стороне.
Ну и просто для информации: SoapUI не закрывает tcp/ip соединение пока не закончит весь тест. Но на сколько помню, это можно параметризировать
Нагрузочное тестирование сайта на Microsoft Azure