Что положить в переменную сеанса - PullRequest
6 голосов
/ 17 сентября 2008

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

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

Ответы [ 9 ]

5 голосов
/ 17 сентября 2008

Do not помещает информацию о соединении с базой данных в сеанс.

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

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

5 голосов
/ 17 сентября 2008

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

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

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

2 голосов
/ 17 сентября 2008

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

помимо этого, я бы сказал, что это меняется. слишком большое количество сеансов может замедлить работу, если вы не используете сеанс in-process, потому что вы собираетесь много сериализовать + скорость провайдера. Cache и Session следует использовать с осторожностью и осторожностью. Не просто положите в сессию, потому что вы можете или это удобно. Садитесь и анализируйте, если это имеет смысл.

1 голос
/ 17 сентября 2008

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

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

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

0 голосов
/ 24 сентября 2008

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

0 голосов
/ 17 сентября 2008

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

0 голосов
/ 17 сентября 2008

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

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

0 голосов
/ 17 сентября 2008

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

0 голосов
/ 17 сентября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...