переменные сеанса asp.net для хранения всех глобальных данных

Question

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

Правильно ли я беспокоюсь, и если да, то почему? Есть ли простой способ узнать, сколько памяти все это сейчас использует на живом сервере? Каков наилучший подход для перефакторинга, чтобы использовать лучшее решение?

Answer 1

Да, я бы сказал, что у вас есть повод для беспокойства. Чрезмерное использование сеанса может вызвать много проблем с производительностью. В идеале, сеанс должен использоваться только для информации, специфичной для пользователя. Очевидно, есть исключения из этого правила, но имейте это в виду при рефакторинге.

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

Answer 2

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

Answer 3

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

как хранить данные сеанса на сервере SQL: http://msdn.microsoft.com/en-us/library/ms178586.aspx

Суть в том, что классы, хранящиеся на сервере sql, должны быть сериализуемыми, и вы можете использовать json.net для этого.

Answer 4

В целом, да, вы должны быть обеспокоены этим.

Сеанс - это тип хранения «на пользователя», который находится в памяти.Изучение использования памяти в ASP.NET Worker Process даст вам представление об использовании памяти, но вам может понадобиться использовать сторонние инструменты, если вы хотите глубже изучить то, что есть. Кроме того, сессия становится действительно "увлекательной".«когда вы начинаете балансировку нагрузки и т. д.

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

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

Answer 5

Вы правы в том, что беспокоитесь об этом.

Строки подключения должны храниться в Web.config и всегда считываться оттуда. Файл Web.config кэшируется, поэтому хранение вещей тут же и на Session является избыточным и ненужным. То же самое можно сказать и о расположении файлов: вы, вероятно, можете создать пары ключ-значение в разделе appSettings вашего web.config для хранения этой информации.

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

Если получение данных из базы данных занимает много времени, первое, что я бы попытался исправить, - это скорость моих запросов. Я пропускаю индексы? Что показывает план выполнения моих запросов? Я делаю сканирование таблицы и т. Д. И т. Д.

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

Очевидно, что приложение, которое хранит почти все, что может на Session, будет иметь проблемы с масштабируемостью, потому что память является ограниченным ресурсом.

Answer 6

В зависимости от версии IIS использование Session для сохранения состояния может повлиять на масштабирование.Более поздние версии IIS лучше.Однако главная проблема, с которой я столкнулся, заключается в том, что сеансы истекают, а затем ваши данные теряются;Вы можете предоставить свой собственный обработчик Session_OnEnd, где можно восстановить ваш сеанс.

Answer 7

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

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

Затем все, что зависело от предыдущего запроса, я быбыли отправлены этим запросом.

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