Классический ASP - используя одно соединение для множества запросов?

Question

Рассмотрим классический сайт ASP, работающий на IIS6 с выделенным бэкэндом SQL Server 2008 ...

Сценарий 1:

Открытое соединение
Выполните 15 запросов, обновлений и т. Д. По всей ASP-странице
Закрыть соединение

Сценарий 2:

Для каждого запроса, обновления и т. Д., Открывайте и закрывайте соединение

---

При пуле соединений мои деньги были бы на сценарии 2 наиболее эффективным и масштабируемым.

Буду ли я прав в этом предположении?

Редактировать: Больше информации

Это операции с базой данных, распределенные по большому количеству asp-кода в отдельных функциях, выполняющие отдельные операции и т. Д. Это не 15 запросов, выполняемых в быстрой последовательности. Подумайте о большом сайте с множеством функций, включением и т. Д.

Answer 1

По сути, ASP страницы синхронны. Так почему бы не открыть соединение один раз для загрузки страницы, а закрыть его один раз для загрузки страницы? Все другие открытия / закрытия кажутся ненужными.

Answer 2

Если я вас правильно понимаю, вы рассматриваете возможность совместного использования объекта соединения между сложным кодом, содержащимся в различных функциях, в различных включениях.

При таком сценарии это было бы плохой идеей. Становится трудно гарантировать правильное состояние и настройки соединения, если другой код мог столкнуться с необходимостью их изменения. Также иногда вы можете иметь код, который извлекает набор записей пожарного шланга и не завершил обработку, когда вызывается другой фрагмент кода, который также нуждается в соединении. В таком случае вы не можете поделиться подключением.

Было бы лучше, если бы каждый атомарный кусок кода получал свое собственное соединение. Соединение будет в чистом известном состоянии. Несколько соединений при необходимости могут работать параллельно. Как отмечали другие, стоимость создания соединения практически полностью снижается за счет базового пула соединений.

Answer 3

Рекомендуется один раз открыть соединение, прочитать все ваши данные и как можно скорее закрыть соединение. После того как вы закрыли соединение, вы можете делать то, что вам нравится с данными, которые вы получили. В этом случае вы не открываете слишком много соединений и не открываете соединение слишком долго.

Даже если в вашем коде есть вызовы из базы данных в нескольких местах, накладные расходы на создание соединения будут хуже, чем ожидание - разве вы говорите, что вашей странице требуется много секунд для создания на стороне сервера? Обычно, даже без контролируемого доступа к данным и со многими функциями, ваша страница должна генерироваться менее чем за секунду для генерации на сервере.

Answer 4

в вашем Сценарии 2 существует обратная связь между вашим приложением и SQLServer для выполнения каждого запроса, который потребляет ресурсы вашего сервера и время общего выполнения увеличится.
но в Сценарии 1 есть только один прием, и SQLServer выполнит все запросы всего за один раз. так что это быстрее и менее ресурсоемко

РЕДАКТИРОВАТЬ: ну, я думал, вы имеете в виду несколько запросов в один раз ..
поэтому при включенном пуле соединений проблем с закрытием соединения после каждой транзакции точно не возникает. так что идите со Сценарием 2

Answer 5

С точки зрения производительности нет заметной разницы. ADODB пул соединений управляет фактическими соединениями с БД. Adodb.connection .open и .close - это просто фасад для пула соединений. Создание 1 или 15 объектов adodb.connection на самом деле не влияет на производительность. Прежде чем использовать транзакции, мы использовали строку подключения в сочетании с adodb.command (.activeConnection) и никогда не открывали и не закрывали подключения явно.

Причинами явного сохранения ссылки на adodb.connection являются транзакции или функции на основе соединения, такие как mysql last_inserted_id (). В этих случаях вы должны быть абсолютно уверены, что получаете одно и то же соединение для каждого запроса.

Answer 6

Я считаю, что пул соединений по умолчанию составляет около 20 соединений, но SQLServer может обрабатывать намного больше. Получение соединения с сервера занимает больше всего времени (при условии, что вы ничего не делаете с вашими командами), поэтому я не вижу ничего плохого в том, чтобы получить соединение на страницу и убить его при последующем использовании.

Для масштабируемости вы можете столкнуться с проблемами, когда ваш пул соединений становится слишком занятым и время ожидания истекло, пока ваш сценарий ожидает, пока соединение не станет доступным, в то время как ваша БД находится там со 100 запасными соединениями, но никто их не использует. *

Создавай и убивай на одной странице и получай мой голос.