Почему это - плохая идея использовать Сессию для хранения состояния в веб-сайтах интенсивного трафика?

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

Как говорит gaijin42, куки или БД являются альтернативой.

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

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

Внутрипроцессный сеансовый сервер также умирает при перезапуске пула приложений, что чаще происходит на серверах с более высоким трафиком.

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

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

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

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

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

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

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

Вот несколько ссылок, если вам интересно: ASP NET Caching Application State

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

1. НИКОГДА не используйте $ _ GET или $ _ POST , не проверив и не очистив его.
2. Прочтите о том, как настроить php.ini ] правильно.
3. Никогда не помещайте переменные в необработанный SQL.
4. Если вы используете фреймворки, используйте те, у которых меньше зависимостей.
5. Прекратите чрезмерное обобщение.
6. Распределите ваш код по php-файлам. В большинстве случаев нет реальной необходимости помещать все в один index.php .
7. Уменьшить сложность перед написанием кода.
8. Уважайте тот факт, что это веб-приложение. (Попробуйте быть RESTful .) Это не настольное приложение. Поэтому прекратите помещать все в $ _ SESSION .
9. Как минимум одна строка комментария на каждые 10 строк кода. Вы прочитаете это через год. Обещаю!
10. Код как девушка - сделай так, чтобы ей было приятно читать. сохранять данные между запросами пользователей. Вы можете использовать объект приложения, куки, скрытые поля, сеанс или Кэшировать объекты и многое другое методы. Решая, когда использовать каждый из иногда это может быть сложно. это статья представит вышеупомянутые методы и настоящее некоторые рекомендации о том, когда их использовать. Хотя многие из этих методов существовал в классическом ASP, лучшие практики когда их использовать изменилось с введение .NET Фреймворк. Чтобы сохранить данные в ASP.NET, вам придется скорректировать то, что вы узнали ранее о состоянии обработки в ASP.