提高性能（包括某种故障转移）的最佳方式

现在你在虚拟机上有32位的操作系统。 由于Standard Edition不允许AWE两台服务器（IIS和SQL），所以SQL server将加载最大值约为1.8 GB，并为IIS和OS留下大量内存。 但是一旦你移动到64位的操作系统，事情将会改变，因为SQL server将把缓冲池中的所有内存（如果6GB可用，大约5GB），然后在通知时开始将其返回给操作系统。 这种行为可以通过配置SQL server 内存选项来调整。 通过将IIS和SQL分离到单独的虚拟机上，可以将SQL虚拟机上的所有内存留给它的缓冲池，这很好。 理想情况下，您应该拥有足够的内存，以便SQL可以将整个数据库加载到内存（包括tempdb）中，只需要触摸磁盘进行日志写入以及何时需要检查点数据库。 换句话说，更多的RAM意味着更快的SQL。 到目前为止，SQL是性能最重要的硬件资源之一，并将给予最大的回报。

现在回到“故障转移”的广泛问题。 在SQL server中， 高可用性解决方案分为两类： 自动和手动 。 对于自动故障转移，您实际上只有几个解决方案：

• 聚类 。 传统上，由于支持集群的硬件成本很高，实施起来相当昂贵，但对于VM来说，这是一个不同的故事。 标准版SQL支持两个节点群集。 群集有点难以部署，但操作起来相当简单，不需要修改应用程序。 通过集群，故障转移的单位是整个SQL server实例（即每个数据库，包括master / tempdb / model和msdb，所有登录，所有SQL代理作业等）。 群集不是一个性能的解决方案，因为备用服务器只是闲置，以防主要崩溃。 您可以通过部署所谓的“主动 – 主动”群集来利用备用VM。 这意味着您部署了两个群集，一个在VM1上活动，在VM2上备用，另一个在VM2上活动，在VM1上备用。 在故障转移的情况下，其中一个虚拟机将不得不承担这两个实例的负载，这就是为什么主动 – 主动部署有时皱起了眉头。 考虑到你打算部署在虚拟机上而不是（昂贵的）金属上，我建议不要这样做，因为没有巨额的成本来“分流”。
• 镜像 。 这将保持数据库的热备用镜像（不是实例）。 由于部署成本较低（无需特殊硬件），较短的故障转移时间（相对于群集中的分钟数而言为秒）和地理分布功能（镜像支持分散的大陆上的节点分布，群集仅支持少量百米之间的节点）。 但由于故障转移的单位是数据库 ，因此镜像不能提供群集的易用性。 应用程序所需的大量资源不驻留在数据库中：登录，代理作业，维护计划，数据库邮件消息等等。 由于只有数据库故障转移，故障转移必须仔细计划，以便应用程序在故障转移后继续工作（例如登录必须转移）。 应用程序还必须了解镜像部署，以便它能正确连接 。 使用标准版，您只能以高安全模式部署镜像。
• 硬件镜像。 我不打算详细介绍这一点，它需要专门的SAN硬件能够进行磁盘级镜像。

如果您正在考虑手动故障转移解决方案，那么还有更多的选择：

• 日志传送 。 日志传送基本上是带外镜像。 日志不是通过专用的TCP连接实时传输日志记录，而是通过文件复制操作进行传输。 通过镜像选择日志传送的原因很少：可以查询待机数据库的报告，待机可以位于具有零星连接的位置，待机可以由真正低功率的机器容纳。

• 复制。 这实际上不是高可用性解决方案。 复制是提供数据副本和/或在站点之间交换数据更新的解决方案。 虽然它可以用来部署某种高可用性的转换“解决方案”，但存在许多问题，基本没有优势。 与日志传送和镜像相比，它有一些额外的缺点，因为故障转移的单位甚至不是数据库，只是数据库内的一些数据片（一些表）。 像用户和安全权限这样的元数据不会故障转移，模式更改必须在复制感知模式下完成，并且一些更改甚至不能被复制。 通过合同，镜像和日志传送都提供了与生产数据库相同的备用副本，该数据库自动覆盖对数据库所做的任何更改。

您提到您担心许可成本：实际上， 除了复制以外，您实际上不需要使用任何这些技术的任何被动服务器的许可证。 待机服务器仅在激活并运行数据库30天以上时才需要许可证。

考虑到你计划部署在虚拟机上，我选择的是集群。 如果你要部署在金属上，我建议使用mirroing，因为集群硬件的成本。

如果SQL server是机器上运行的“唯一”的东西，SQL server总是最好的。 您只要做到这一点，就能获得快速，简单和良好的效益。 它似乎喜欢控制一切，当它可以:)总是更快乐

你必须参考这两篇关于ASP.Net性能调优的codeproject的文章

1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx
2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx

我个人在我的asp.net应用程序中实现了这些技术，性能得到了30％以上的提升。

另外你可以参考这篇文章，为你的应用程序提供99.99％的正常运行时间。

3. http://www.codeproject.com/KB/aspnet/ProdArch.aspx

这听起来像你真的问，如果你把数据库在一个单独的机器上。 这可能不会提高性能（实际上会随着延迟的增加而下降），但会提高可伸缩性（我猜测这是您真正需要的）。

性能<>可扩展性。

然而，更多的问题发挥作用 – 如果你没有足够的RAM性能可能会减少在同一个盒子上的数据库 – SQL服务器喜欢使用RAM。

这就是为什么像TFS这样的使用SQL服务器的东西，对于少数用户来说，微软推荐它全部安装在一台机器上，但是对于更多用户，微软建议数据库位于不同的服务器上。

您可以在这里阅读关于TFS的部署选项 。

切换SQL server状态管理不会提高性能 – 它可能会降低性能，但您将获得其他好处（如可靠性）。

这听起来像你需要真正找出性能瓶颈是第一位的。 根据我的经验，这通常在数据库中。

你有没有研究标准的ASP.NET优化技术，如缓存？ 微软提供的应用程序调优指南也可能对您有用。

在Web应用程序场景中使用SQL server时，如果您使用的是SQL server 2005及更高版本，则可能希望阅读有关快照隔离的信息 。 有时不使用它是Web应用程序性能问题的一个原因。

分离层可能有帮助。 通常情况下，调整数据库的机器是非常具体的，所以这是一个合理的第一次努力。

但是，如果您有两种用户活动，其中之一是非常重的，那么您总会面临一些重度用户伤害其他人的风险。

你可以考虑两件事情：

1. 你可以采用“数据仓库”方法吗？ 有第二个DB从第一个涓流。 新的数据库是大量用户工作的地方。 当然，他们的数据会稍微过时，但从概念上讲，这总是会是真的 – 当他们看到世界将会移动的答案的时候。
2. 控制任何时候允许的统计请求的数量。 也许让他们作为一个“工作”提交给队列。 将它们作为低优先级运行。

自然分离IIS和SQL服务器是第一步。 Sql服务器真的想拥有一个完整的机器。

第二件重要的事情就是在运行时分析应用程序。 不要试图在没有实际使用数据的情况下优化应用程序的性能，因为您可能只是花时间优化很少被调用的东西。 我过去成功使用的一种技术是在global.asax中的Request_Begin中创建一个System.Diagnostics.Stopwatch，然后将其存储在上下文变量

var sw = new Stopwatch(); sw.Start() HttpContext.Current.Items["stopwatch"] = sw; 

在Request_End中，您将获得秒表

 sw = HttpContext.Current.Items["stopwatch"]; sw.Stop(); Timespan ts = sw.Elapsed; 

然后写入日志表需要多长时间来处理请求。 还要记录URL（包含和不包含查询字符串参数）以及各种可帮助您分析性能的内容。

然后你可以分析你的应用程序，并找出哪些操作花费的时间最长，这就是所谓的最多等。这将允许你看看是否有一个页面被要求很多，而且通常需要很长时间才能完成，这应该是优化的目标，使用任何你有的工具，.NET和SQL分析器。

我通常也记录的其他东西，IP地址和登录用户的用户ID。 当错误出现时，这也给了我一个非常宝贵的debbugging工具。

把它写到一个表中，而不是把它写到一个日志文件的原因是你可以使用SQL语法来过滤，分组，计算平均时间等。