Что поместить в переменную сеанса

Question

Недавно я наткнулся на веб-приложение ASP 1.1, которое помещало в переменную сеанса целую кучу вещей, включая все объекты данных БД и даже объект подключения к БД.В конечном итоге он становится огромным.Когда время веб-сеанса истекает (через четыре часа после того, как пользователь завершил работу с приложением), иногда транзакции базы данных откатываются.Я предполагаю, что это связано с тем, что соединение с БД не закрывается должным образом, когда IIS завершает сеанс.

В любом случае, мой вопрос: что должно быть в переменной сеанса?Очевидно, что некоторые вещи должны быть там.Пользователь выбирает, какой план он хочет редактировать на главном экране, поэтому идентификатор плана попадает в переменную сеанса.Лучше ли попытаться уменьшить нагрузку на БД, сохранив все сведения о пользователе (и его менеджере и т. д.) и плане, который они редактируют, в переменной сеанса, или мне следует попытаться свести к минимуму данные в переменной сеанса и запросить у БД все, что мне нужно в событии Page_Load?

Answer 1

На этот вопрос довольно сложно ответить, потому что это очень зависит от приложения, но вот несколько рекомендаций, которые я использую:

1. Вкладывайте в сеанс как можно меньше.
2. Выбор для конкретного пользователя, который должен действовать только во время данного посещения, является хорошим выбором.
3. часто в сеанс также полезно включать переменные, которые должны быть доступны нескольким страницам во время посещения пользователем вашего сайта (чтобы избежать их передачи со страницы на страницу).

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

Answer 2

Делать нет поместите информацию о соединении с базой данных в сеанс.

Что касается кеширования, я бы, по возможности, избегал использования сеанса для кеширования — вы столкнетесь с проблемами, когда кто-то другой изменит данные, которые использует пользователь, плюс вы не сможете делиться кешированными данными между пользователями.Используйте ASP.NET Cache или другую утилиту кэширования (например, Memcached или Velocity).

Что касается того, что должен пойти на сессию, все, что относится к все Окна браузера, которые пользователь открывает на вашем сайте (логин, настройки безопасности и т. д.), должны находиться в сеансе.Такие вещи, как то, какой объект просматривается/редактируется, на самом деле должны быть переменными GET/POST, передаваемыми между экранами, чтобы пользователь мог использовать несколько окон браузера для работы с вашим приложением (если вы не хотите этого предотвратить).

Answer 3

НЕ поместить объекты пользовательского интерфейса в сеанс.

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

Answer 4

В идеале сеанс в ASP должен хранить наименьший объем данных, который вам может сойти с рук.Хранение ссылки на любой объект, который удерживает открытыми системные ресурсы (особенно соединение с базой данных), является явным убийцей масштабируемости.Кроме того, в большинстве случаев хранить незафиксированные данные в переменной сеанса — просто плохая идея.В целом похоже, что текущая реализация злоупотребляет объектами сеанса, чтобы попытаться имитировать приложение с сохранением состояния в предположительно среде без сохранения состояния.

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

Мое практическое правило заключается в том, что чем более масштабируемым (с точки зрения пользователей/обращений) должно быть приложение, тем меньше вам сойдет с рук использование состояния сеанса.Однако существует компромисс.Для веб-приложений, в которых пользователь неоднократно обращается к одним и тем же данным и обычно имеет довольно длительный сеанс при каждом использовании сайта, некоторое кэширование (при необходимости в объектах сеанса) может фактически помочь масштабируемости за счет снижения нагрузки на сервер БД.Идея здесь в том, что гораздо дешевле и проще обрабатывать уровень представления, чем серверную БД.Конечно, в любом случае этот совет следует принимать в умеренных количествах, и он не применим во всех ситуациях, но для довольно простого собственного CRUD-приложения он должен вам сослужить хорошую службу.

Answer 5

А очень похожий вопрос ранее меня спрашивали о сеансах PHP.По сути, сеансы — отличное место для хранения пользовательских данных, к которым вам необходим доступ при нескольких загрузках страниц.Сессии НЕ являются отличным местом для хранения ссылок на соединения с базой данных;вам лучше использовать какое-то программное обеспечение для объединения пулов соединений или открывать/закрывать соединение при каждой загрузке страницы.Что касается кэширования данных в сеансе, это зависит от того, как хранятся данные сеанса, насколько вам нужна безопасность и являются ли данные специфичными для пользователя.Лучше всего было бы использовать что-то другое для кэширования данных.

Answer 6

хранить навигационные подсказки в сеансах сложно.У одного и того же пользователя может быть открыто несколько окон, а затем изменения распространяются запутанным образом.Соединения с БД должны определенно не храниться.ASP.NET поддерживает пул соединений за вас, и вам не придется прибегать к собственному колдовству.Если вам нужно кэшировать данные на короткие периоды времени, а размер набора данных относительно невелик, рассмотрите ViewState как возможный вариант (за счет загрузки большего объема на размер страницы).

Answer 7

А:Данные, относящиеся только к одному пользователю.ИЕ:имя пользователя, идентификатор пользователя.В большинство объект, представляющий пользователя.Иногда данные, относящиеся к URL-адресу (например, куда кого-то взять) или стек сообщений об ошибках полезно отправить в сеанс.

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

Answer 8

Стивен,
Вы работаете в компании, название которой начинается на «I», у которой есть веб-сайт, начинающийся на «BC»?Это похоже на то, что я сделал, когда впервые начал разработку в .net (и был молод и глуп) — я втиснул все, что мог придумать, в сеансы и приложения.Излишне говорить, что это было вдвойне плохо.
В общем, избегайте сеансов, насколько это возможно.Конечно, там не должны храниться несериализуемые объекты (соединения с базой данных и т. д.), но даже большие сериализуемые объекты тоже не должны храниться.Вам просто не нужны накладные расходы.

Answer 9

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