Каковы альтернативы СЕССИИ ПЕРЕМЕННЫХ?

Question

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

Пожалуйста, предоставьте мне альтернативы SESSION ПЕРЕМЕННЫХ

Answer 1

Чтобы понять преимущества не использовать сессии, вы должны понять, как работают сессии.

В настройках по умолчанию,

• сеансов определяются набором печенья в браузере пользователя и
• данные сеанса хранится в памяти на веб-сервере

Когда пользователь отправляет запрос на сервер, cookie сеанса отправляется вместе. Он содержит идентификатор, который использует сервер для определения данных сеанса конкретного пользователя.

Вы можете настроить ASP.NET для

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

Теперь о преимуществах отключения состояния сеанса:

1. ASP.NET обеспечивает доступ к данным сеанса потокобезопасным путем сериализации запросов. Это означает, что когда состояние сеанса включено, ASP.NET отказывается обслуживать одновременные запросы от одного и того же пользователя. Это особенно актуально, когда браузер пользователя делает много запросов ajax. Эту проблему можно смягчить, отметив состояние сеанса только для чтения для запросов, где вам не нужно его обновлять.
2. Когда запрос приходит, ASP.NET должен извлекать данные сеанса, и он должен записывать данные после завершения запроса. Это может быть не большой проблемой, если состояние сеанса хранится в памяти, но если данные хранятся в центральной базе данных, это может вызвать серьезные проблемы с производительностью.

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

Для получения дополнительной информации см

1. ASP.NET Session State Overview
2. Fast, Scalable, and Secure Session State Management for Your Web Applications

(что последняя статья немного устарела, но все-таки хорошо читать).

Альтернативы

• Если вы можете избежать состояния сеанса в целом.
• Если вам абсолютно необходимо связать данные с пользователем, используйте механизмы HTTP и сделайте браузер переносимым данные в файл cookie или, возможно, параметр запроса (отчасти это относится ко всему движению REST).

Надеюсь, что это поможет.

Answer 2

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

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

Экземпляр каждой переменной сеанса создается, когда пользователь посещает страницу, и эти переменные сохраняются в течение 20 минут ПОСЛЕ того, как пользователь покидает страницу! (Фактически, эти переменные сохраняются до тех пор, пока они не «тайм-аут». Эта длина таймаута задается администратором веб-сервера. Я видел сайты, в которых переменные будут рушиться всего за 3 минуты, а другие, которые сохраняются на 10, а третьи - сохраняйте значение по умолчанию 20 минут.) Итак, если вы помещаете какие-либо большие объекты в сеанс (например, наборы записей ADO, соединения и т. д.), вы требуете серьезных проблем! По мере увеличения числа посетителей ваш сервер будет испытывать резкие беды производительности, размещая большие объекты в сеансе!

Answer 3

Плюсы и минусы переменных сессии See Here

Answer 4

Это зависит от бизнес-логики вашего приложения, в некоторых случаях сеанс может быть лучшим выбором, однако есть много альтернатив. Сессия должна использоваться, если у вас есть разные данные для каждого запроса в вашем приложении, вы можете публиковать сообщения ваши данные в скрытых полях с вашими формами, но снова ур вопрос немного дорожки, вы должны проанализировать свое требование, чем в соответствии с ним вы должны решить, использовать ли сеансы или какое-то другое альтернативное решение, если мне нужно хранить Идентификатор пользователей, чем определенно, я пойду на сеансы, потому что они будут разными для каждого пользователя, я не буду хранить очень большие данные в сеансе, например, сохраняя набор данных в сеансе, который мало кто делает. Затем также возникают вопросы, если ур использует сеанс, где вы хотите сохранить его в процессе или на сервере, если ур сохраняет сеанс на сервере, это очень дорого, но в ssome-сценариях это очень полезно.