Я наблюдаю, как ASP.NET учит видео на asp.net/learn. В этом уроке они строят двигатель викторины. В какой-то момент рассказчик объясняет, что мы будем использовать объект Session для поддержания состояния между каждой страницей (каждая страница содержит вопрос и четыре ответа). Он говорит, что "поскольку это веб-сайт с низким трафиком", можно использовать сессию и что у него нет времени для внедрения более сложного метода.
Мне просто интересно, к чему он намекает альтернативный метод (ы)? И почему сеанс плохой выбор для сайта с высоким трафиком?
Хранение данных в базе данных или в файлах cookie или другом методе, который напрямую не связывает память веб-сервера.
В дополнение к загрузке сеанс также вызывает проблемы с возможностью использования ферм, поскольку вам нужно либо синхронизировать сеанс по ферме, либо делать сеансы липкими, что может повлиять на масштабируемость.
Для альтернатив вы можете прочитать статью Девять параметров управления постоянным состоянием пользователя в приложении ASP.NET.
В статьях автор объясняет плюсы и минусы каждого метода.
Из резюме:
ASP.NET предоставляет множество способов для сохранения данных между пользовательскими запросами. Вы можете использовать объект Application, куки, скрытые поля, сеанс или Кэш-объекты и множество других методы. Решая, когда использовать каждый из иногда это может быть затруднено. Эта статья представит вышеупомянутые методы и настоящие некоторые рекомендации о том, когда их использовать. Хотя многие из этих методов существует в классическом ASP, передовой практике когда их использовать введение .NET Фреймворк. Чтобы сохранить данные в ASP.NET, вам придется настроить то, что вы изучили ранее о состоянии обработки в ASP.
Данные сеанса хранятся в ОЗУ сервера, если у вас есть сайт с высоким трафиком, который будет полностью реален, и последнее, что вы хотите, это то, что данные заменяются на диск.
Как говорит gaijin42, альтернативными могут быть файлы cookie или DB.
Сессия как метод хранения данных является грубой в системах с высокой пропускной способностью по нескольким причинам.
Во-первых, метод хранения сеанса по умолчанию находится в процессе, что означает, что если у вас есть сбалансированная по нагрузке веб-ферма, вы будете постоянно "потерять" информацию о сеансе, поскольку пользователь получает страницы, обслуживаемые с разных серверов.
Сервер сеанса In-proc также умирает, когда пул приложений перерабатывается, что происходит чаще на более высоких серверах трафика.
Параметры масштабирования для данных сеанса
Из-за характера данных сеанса в целом, ни один из них не является очень хорошим вариантом для сайта с очень высоким трафиком (если у вас нет неограниченных денег, чтобы бросить на аппаратное обеспечение).
Для сайтов с высоким трафиком вы можете посмотреть Memcached. Это кэширующий меканизм, который хранится в ОЗУ удаленного компьютера. Совсем недавно из библиотеки был создан win32-порт (возможно только с linux).
Я не буду повторять то, что уже упоминалось здесь, но другая альтернатива использует хеш приложения. Его следует использовать экономно, поскольку он будет потреблять память на вашем веб-сервере, как уже упоминал Адам, но он обеспечивает хороший способ кэширования вещей, которые являются общими для ВСЕХ ваших пользователей.
Это не даст вам вернуться в вашу базу данных, чтобы получить информацию, которая, скорее всего, уже была запрошена кем-то другим.
Другой альтернативой, подобной Application, является Cache, который имеет большую гибкость с точки зрения того, когда он освобождается, длительность и т.д.
Вот некоторые ссылки в случае, если вам интересно: ASP NET кэширование Состояние приложения
Мы используем базу данных для любого высокого трафика или это приведет к большому состоянию сеанса. Вместо этого мы сохраняем указатель в реальном сеансе, который указывает на нашу запись в базе данных. Тогда только накладные расходы у нас есть пропускная способность между веб-сервером и сервером базы данных, который будет намного меньше, чем между любым пользователем и веб-сервером.