SQL server deadlocks

Добрый день!

Возник очередной вопрос, на тему аутентификации в тестируемом приложении и LR.

Суть: тестируемое приложение общается с SQL server по ODBC. В само приложение доступ осуществляется по связке логин-пароль.
Через администраторскую консоль я завел специального юзера, начал запись скрипта, залогинился в приложение.
Далее, в LR Controller'e создаю сценарий, в котором задаю количество пользователей, равное 25. Запускаю тестирование и спустя некоторое время получаю ошибки

"SQL SERVER – Fix : Error 1205 : Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction"

Вопросы:
Что происходит, при запуске теста с точки зрения SQL сервера - он считает, что в него ломятся 25 человек, вводящих одинаковую связку логин-пароль?
Отчего, в принципе возникают дедлоки - косяки в механизмах тестируемого ПО или, к примеру, SQL серверу недостает ресурсов?

P.S. Интереса ради, завел второго тестового юзера в тестируемой софтине, в Controller'e задал две группы пользователей, 10 штук на первого тестового пользователя, 15 на второго. Проблем с деадлоками не возникло. Не получится ли так, что для получения "честных" результатов тестирования мне придется заводить 25 тестовых пользователей в софтине и по отдельности добавлять их в сценарий теста LR Controller'a?

Благодарю за ответы!

Добрый день!


Что происходит, при запуске теста с точки зрения SQL сервера - он считает, что в него ломятся 25 человек, вводящих одинаковую связку логин-пароль?
Отчего, в принципе возникают дедлоки - косяки в механизмах тестируемого ПО или, к примеру, SQL серверу недостает ресурсов?

Благодарю за ответы!

Не скажу точно за ODBC, но использование разных логин/пароль для тестирования - есть трупрактика :)
Точно могу сказать, если тестировать с помощью Citrix протокола и не параметризировать учётные записи, то все пользователи будут ломиться в одну сессию.. что вызовет сбой выполнения скрипта. Кто-то раньше, кто-то позже залогинился и начинает делать действия с опозданием.., синхронизация по image слетает сразу же)
Возможно, в ODBC происходит тоже самое ;)

Дедлок в данном случае происходит потому, что потоки пытаются обновить одну и ту же запись. Это все же ошибка приложения.

Дедлок в данном случае происходит потому, что потоки пытаются обновить одну и ту же запись. Это все же ошибка приложения.

Меня смущает, что если я снижаю мультипликатор для первого вюзера до 23х, то тест отрабатывается на ура.
Если я ставлю, скажем, 15 вюзеров, соответствующих первому тестовому юзеру тестируемого ПО и 8 вюзеров для второго тестового юзера, то тоже все в порядке.
Также все ок, если их будет по 23 на каждого тестового юзера, т.е. всего 46 вюзеров.

Однако же, если выставить, например 25 вюзеров "первого типа" и до 23х вюзеров "второго типа", то опять вылезают дедлоки.

Ради эксперимента завел 5 тестовых пользователей тестируемого ПО, если на каждого выставлять не больше 23х вюзеров, то все в порядке, тест идет нормально со 115-ю вюзерами.

Где же косяк?

Где же косяк?

Можно попробовать залоггировать действия на стороне приложения и посмотреть где именно дедлок.
Вы можете сделать это сами или попросить программистов, чтобы они вылавливали Error 1205 и выдавали trace (подробное сообщение о том, где вызвана эта ошибка).

В порядке эксперимента, было создано 25 тестовых пользователей ПО, каждому был назначен один vuser.
При одновременном запуске этих vusers при тесте проблем с дедлоками не возникало. О чем это может говорить?

В порядке эксперимента, было создано 25 тестовых пользователей ПО, каждому был назначен один vuser.
При одновременном запуске этих vusers при тесте проблем с дедлоками не возникало. О чем это может говорить?

Возможно, что проблема возникает в следствии определённых условий.. попробуйте вставить точки рэндэву перед каждой операцией с БД :) И посмотреть, что из этого получится)