0

我的任务是找到解决我们在 PHP Web 应用程序中遇到的一些性能问题的解决方案（基本上，当将大容量用户与峰值流量/负载时间结合起来时，我们正在达到一个“失败”点）。到目前为止，我发现在尝试访问 MS SQL Server 数据库时出现了瓶颈。我们的系统管理员认为这可能是由于 SQL Server 必须进行过多的上下文切换，因为代码查询数据库的数量。

然而，在更多地研究上下文切换以及如何减少它时，我只能模糊地提到如何在应用程序代码级别实际这样做，主要是“重构你的代码，使其不会打这么多电话，”或特定于 .Net 的提示。

我们正在处理一个庞大而复杂的代码库，所以我们不能做像完全重写系统这样的事情，而且我们还可以很好地优化（尽我们所能）个别查询，所以还有什么其他重构机会可以我们希望帮助我们的代码不会让我们的数据库服务器瘫痪吗？

我目前不知道我们数据库服务器上的完整统计信息，但它足以运行 MS SQL Server 2008 并且直到最近都表现良好。

ETA：我只是一个开发人员，没有任何权威，所以我不能做聘请顾问之类的事情。虽然我愿意向我的上级提出建议，但我主要是在寻找我们可以在内部做的事情，以进一步努力解决根本问题。

正如我在评论中解释的那样，我知道上下文切换更多是其他事物的症状，这会导致我们实际看到的问题（数据库响应缓慢；就像在操作系统中一样，进行大量交换导致应用程序响应缓慢，但它本身就是其他事物占用过多 RAM 的症状）。是什么导致上下文切换？很多数据库访问来自应用程序代码。问题是，正如我们的监控软件所显示的那样，我们现在可以得到的单个查询已经很好了，那么我们还能做些什么来解决这个问题呢？

此后，我的管理员对上下文切换的使用得到了澄清。考虑到他的澄清，问题似乎在于正在进行大量相对较小的调用，这将需要数据库服务器在依次处理每个调用时将它们排入队列，从而在脚本等待时延长响应时间他们要求的数据。那么，是否有任何策略可以组合这些数据库调用，或者调整 MVC 结构的 PHP 应用程序调用数据库的方式，以便脚本不会一直等待数据库？

4

1 回答 1

2

您有 SQL Server 性能问题，将其作为 SQL Server 性能故障排除来处理。有一些众所周知的方法，例如Waits 和 Queues。SQL Server性能故障排除流程图很好地综合了各种文章、工具、方法和指标，供您使用，以识别瓶颈。

Saying that the problem is 'context switching' is non-informative, unhelpful and unactionable. For the record, there is not even such concept as 'context switching' in SQL Server troubleshooting because of the very specific way SQL Server scheduling architecture works. This is not how SQL Server performance troubleshooting is done, it is not even close to true root cause analysis. You need to identify the problem before you can attempt a solution. If your admin cannot help you, seek specialized help from qualified consultants.

And yes, if you can cache anything in the client and avoid querying the server is always, by definition, good. If the client and proxies can cache the page and avoid even hitting your HTTP server, is even better. These are true with any technology stack.

there are a lot of relatively small calls being made, which would require the database server to enqueue them as it handles each one in turn, driving up the response time as the scripts wait for their requested data. Are there any strategies, then, for combining these database calls

There is no silver bullet. Consider though that a well tuned database can drive a lot of small requests per second (many thousands per second) w/o problems. Did you measure metrics in:

These are interesting metrics that can tell a lot where you should focus your effort.

于 2012-09-07T13:24:51.407 回答