提高性能的最佳方法(并以某种方式包括故障转移)

现在,我想你在虚拟机上有32位操作系统。因为标准版不允许 AWE 这两个服务器(IIS和SQL)SQL服务器将最大负载大约1.8GB,并为IIS和OS留下大量的RAM。但是,一旦移动到64位操作系统,事情就会发生变化,因为SQL Server会将所有RAM作为缓冲池(如果有6GB,则为5GB),然后在 notified . 可以通过配置SQL Server来调整此行为 memory options . 通过将IIS和SQL拆分到单独的虚拟机上,您可以将SQL虚拟机上的所有内存保留为其缓冲池,这很好。理想情况下,您应该有足够的RAM,以便SQL可以将整个数据库加载到内存(包括tempdb)中,并且只在需要检查数据库时触摸磁盘进行日志写入。换句话说,更多的RAM意味着更快的SQL。这是迄今为止SQL对性能所需的最重要的硬件资源,并将带来最大的回报。

现在回到关于“故障转移”的广泛问题。在SQL Server中, high availability 分为两类: 自动的 和 手册 . 为了 自动的 故障转移您实际上只有几个解决方案:

• Clustering .传统上,由于支持群集的硬件成本很高,因此实现这一点相当昂贵,但对于虚拟机,情况就不同了。标准版SQL支持两个节点集群。集群的部署有点困难,但操作起来相当简单,不需要对应用程序进行任何更改来支持。通过集群,故障转移单元是一个完整的SQL Server实例(即每个数据库,包括master/tempdb/model和msdb、所有登录、所有SQL代理作业等)。集群是 不 一种性能解决方案,因为备用服务器只是处于空闲状态,以防主服务器崩溃。您可以通过部署所谓的“活动-活动”集群来利用备用虚拟机。这意味着你部署了 二 群集,一个在VM1上活动,另一个在VM2上活动,另一个在VM1上备用。如果发生故障转移,其中一个虚拟机必须承担 二者都 实例,这就是为什么有时不支持活动的活动部署的原因。考虑到你计划在虚拟机上部署而不是在(昂贵的)金属上部署,我建议你不要这样做,因为“弹药化”成本不高。
• Mirroring . 这将保持你的热备用镜子 数据库 (不是实例)。镜像优于群集,因为部署成本较低(无特殊硬件)、故障转移时间较短(与群集中的分钟相比,为数秒)和地理分布功能(镜像支持在单独的continets上分布节点,群集仅支持节点之间几百米的短距离)。但因为故障转移单元是 数据库 ,镜像不提供群集的易用性。应用程序所需的大量资源 不 驻留在数据库中:登录、代理作业、维护计划、数据库邮件消息等。因为只有数据库故障转移,所以必须仔细计划故障转移,以便在故障转移后应用程序继续工作(例如,必须转移登录名)。应用程序还必须了解镜像部署,以便 connects properly . 使用Standard Edition,您只能在 high-safety mode .
• 硬件 镜像。我不想详细介绍这一点,它需要能够进行磁盘级镜像的专用SAN硬件。

如果您正在考虑手动故障转移解决方案,那么还有其他两种选择:

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

• 复制。这真的不是一个高可用性解决方案。复制是提供数据副本和/或在站点之间交换数据更新的解决方案。虽然它可以用于部署某种高可用性的“转换”解决方案,但存在许多问题,基本上没有优势。与日志传送和镜像相比,它有许多 额外的 缺点是,由于故障转移单元甚至不是数据库,所以只是数据库(某些表)中的数据切片。元数据(如用户和安全权限)不会失败,架构更改必须在 replication aware mode 有些变化甚至无法复制。根据合同,镜像和日志传送都提供与自动覆盖的生产数据库相同的备用副本 任何 对数据库所做的更改。

您提到您关心许可证成本:实际上您不需要为任何 passive 使用这些技术的服务器 除了 复制。只有当备用服务器处于活动状态并运行数据库超过30天时,它们才需要许可证。

考虑到您计划在虚拟机上部署,我的选择是集群。如果您将部署在金属上,我建议使用mirroing,而不是集群硬件的成本。

如果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%的性能改进。

此外,您可以参考 this 文章为您的应用程序99.99%的正常运行时间。

三。 http://www.codeproject.com/KB/aspnet/ProdArch.aspx

听起来你真的在问是否应该把数据库放在一台单独的机器上。这可能不会提高性能(实际上会随着延迟的增加而降低),但会提高可伸缩性(我猜这正是您真正需要的)。

性能<gt;可扩展性。

然而,更多的问题开始出现——如果没有足够的RAM,那么数据库在同一个盒子上的性能可能会降低——SQL Server喜欢使用RAM。

这就是为什么对于像TFS这样使用SQL Server的用户,对于数量较少的用户,Microsoft建议将其全部安装在一台计算机上,但是对于数量较多的用户,Microsoft建议将DB安装在不同的服务器上。

你可以 read about the deployment options for TFS here .

切换SQL Server状态管理不会提高性能—它可能会降低性能,但您将获得其他好处(如可靠性)。

听起来您需要先了解性能瓶颈是什么。根据我的经验,这通常在数据库中。

您是否研究过标准的ASP.NET优化技术(如缓存)?微软提供 guidance on application tuning 这也可能对你有用。

当您在Web应用程序场景中使用SQL Server时,如果您使用的是SQL Server 2005及更高版本,则可能希望阅读 Snapshot isolation . 有时不使用它会导致Web应用程序出现性能问题。

层的分离可能有帮助。通常,数据库的机器调优是非常具体的,所以这是一个合理的第一步工作。

然而,如果你有两种用户活动,其中一种是非常沉重的,那么你总是会冒着让几个沉重的用户伤害其他人的风险。

你可以考虑两件事:

1. 你能采用“数据仓库”的方法吗?从第一个开始第二个db滴流。新的数据库是重型用户工作的地方。当然,他们的统计数据会有点过时,但从概念上讲,这永远都是正确的——当他们看到答案的时候,世界就会改变。
2. 控制一次允许的统计请求数。也许把它们作为“作业”提交到队列中。以低优先级运行它们。

自然地,将IIS和SQL Server分离是第一步。SQL Server确实希望自己拥有一台完整的计算机。

第二件重要的事情是在应用程序运行时对其进行分析。不要在没有实际使用数据的情况下尝试优化应用程序的性能,因为您可能只是花时间优化很少被调用的东西。我过去成功使用的一种技术是在请求中创建system.diagnostics.stopwatch,然后在global.asax中开始,然后将其存储在上下文变量中。

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

在请求端,您获得秒表agin

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

然后将处理请求所需的时间写入日志表。同时记录URL(包括查询字符串参数和不包括查询字符串参数)以及各种有助于分析性能的东西。

然后,您可以分析应用程序并找出哪些操作花费的时间最长,哪些操作被称为最长的,等等,这些操作将允许您查看是否有一个页面被大量请求,并且通常需要很长的时间才能完成,这应该是优化的目标,使用您为此所拥有的任何工具,包括.NET和SQL分析程序。

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

与将其写入日志文件不同,将其放入表中的原因是可以使用SQL语法筛选、分组、计算平均时间等。