在时间紧迫的情况下添加更多硬件v / s重构代码

Question

背景： 企业应用程序 - 非常将于2004年编写。

堆栈： .NET，大量使用远程处理，ASMX样式的Web服务，SQL Server

问题： 该应用程序允许用户通过各种向导来查找缺少更好的术语，他们的所有操作都存储在我们称之为“wiz state”的内容中，这实际上是非常频繁地持久存储到SQL Server数据库的XML，因为我们允许用户暂停/恢复他们的申请。通常在这些向导中，构成向导状态的XML变得非常大，我说的是5-8 MB的数据，我们注意到当我们突然涌入同时用户时，我们开始偶尔收到针对数据库的超时，因为巫师状态的很多内容都是跟踪“事物”的集合。有时这些自定义集合会变得非常大。

问题： 我们今天参加了一个会议，我们期待10月份的一系列活动将以前所未有的方式测试系统，并可能导致从Web服务器到数据库来回的巨大向导状态。情况的关键是只有一个数据库和一个Web服务器。

为了论证，由于应用程序的复杂性，假设添加任何类型的群集/镜像来提高数据库吞吐量是不可能的。我在会议上发言并表示，在最短的时间内解决这个问题的最快方法是在前端Web应用程序中添加更多服务器，以便可以在Web服务器之间分配负载。开发负责人说我完全错了，因为我们只有一个数据库，所以没有任何效果，所以添加更多网络功能将无济于事。他让其他开发人员之一将我们经常持久存在的xml膨胀减少到数据库。可能从长远来看，减少我们来回传递的xml的大小是正确的想法，但是添加额外的Web服务器真的没有效果，我只想从同时用户的角度来看，应该帮助。

任何回复的想法都值得赞赏，证明更多的网络服务器将有助于纯粹的胜利。

感谢。

编辑：我们使用二进制序列化将XML存储在图像字段的数据库中。

Answer 1

如果SQL写入数据的速率是瓶颈，那么更快地向SQL提供数据应该没有效果。

我不确定数据结构究竟是什么，但可能在写入之前压缩Web服务器上的XML数据可能会产生积极的影响。

Answer 2

如果瓶颈是数据库，那么更多的Web服务对您没有多大帮助。

问题可能是问题不仅是数据的大小，而且是同一个表的并发请求数。写入次数将是一个大问题。如果您的XML写入与其他查询处于事务中，您可能会尝试从该事务中分离XML写入以减少XML表的锁定时间。

如vdeych所述，您可以尝试压缩以减少数据大小。 （这会增加Web服务器的负载。）

您也可以尝试缓存数据。如果数据尚未存在于缓存中，则仅从SQL服务器读取。如果数据没有更改，请确保不更新SQL Server。

Answer 3

我没有听说过有关定位“瓶颈”的事情。这不是第一件事吗？ Here's the method I use. 否则你只是投资猜测。那不行。

我参加过这样的会议，每个人都兴奋地投掷想法，而“管理层”想做出“决定”，但盲人领导盲人。指责并找出正在发生的事情。你不能在会议上这样做。

前段时间我查看了与您的性能问题有些相似的性能问题。最大的“瓶颈”是写入和解析XML，伴随着内存分配，设置和破坏。然后还有其他人。你可能会发现同样的事情或不同的东西。

P.S。我一直引用“瓶颈”，因为我发现的所有性能问题都不像瓶颈。相反，它们就像是需要彻底修剪的过于浓密的调用树，例如无缘无故地制作和阅读XML版本。

Answer 4

似乎没有人建议这样做，如何用JsonSerialization替换向导的XML序列化。

由于DataContractSerializer（更快）和Newtonsoft Json.NET（最快）在.NET中执行XML序列化，因此这不仅可以在序列化本身中提供性能的轻微提升。这应该可以轻松地将对象图形的大小减少50％或更多（取决于属性数量与XML中的大字符串）。

这应该会大大降低对Sql server造成的IO。这也应该限制显着改变你的应用程序所需的范围数量（假设它设计得很好并且可以通过常见的序列化/反序列化调用）。

如果你选择这条路线也投入时间比较BSON和JSON，因为我认为由于对象图的大小，二进制编码的可能会提供更多的空间节省（以及进一步的IO减少）。

Answer 5

我不是.NET专家，但使用二进制序列化会增加吞吐量。确保XML不是作为文本存储的（相当明显，但我想提到它）。关系数据库最适合存储关系数据，因此可能用ORM层代替序列化（听起来可行）可以加快速度。

Answer 6

迈克是现场，没有理解导致性能问题的资源构造，没有多少讨论会解决问题。我将添加影响正在运行的语句的套接字超时是一种症状，并且永远不会被SQL Server强加，它们是驱动程序配置的工件或应用程序和数据库之间的防火墙或类似设备强加它们（除非你在说话）关于新连接的超时，然后你有一个主机在负载下严重遇险）。

鉴于您的症状是数据库超时，您需要从那里开始。如果它们指示导致套接字超时的长时间运行语句，请使用SQL Server分析器捕获工作负载，同时监视系统资源。鉴于它是一个成熟的应用程序和您提到的工作负载类型，它不太可能与语句调优相关，它可能归结为资源限制CPU，内存或磁盘IO容量

这个Technet指南是一个非常好的起点： http://technet.microsoft.com/en-us/library/cc966540.aspx

如果是资源争用，那么这是一个简单的讨论，讨论如何通过添加更多所需的资源来调整，配置或解决资源争用。

编辑：我应该补充一点，鉴于数据库性能问题，随着您增加并发数量，更多应用程序服务器可能会使问题恶化，否则可能会被连接池，请求处理或其他限制所检查。