Состояние сессии ASP.Net

Question

Мне было интересно, можно ли изменить sqlConnectionString, используемый для SessionState в ASP.net, в зависимости от домена, на котором запущено приложение?

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

При просмотре www.domain1.com приложение обращается к базе данных 'db1'. Сайт www.domain2.com, с другой стороны, общается с базой данных «db2» и т. Д., Выбирая соответствующий контент и распределяя нагрузку на каждую базу данных, а не используя одну основную базу данных для обработки всех соединений для сайтов.

Однако возникла проблема - для этой настройки мы используем режим SqlServer для SessionState, поэтому все пользователи всех сеансов сайтов хранятся в 1 базе данных aspstate, теперь, когда сайты становятся более занятыми / число сайтов увеличивается, эта база данных увеличивается постарайтесь обработать все запросы сеанса для всех сайтов, и мы начинаем получать ошибки тайм-аута, когда соединения с этой базой данных являются узким местом.

Мы можем отделить сайты от их собственного приложения и настроить различные приложения с одним и тем же кодом, но в каждом приложении установить разные базы данных Session в каждом Web.Config и, таким образом, снизить нагрузку. Эта задача будет довольно трудоемкой и приведет к большему управлению в долгосрочной перспективе. Так что ... Я хотел бы знать, возможно ли изменить внутри кода sqlConnectionString, используемого для SessionState, на основе домена, до создания объекта сеанса? Можем ли мы наследовать от System.Web.HttpApplication и использовать событие Application_AcquireRequestState для создания требуемой настройки объекта HttpSessionState?

Надеюсь, это имеет смысл, и кто-то может предоставить некоторые указатели и доказать мне, что это не несбыточная мечта!

Cheers, Стив

Answer 1

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

По умолчанию поставщик состояния Sql Server просто сериализует ваши данные и отправляет их в базу данных. Это ОЧЕНЬ неэффективно и требует ДЛИННОГО времени для передачи по быстрой сети.

Мы решили эту проблему, перейдя к пользовательскому провайдеру, например DOTSS , который сжимает содержимое сеанса перед отправкой его в базу данных. Степени сжатия, которые мы видим, составляют 80-90%, а время сжатия составляет менее 10 мс.

Answer 2

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

Answer 3

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

Существует отдельный раздел конфигурации, соответствующий каждому URL в нашей интрасети (например, http://development11, http://development12). У нас есть экземпляры SQL с аналогичным соглашением об именах (DEVDB1 \ SQL1, DEVDB1 \ SQL2).

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

Answer 4

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

Вот пример, показывающий, как реализовать собственный преобразователь разделов . (Пример разделов по идентификатору сеанса, но было бы тривиально заменить его на раздел по доменам.)

Answer 5

Почему бы не разделить сайты на отдельные веб-приложения и использовать hostheader для различения веб-сайтов. Таким образом, вы можете легко настроить, какую базу данных сеансов вы хотите использовать в своем веб-приложении, поскольку каждое веб-приложение будет иметь отдельный файл web.config.

Answer 6

• Прежде всего, я не вижу преимущества "я хотел бы знать, можно ли изменить в коде sqlConnectionString, используемую для SessionState, на основе домена, до создания объекта сеанса" по сравнению с установите это в web.config.
• Во-вторых, я думаю, что вам нужно изменить настройку этой строки подключения в App_Start, поэтому во всех запросах будут использоваться эти измененные настройки.

Answer 7

Вы можете реализовать пользовательский поставщик состояния сеанса. Подробнее см. MSDN . Я никогда не делал этого, но с небольшой удачей вы можете обернуть модуль состояния сеанса SqlServer и перенаправить его на основе домена