Подтвердить что ты не робот

Почему неплохо использовать сеанс для хранения состояния на сайтах с высоким трафиком?

Я наблюдаю, как ASP.NET учит видео на asp.net/learn. В этом уроке они строят двигатель викторины. В какой-то момент рассказчик объясняет, что мы будем использовать объект Session для поддержания состояния между каждой страницей (каждая страница содержит вопрос и четыре ответа). Он говорит, что "поскольку это веб-сайт с низким трафиком", можно использовать сессию и что у него нет времени для внедрения более сложного метода.

Мне просто интересно, к чему он намекает альтернативный метод (ы)? И почему сеанс плохой выбор для сайта с высоким трафиком?

4b9b3361

Ответ 1

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

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

Ответ 2

Для альтернатив вы можете прочитать статью Девять параметров управления постоянным состоянием пользователя в приложении ASP.NET.

В статьях автор объясняет плюсы и минусы каждого метода.

Из резюме:

ASP.NET предоставляет множество способов для сохранения данных между пользовательскими запросами. Вы можете использовать объект Application, куки, скрытые поля, сеанс или Кэш-объекты и множество других методы. Решая, когда использовать каждый из иногда это может быть затруднено. Эта статья представит вышеупомянутые методы и настоящие некоторые рекомендации о том, когда их использовать. Хотя многие из этих методов существует в классическом ASP, передовой практике когда их использовать введение .NET Фреймворк. Чтобы сохранить данные в ASP.NET, вам придется настроить то, что вы изучили ранее о состоянии обработки в ASP.

Ответ 3

Данные сеанса хранятся в ОЗУ сервера, если у вас есть сайт с высоким трафиком, который будет полностью реален, и последнее, что вы хотите, это то, что данные заменяются на диск.

Как говорит gaijin42, альтернативными могут быть файлы cookie или DB.

Ответ 4

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

Во-первых, метод хранения сеанса по умолчанию находится в процессе, что означает, что если у вас есть сбалансированная по нагрузке веб-ферма, вы будете постоянно "потерять" информацию о сеансе, поскольку пользователь получает страницы, обслуживаемые с разных серверов.

Сервер сеанса In-proc также умирает, когда пул приложений перерабатывается, что происходит чаще на более высоких серверах трафика.

Параметры масштабирования для данных сеанса

  • Использовать свободно доступную ASP.NET Session Server и укажите все ваши приложения на нем
  • Используйте SQL Server для хранения данных сеанса.

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

Ответ 5

Для сайтов с высоким трафиком вы можете посмотреть Memcached. Это кэширующий меканизм, который хранится в ОЗУ удаленного компьютера. Совсем недавно из библиотеки был создан win32-порт (возможно только с linux).

Ответ 6

Я не буду повторять то, что уже упоминалось здесь, но другая альтернатива использует хеш приложения. Его следует использовать экономно, поскольку он будет потреблять память на вашем веб-сервере, как уже упоминал Адам, но он обеспечивает хороший способ кэширования вещей, которые являются общими для ВСЕХ ваших пользователей.

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

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

Вот некоторые ссылки в случае, если вам интересно: ASP NET кэширование Состояние приложения

Ответ 7

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