使用IIS静态内容服务与从SQL Server Jquery WCF获取数据之间的性能差异

我们有一个在ASP.Net中开发的门户，托管在Windows 2008 IIS服务器上，有超过200000人全局访问（额外网络），其中40%是并发访问

作为门户的一部分，我们需要显示特定于用户的通知

（每天可能有50多条通知，其中包含20行通过HTML显示的内容）

门户还应该能够搜索特定于用户的通知

通知可以作为XML文件在服务器上接收。（实时或计划方式）

我们想建造一个高性能的建筑

让我知道哪一个主题会遇到相同的问题

---

啊，这让我想起了我在上一次创业页面上所做的事情。我们必须向单个用户推送警报和通知，并允许每个用户将其标记为已读

首先，我们想用惯常的方法来做。创建一个具有用户标识、通知标题和读取标志的通知表。但随着时间的推移，这会变得非常零碎，速度越来越慢，而且随着数百万通知的添加/更新/删除，索引需要重建等等

所以，我们选择了另一种选择。我们添加了一个通知表，它有一个UserID，但它有一个巨大的char列，其中包含一个XML，该XML包含用户可以看到的所有通知。由于您不需要跨用户搜索，因此一个用户将始终只查看该用户的通知。这意味着通知表在最坏情况下可以与用户表具有相同的行数，而不是更多。而且我们不经常在这个表上添加/更新/删除行，因此没有数据库框架、索引重建等问题

你也可以试试。创建具有以下内容的通知表：

Notification:
=============
UserID int FK to user table
RecentNotifications  char(4000)
ArchivedNotifications char(4000)

在RecentNotifications上，存储包含需要向用户显示的通知的XML。ArchiveNotifications包含用户在转到某个通知页面时可以看到的归档消息

您可以使用一些xml来存储它：

<notifications>
  <notification title="" datetime="" read="yes/no" />
</notifications>

---

这是否回答了您的问题？

这只涉及数据库存储方法，让我知道这比静态内容方法更好，静态内容方法将通知内容存储为单独的HTML文件，并将其下载到浏览器中一次，之后无需下载（在内容过期期间），另外，我也不确定从长远来看，4000个字符（我提到大约50个/天/用户）是否足以让您了解Stackoverflow体系结构本身的最新消息：若您使用静态html内容，那个么若它被缓存在浏览器上，那个么在浏览器下载最新的html通知之前，用户不会收到通知。最好将其存储在数据库中，并将其作为页面输出的一部分发出。将重要数据存储为通知，并将其缓存，这意味着用户将看到过期的通知。此外，用户可能会将某些通知单击为“已读”。这应该会从页面上消失。但如果您使用的是缓存的html，则在重新加载页面后，通知会再次返回，就像它没有被读取一样，因为浏览器正在显示缓存的html中的内容，而缓存的html已经过时。我使用了4000个字符来确保表仍然可以在线重建索引。如果我使用varchar（max），则无法对重建进行索引。因此，随着时间的推移，表的速度越来越慢，您必须停机以使表恢复到其原始性能。