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

Question

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

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

Answer 1

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

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

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

Answer 2

DO NOT put UI objects in session.

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

Answer 3

Do не информация о подключении к базе данных в сеансе.

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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