ASP.NET Session - использовать или не использовать и лучшие практики для приложения электронной коммерции

Question

Я использовал ASP.NET в основном в сценариях интрасети и довольно хорошо знаком с ним, но для чего-то, например, корзины покупок или подобных данных сеанса, существуют различные возможности.Вот несколько имен:

1) Сессия State-Server

2) Сессия SQL Server

3) Сеанс пользовательской базы данных

4) Cookie

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

Я не упомянул in-proc , поскольку в крупномасштабном приложении этого нет места.

Большое спасибо Али

Answer 1

Самым большим уроком, который я выучил, был тот, который я уже знал в теории, но увидел на практике.

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

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

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

Answer 2

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

Использование сервера Sql - лучший вариант, потому что возможны сеансы с неограниченным сроком действия.Однако необходимо учитывать стоимость сервера, места на диске, его обслуживания и производительности.Я использовал его в своем приложении для электронной коммерции в течение нескольких лет, пока мы не сменили поставщиков на одного с очень небольшим пространством базы данных.Было обидно, что это должно было пойти.

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

Когда я работал в крупной компании, мы использовали кластерный SQLСервер в другом приложении, которое было более важным, чтобы оставаться в сети.У нас было многократное резервирование в каждой части системы, включая сетевые карты.Имейте в виду, что добавление сервера состояний или службы добавляет потенциальную единственную точку отказа для приложения, если только вы не идете по кластерному маршруту, который обходится дороже.

Была также проблема, когда мы впервые переключилиськ подходу на основе SQL, где двоичные объекты не могут быть сериализованы в состояние сеанса.У меня их было всего несколько, и я изменил код, чтобы он не нуждался в двоичной сериализации, чтобы я мог получить сайт в Интернете.Однако, когда я вернулся, чтобы исправить проблему сериализации несколько недель спустя, она внезапно перестала существовать.Я предполагаю, что это было исправлено в Центре обновления Windows.

Answer 3

In-proc, безусловно, может иметь место в крупномасштабном приложении; это просто требует липких сессий на уровне балансировки нагрузки. Фактически, снижение затрат на обслуживание и затраты на инфраструктуру при использовании внутрипроцессных сеансов может быть значительным. Любой коммутатор контента корпоративного уровня, который вы будете использовать перед своей фермой, несомненно, будет предлагать такую ​​функциональность, и трудно поспорить с деньгами и рабочей силой на покупку / настройку / интеграцию серверов состояний по сравнению с простым переключением коммутатора. Я использую это в довольно крупных масштабируемых системах ASP.NET без проблем, чтобы говорить о. Оперативная память слишком дешевая, чтобы игнорировать это в качестве опции.

Answer 4

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

In proc ненадежен (и вы упомянули это), поэтому это не учитывается.

Cookies на самом деле не являются заменой состояния сеанса, поскольку вы не можете хранить там много данных

Я голосую за хранилище на основе базы данных (если оно вообще необходимо), оно имеетлучшая возможность для масштабирования.