ASP.NET Masters: Каковы преимущества/недостатки использования переменных Session?

Я уже сделал поиск по этому вопросу и снова и снова обнаружил одни и те же данные - обзор трех разных типов сеансов. (InProc, Sql, StateServer) Однако мой вопрос имеет другой характер.

В частности, каковы преимущества/недостатки использования встроенного .NET-сеанса в первую очередь?

Вот почему я спрашиваю: один разработчик .NET сказал мне, что НИКОГДА не используйте встроенный сеанс Microsoft. Не за что. Даже не создать пользовательский поставщик состояния сеанса. Его аргументация заключается в следующем: если вы включили сессию в IIS, все ваши запросы будут выполняться синхронно. Он говорит, что включение сеанса ухудшает производительность веб-сервера.

Его решение заключается в том, чтобы создать сеанс самостоятельно - класс, который хранит все необходимые вам значения и сериализуется в базе данных и выходит из нее. Он советует вам сохранить уникальный идентификатор, чтобы ссылаться на него в файле cookie или переменной запроса. В нашей среде использование БД для хранения сеансов является обязательным требованием, потому что все страницы, которые мы делаем, находятся в веб-фермах, и мы используем Oracle - поэтому я согласен с этой частью.

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

Итак, чтобы подвести итог, каковы преимущества/недостатки?

Спасибо всем, кто отвечает!

Ответ 1

Во-первых, браузер будет выполнять только два запроса до заданного имени хоста в данный момент времени. По большей части эти запросы предназначены для статического контента (файлы JS, CSS и т.д.). Таким образом, сериализация запросов к динамическому контенту не является проблемой, о которой можно подумать. Кроме того, я думаю, что это может быть путано с классическим ASP, где страницы, использующие Session, определенно сериализованы, я не верю, что это относится к ASP.Net.

С состоянием сеанса ASP.Net(режим SQL, государственный сервер или пользовательский) у вас есть стандартная и последовательная реализация во всем приложении. Если вам не нужно делиться информацией о сеансе, это ваш лучший выбор. Если вам нужно обмениваться информацией с другими средами приложений (php, swing/java, classic asp и т.д.), Это может быть полезно рассмотреть.

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

Ответ 2

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

I и многие другие разработчики столкнулись с серьезными проблемами производительности, когда мы ошибочно использовали сеанс для хранения больших объемов данных из базы данных, чтобы "сохранить поездку". Это плохо. Сохранение записей 2000 пользователей за сеанс приведет к тому, что веб-сервер встанет на колени, когда более чем несколько пользователей используют приложение. Сессия не должна использоваться как кэш базы данных.

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

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

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

Ответ 3

Во-первых, вы, коллега, внедряете свою собственную систему управления сессиями, поддерживаемую БД, я не вижу, какую пользу у нее есть, используя встроенное состояние сеанса, хранящееся в базе данных (MS SQL по умолчанию, нет оснований не использовать Oracle вместо этого).

Является ли его решение лучше, чем встроенный? Вряд ли. Для вас это больше подходит для вас. Вот простая иллюстрация почему. Скажем, вы используете файлы cookie для хранения вашего идентификатора, как вы справляетесь с пользователем, который отключает куки? Если вы используете состояние сеанса ASP.Net, нет проблем, так как оно вернется к использованию строки запроса. С идеей ваших коллег вы должны сворачивать свои собственные.

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

Ответ 4

Реализация MS Session State не является злом сама по себе... так используют некоторые разработчики. Как упоминалось выше, использование встроенного провайдера состояния сеанса означает, что вам не нужно повторно изобретать проблемы безопасности, старения и concurrency. Просто не начинайте забивать много мусора в сеансе, потому что вы слишком ленивы, чтобы найти лучший способ управлять переходом состояния и страницы. Сессия не очень хорошо масштабируется... если каждый пользователь на вашем сайте наполняет кучу объектов в сеансе, и эти объекты занимают небольшую часть конечной памяти, доступной вашему приложению, вы столкнетесь с проблемами раньше, чем позже, когда ваше приложение растет популярностью. Используйте сеанс в том виде, в котором он был разработан: токен, представляющий, что пользователь все еще "использует" ваш сайт. Когда вы начинаете выходить за рамки этого, из-за невежества или лень, вы обязательно сожжетесь.

Ответ 5

Вы должны быть разумными при использовании сеанса, так как несколько запросов к одному и тому же объекту сеанса будут обычно поставлены в очередь: см. "Параллельные запросы и состояние сеанса" http://msdn.microsoft.com/en-us/library/ms178581.aspx.

Обратите внимание, что вы можете установить EnableSessionState в ReadOnly, чтобы разрешить одновременный доступ к чтению в состояние сеанса.

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

Я бы не согласился с рекомендацией вашего коллеги "никогда" использовать Сессию, и я, конечно же, не стал бы отказываться от собственного.

Ответ 6

Есть ли проблемы с безопасностью?

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

Ответ 7

домашний сеанс, как вы описали, не делает ничего другого "SQL" состояния сеансов .Net, и по моему опыту я не думаю, что сеанс ухудшает вашу производительность в любом случае. для создания собственного менеджера сеанса потребуется выполнить еще несколько задач по сантехнике: безопасность, очистка и т.д.

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

мы разработали приложение электронной коммерции b2b для компании Fortune 57, которая обрабатывает более 100 тыс. транзакций в день и использует сеансы [режим SQL] достаточно широко, без каких-либо проблем.

Ответ 8

Исправьте меня, если я ошибаюсь:

Основное преимущество хранения состояния сеанса в db, например SQL Server, заключается в том, что вы не потребляете ресурсы памяти, а вместо этого сохраняете его на диске в db.

Недостатком является то, что вы берете IO-хит, чтобы извлекать эту информацию из базы данных каждый раз, когда вам это нужно (или SQL Sever даже делает какое-то волшебное кэширование данных для вас на основе недавно выполненных запросов?)

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