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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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