У меня два сервера, один - SQL Server, а другой - веб-сервер с установленным IIS.
Мне нужно было бы найти странную, по общему признанию, информацию: сколько времени веб-сервер в целом тратит в течение дня на установление соединений с SQL Server?
Чтобы дать вещам немного больше контекста ...
Проблема в том, что наше текущее веб-приложение настолько плохо спроектировано, что оно выполняет тысячи запросов даже для самой простой задачи: пользователь нажимает кнопку, и, вуаля, через 3 минуты и 70 тысяч вызовов выдается результат. Это явно плохо, и я хочу, чтобы компания решила эту проблему, но я также хочу получить некоторые цифры.
Я хочу извлечь здесь, сколько общего времени ежедневно тратится на процесс подключения - как на подключение, так и на отключение - без учета времени, затраченного на ожидание самого ответа.
Допустим, общение идет следующим образом:
Я бы хотел получить в сумме 1 + 2 + 5, включая задержку, для каждого обмена данными между двумя серверами в течение всего дня. Возможно? Невозможно?
Существуют и другие характеристики, связанные с сетью, которые вы не оцените ПОСЛЕ установления соединения. В частности, эффект задержки приема-передачи, но также и медленный запуск TCP.
Вы сможете избежать большей части медленного старта и накладных расходов на соединение, используя пул соединений (я могу ошибаться ... детали реализации и все такое), но самая большая проблема будет в том, что ваша производительность будет очень плохо масштабироваться, чем дальше вы получите с сервера.
70к запросов - это большое количество. Отправьте эхо-запрос на ближайшую к вам машину в сети. Теперь проверьте связь с машиной в другой части сети. Скажем, это похоже на разницу между небольшой сетью SoHO и большой сетью, где клиентское приложение, например, находится на рабочем столе пользователя, а база данных находится на сервере базы данных в центре обработки данных.
Теперь, сколько TCP-циклов в среднем требуется для одного из этих запросов. Теперь работайте и сколько обходов, и, следовательно, общее время, потраченное на ожидание обходов.
Это хорошая причина, по которой клиентское приложение и база данных - плохая идея; вам нужен компонент сервера приложения, который находится рядом с базой данных, чтобы бизнес-логика и база данных всегда были рядом.