ASP.Net 会话状态

发布于 2024-07-23 22:32:25 字数 829 浏览 7 评论 0原文

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

一个场景; 我们有 20 个站点从一个应用程序运行,所有站点都与不同的数据库进行通信,具体取决于它们从哪个域(站点)浏览。

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

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

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

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

干杯, 史蒂夫

I was wondering whether it would be possible to change the sqlConnectionString used for SessionState in ASP.net based upon the domain an application is running on?

A scenario; We have 20 sites running from one application all talking to different databases depending which domain (site) they are browsing from.

When browsing www.domain1.com the application talks to the database 'db1'. The site www.domain2.com on the other hand talks to the database 'db2' etc, thus selecting the relevant content and also spreading the load to each database rather than using one master database to handle all connections for the sites.

An issue that has arisen though - for this setup we use SqlServer mode for the SessionState so all users to all sites sessions are stored in 1 aspstate database, now as the sites get busier / number of sites increase this database comes under increasing strain to handle all the session requests for all the sites and we are starting to get some timeout errors where the connections to this database are bottlenecking.

We can seperate out the sites to from their own application and set up different applications with the same code but within each application set a different Session database in each Web.Config and thus lightening the load. This task would be quite time consuming though and would result in more management in the long term. SO.. I would love to know if it's possible to modify within the code the sqlConnectionString used for SessionState, based upon a domain, before the session object is created? Can we inherit from System.Web.HttpApplication and use the Application_AcquireRequestState event to create the required setup of the HttpSessionState object?

Hopefully this makes sense and that someone can provide some pointers and prove to me that this isn't a pipe dream!

Cheers,
Steve

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

苏辞 2024-07-30 22:32:25

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

我们的 Intranet 上的每个 URL 都有一个单独的配置部分(例如 http://development11http://development12)。 我们有具有类似命名约定的 SQL 实例(DEVDB1\SQL1、DEVDB1\SQL2)。

根据 Intranet IIS 服务器上配置的 URL,应用程序获取适当的配置。 为了进行测试,我们可以轻松修改用户、数据库服务器或特定站点使用的单个数据库。

We have several dozen development sites whose database connections are handled via the project's main Web.Config.

There is a separate configuration section corresponding to each URL on our intranet (e.g. http://development11, http://development12). We have SQL instances with a similar naming convention (DEVDB1\SQL1, DEVDB1\SQL2).

Based on the URL configured on the intranet IIS server, the app grabs the appropriate config. For testing we can easily modify the user, the database server or individual databases utilized for a particular site.

開玄 2024-07-30 22:32:25

您的问题并不是与数据库的连接出现瓶颈,而是您使用来自所有会话的数据压垮了与数据库的网络连接。

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

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

Your issue isn't so much that the connections to the database are bottlenecking, its that you are overwhelming the network connection to the database with data from all of the sessions.

By default, the Sql Server state provider simply serializes your data and ships it to the database. This is VERY inefficient and takes a LONG time to transfer on a fast network.

We solved this problem by going to a custom provider, like DOTSS that compresses session content before shipping it to the database. The compression rates we see are 80%-90% and the compression time is less than 10ms.

帅气称霸 2024-07-30 22:32:25

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

You can implement a custom session state provider. See MSDN for details. I've never done it, but with a little luck you can wrap the SqlServer session state module and redirect it based on the domain

清秋悲枫 2024-07-30 22:32:25
  • 首先,我没有看到“我很想知道是否可以在创建会话对象之前根据域修改用于 SessionState 的 sqlConnectionString 的代码”与在网络配置。
  • 其次,我认为您需要更改 App_Start 中的连接字符串设置,因此所有请求都将使用更改后的设置。Application_AcquireRequestState 对此可能为时已晚。
  • First of all, I don't see there is advantage of "I would love to know if it's possible to modify within the code the sqlConnectionString used for SessionState, based upon a domain, before the session object is created" compared to set this in web.config.
  • Secondly, I think you need change that connection string setting in App_Start, so all the request will use that changed settings.Application_AcquireRequestState probably too late for this.
无悔心 2024-07-30 22:32:25

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

Why not split up the sites into sperate web applications and use hostheader to differentiate between the web sites. That way you could easily configure which session database you want your web application to use since each web application would have a seperate web.config file.

清眉祭 2024-07-30 22:32:25

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

以下示例展示了如何实现自定义分区解析程序。 (示例按会话 ID 分区,但将其更改为按域分区就很简单了。)

You could partition your session across different databases by implementing IPartitionResolver, and using a different partition for each domain.

Here's an example showing how to implement a custom partition resolver. (The example partitions by session ID, but it would be trivial to change it to partition by domain instead.)

双手揣兜 2024-07-30 22:32:25

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

I think you are missing a big point--putting things in separate databases on the same server isn't going to help things at all if the bottleneck is sql server--it is either SQL running out of headroom or the network running out of bandwidth. I'd try and figure out which one it was before doing anything.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文