Size: a a a

QA — Load & Performance

2019 November 05

VG

Viktor Ganeles in QA — Load & Performance
Июля
У меня ещё вопрос. Может, кто знает почему у моих графиков "провалы в памяти" ))))
Количество коннектов к sql можно мониторить на стороне sql server, но там оно не разбито на клиентов.

На стороне клиентов я его мониторил командой
Netstat -o -n -b | find “1433” | find “ESTABLISHED”
источник

VG

Viktor Ganeles in QA — Load & Performance
А результаты в сводную табличку excel
источник

VG

Viktor Ganeles in QA — Load & Performance
Но такой рост коннектов под нагрузкой и правда говорит и вероятных проблемах в приложении
источник

VG

Viktor Ganeles in QA — Load & Performance
Сходу несколько предположения по архитектуре проблем:

1) транзакционность: приложение коннектится к бд, потом выполняет свой код, который подтупливает под нагрузкой (например, расчитывает данные, которые надо сунуть в бд), потом суёт их в бд и отключается.

Если ресурсов не хватает - выполнение кода замедляется и коннекты простаивают.

Выявляется профилированием (я использовал dotTrace, скрин как это выглядит сейчас скину)


2) неверная работа с пулом коннектов: каждый пользователь системы порождает отдельный коннект к бд.
Больше пользователей = больше коннектов. Выявляется тестом или беседой с разработчиками :)

3) приложение перегружено и медленно забирает данные, которые sql server готов отдавать. Надо меньше хранить в sql server бинарей.
Выявляется изучением статистики ожиданий: будет много «network async io»
источник

c

care1e55 in QA — Load & Performance
Июля
Ура, решили мою проблему. Для анализа запросов к БД воспользовалась solarwinds. Но оказалось, что проблема не в базе. Всё же пришлось замучать админа и по логам разобраться что к чему. Вроде как количество запросов было больше лимита (какая-то настройка в .net core). Админ в конфиге приложения поменял max pool size со  100 на 2000 и тесты заработали. Но у меня не хватило знаний, чтобы разобраться самой :( Хорошо, что у меня крутой админ-девопс.
Много соединений к бд это не есть хорошо со стороны приложения. Почти наверняка можно обойтись меньшим кол-вом, и обратить внимание на другие параметры, например таймаут, размер и тип очереди (если есть). Также проблема может быть не в конекшн пуле, а например в тредпуле приложения. Не исключено, что соединение может и блокироваться
источник

c

care1e55 in QA — Load & Performance
полезное чтиво видео на тему      https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
источник

VG

Viktor Ganeles in QA — Load & Performance
❄Июля❄

Вот тут видно, что на работу с sql уходило 921 ms, но на самом деле 920 из них шёл расчёт хэша что бы положить его в базу. Коннект всё это время простаивал.
источник

VG

Viktor Ganeles in QA — Load & Performance
источник

c

care1e55 in QA — Load & Performance
И тюнинг возможен не только со стороны приложения, но и, очевидно, со стороны бд - размер кэша, кол-во воркеров и то же максимальное кол-во конектов
источник

VG

Viktor Ganeles in QA — Load & Performance
care1e55
И тюнинг возможен не только со стороны приложения, но и, очевидно, со стороны бд - размер кэша, кол-во воркеров и то же максимальное кол-во конектов
Хикари крутые :)
источник

VG

Viktor Ganeles in QA — Load & Performance
Но у июли NetCore+SQLServer, как я понял. Хотя всё равно стоит изучить :)
источник

И

Июля in QA — Load & Performance
care1e55
Много соединений к бд это не есть хорошо со стороны приложения. Почти наверняка можно обойтись меньшим кол-вом, и обратить внимание на другие параметры, например таймаут, размер и тип очереди (если есть). Также проблема может быть не в конекшн пуле, а например в тредпуле приложения. Не исключено, что соединение может и блокироваться
Спасибо. Пойду копать.
источник

И

Июля in QA — Load & Performance
Viktor Ganeles
Но у июли NetCore+SQLServer, как я понял. Хотя всё равно стоит изучить :)
Да! Верно!
источник

И

Июля in QA — Load & Performance
А эта сводка откуда? Я имею в виду скриншот откуда снят? )
источник

VG

Viktor Ganeles in QA — Load & Performance
DotTrace
источник

VG

Viktor Ganeles in QA — Load & Performance
Профилировал им приложение на .NetCore
источник

VG

Viktor Ganeles in QA — Load & Performance
Глянь выше я про возможные причины проблем написал
источник

VG

Viktor Ganeles in QA — Load & Performance
Viktor Ganeles
Сходу несколько предположения по архитектуре проблем:

1) транзакционность: приложение коннектится к бд, потом выполняет свой код, который подтупливает под нагрузкой (например, расчитывает данные, которые надо сунуть в бд), потом суёт их в бд и отключается.

Если ресурсов не хватает - выполнение кода замедляется и коннекты простаивают.

Выявляется профилированием (я использовал dotTrace, скрин как это выглядит сейчас скину)


2) неверная работа с пулом коннектов: каждый пользователь системы порождает отдельный коннект к бд.
Больше пользователей = больше коннектов. Выявляется тестом или беседой с разработчиками :)

3) приложение перегружено и медленно забирает данные, которые sql server готов отдавать. Надо меньше хранить в sql server бинарей.
Выявляется изучением статистики ожиданий: будет много «network async io»
.
источник

И

Июля in QA — Load & Performance
Я всё скопипастила себе в блокнот, и каждый пункт сейчас буду перебирать!❤️
источник

И

Июля in QA — Load & Performance
ой, сердце случайно, сори
источник