Классический ASP — использование одного соединения для многих запросов?

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

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

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

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

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

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

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

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

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

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

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

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

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