Каков наилучший способ управлять своими переменными сеанса?

Question

В моем веб-приложении .NET я сохраняю основную информацию пользователя в объекте сеанса пользователя. Я также обычно держу класс режиссера в сеансе; который в основном просто имеет информацию о том, что на нем работает, на этом экране (например, идентификатор клиента).

Я стараюсь не добавлять тонны сеансов. Я также хочу убедиться, что в любой момент времени ТОЛЬКО требуемые сеансы находятся в памяти.

Это означает, что мне нужен эффективный способ управления моими переменными сеанса. Какие-либо предложения?

Answer 1

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

Answer 2

Мое предложение: не используйте переменные сеанса. Храните все в базе данных.

Answer 3

Две вещи:

1 - Вы не должны хранить столько сессии, что управление памятью является проблемой. I.e., не хранить объекты в сеансе, хранить указатели на вещи, например, а не экземпляр пользователя, просто сохраняя UserID. Если вам нужно, вы можете добавить кэширование извлечения информации, но это должно быть в кешированном слое отдельно от сеансов.

2 - сессий Использование базы данных, так что нет никакого беспокойства о памяти сервера, и таким образом, что вы можете добавить несколько веб-серверов легко при желании (примечание, StateServer дает такую ​​возможность, а). Кроме того, это позволяет вам повторно использовать пул приложений, не теряя при этом их сеанс. Это основная причина, по которой я это делаю - это позволяет мне развертываться «на лету».

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

В идеале нет необходимости в управлении сеансами.

Answer 4

Я думаю, что вы не понимаете сессий в ASP.NET. Вы явно не управляете ими (хотя, возможно, вы этого редко хотели бы), они неявно создаются и уничтожаются ASP.NET и IIS. Каждому пользователю предоставляется сеанс.

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

Единственные данные, которые необходимо сохранить в сеансе, - это временные данные, которые вы хотите получить в разных запросах страниц, которые вы хотите защитить, чтобы они не были доступны клиенту в cookie или аналогичной конструкции.

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

Answer 5

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

Answer 6

Мое предложение:

• Wrap доступ сессии в интерфейс IPerSessionCache
• Иметь конкретную реализацию этого интерфейса
• использовать instace конкретного класса в коде, чтобы получить/установить сеанс данные
• При этом у вас есть свобода для очистки экземпляра IPerSessionCache при завершении сеанса
• Код не должен знать, где находится IPerSessionCache фактически хранит данные (т.е. она могла бы в сессии или в базе данных или в печенье и т.д.)
• Вы бы лучше контролировать на время жизни IPerSessionCache особенно если вы используете DI контейнер для управления & создания экземпляра

НТН ,