Мой профиль трассировки показывает, чтоexec sp_reset_connection вызывается между каждым вызовом sql пакета или процедуры. Естьпричины этого, но можно ли предотвратить его вызов, если я уверен, что в этом нет необходимости, для повышения производительности?

ОБНОВЛЕНИЕ: причина, по которой я думаю, что это может улучшить производительность, в два раза:

SQL Server не нужно сбрасывать состояние соединения. Я думаю, что это было бы относительно незначительным улучшением.Снижение задержки в сети, потому что клиент не должен отправлятьexec sp_reset_connection, дождитесь ответа, затем отправьте все, что он действительно хочет выполнить.

Второе преимущество - это то, что меня интересует, потому что в моей архитектуре клиенты иногда находятся на некотором расстоянии от базы данных. Если каждый пакет sql или rpc требует двойного приема, это удваивает влияние любой задержки в сети. Устранение таких двойных вызовов может потенциально улучшить производительность.

Да, есть много других вещей, которые я мог бы сделать, чтобы улучшить производительность, например, реструктурировать приложение, и я большой поклонник решения основной причины проблем, но в этом случае я просто хочу знать, если этовозможный чтобы не вызывать sp_reset_connection. Затем я могу проверить, есть ли улучшение производительности и правильно оценить риски, не вызывая это.

Это вызывает другой вопрос: действительно ли сетевое взаимодействие с sp_reset_connection происходит, как я обрисовал выше? т.е. отправляет ли клиентexec sp_reset_connection, дождаться ответа, а затем отправить реальный sql? Или все это идет одним куском?