3

我想知道是否可以根据运行应用程序的域来更改 ASP.net 中用于 SessionState 的 sqlConnectionString？

一个场景；我们有 20 个站点从一个应用程序运行，所有站点都与不同的数据库通信，具体取决于它们浏览的域（站点）。

当浏览 www.domain1.com 时，应用程序与数据库 'db1' 对话。另一方面，站点 www.domain2.com 与数据库“db2”等进行通信，从而选择相关内容并将负载分散到每个数据库，而不是使用一个主数据库来处理站点的所有连接。

但是出现了一个问题 - 对于此设置，我们对 SessionState 使用 SqlServer 模式，因此所有站点会话的所有用户都存储在 1 aspstate 数据库中，现在随着站点变得更忙/站点数量增加，该数据库的处理压力越来越大所有站点的所有会话请求，并且我们开始收到一些超时错误，其中与该数据库的连接出现瓶颈。

我们可以将站点从他们自己的应用程序中分离出来，并使用相同的代码设置不同的应用程序，但在每个应用程序中，在每个 Web.Config 中设置不同的 Session 数据库，从而减轻负载。但是，这项任务将非常耗时，并且从长远来看会导致更多的管理。所以..我很想知道是否可以在创建会话对象之前根据域在代码中修改用于 SessionState 的 sqlConnectionString？我们可以从 System.Web.HttpApplication 继承并使用 Application_AcquireRequestState 事件来创建所需的 HttpSessionState 对象设置吗？

希望这是有道理的，并且有人可以提供一些指示并向我证明这不是白日梦！

干杯，史蒂夫

4

7 回答 7

2

您的问题不在于与数据库的连接成为瓶颈，而在于您使用来自所有会话的数据压倒了与数据库的网络连接。

默认情况下，Sql Server 状态提供程序只是序列化您的数据并将其发送到数据库。这是非常低效的，并且需要很长时间才能在快速网络上传输。

我们通过使用自定义提供程序解决了这个问题，例如在将会话内容传送到数据库之前压缩会话内容的DOTSS 。我们看到的压缩率为80%-90%，压缩时间小于10ms。

于 2009-06-13T14:50:36.497 回答
2

我认为你错过了一个重要的点——如果瓶颈是 sql server，把东西放在同一台服务器上的不同数据库中根本不会有帮助——要么是 SQL 耗尽了空间，要么是网络耗尽了带宽。在做任何事情之前，我会尝试弄清楚它是哪一个。

于 2009-06-13T14:54:01.730 回答
0

您可以实现自定义会话状态提供程序。有关详细信息，请参阅MSDN。我从来没有做过，但运气好的话，你可以包装 SqlServer 会话状态模块并根据域重定向它

于 2009-06-13T12:20:08.717 回答
0
  • 首先，我没有看到“我很想知道是否可以在创建会话对象之前基于域在代码中修改用于 SessionState 的 sqlConnectionString”的优势，而不是在网络配置。
  • 其次，我认为您需要更改 App_Start 中的连接字符串设置，因此所有请求都将使用更改后的设置。Application_AcquireRequestState 可能为时已晚。
于 2009-06-13T12:23:28.677 回答
0

为什么不将站点拆分为单独的 Web 应用程序并使用 hostheader 来区分网站。这样您就可以轻松配置您希望 Web 应用程序使用的会话数据库，因为每个 Web 应用程序都有一个单独的 web.config 文件。

于 2009-06-13T12:57:28.750 回答
0

IPartitionResolver您可以通过为每个域实现和使用不同的分区来将会话分区到不同的数据库。

这是一个示例，展示了如何实现自定义分区解析器。（示例按会话 ID 分区，但将其更改为按域分区将是微不足道的。）

于 2009-06-13T13:16:42.463 回答
0

我们有几十个开发站点，它们的数据库连接是通过项目的主 Web.Config 处理的。

我们内网上的每个 URL 都有一个单独的配置部分（例如http://development11，http://development12）。我们有具有类似命名约定的 SQL 实例（DEVDB1\SQL1、DEVDB1\SQL2）。

根据内网 IIS 服务器上配置的 URL，应用程序获取相应的配置。为了进行测试，我们可以轻松地修改用户、数据库服务器或用于特定站点的单个数据库。

于 2009-06-13T14:35:02.993 回答