我的任务是找到解决我们在PHP Web应用程序中遇到的一些性能问题的解决方案（基本上，当我们将高容量用户与峰值流量/负载时间相结合时，我们会遇到“失败”点）。到目前为止我发现的是，在尝试访问MS SQL Server数据库时出现了瓶颈。我们的系统管理员建议，这可能是由于SQL Server必须进行太多的上下文切换，因为代码查询数据库的数量。
在更多地考虑上下文切换以及如何减少它之后，我只能在应用程序代码级别找到关于如何实际执行此操作的模糊提示，主要是“重构代码所以它”没有打那么多电话，“或.Net特定的提示。
我们正在处理一个庞大而复杂的代码库，因此我们不能完全重写系统，而且我们也可以很好地优化（尽我们所能）我们可以进行的各个查询，以及其他什么我们可以寻找重构机会来帮助我们的代码不会让我们的数据库服务器瘫痪吗？
我目前不知道我们的数据库服务器上的完整统计信息，但是它足够强大，可以运行MS SQL Server 2008并且直到最近都运行良好。
ETA：我只是一名开发人员而且没有任何权威，所以我不能做聘请顾问这样的事情。虽然我愿意向我的上司提出建议，但我主要是寻找内部可以做的事情来进一步解决潜在问题。
正如我在评论中所解释的那样，我理解上下文切换更像是其他东西的症状，然后导致我们实际看到的问题（来自数据库的响应缓慢;就像在操作系统中，做一个大量的交换会导致应用程序响应缓慢，但本身就是占用太多RAM的其他事情的症状。什么导致上下文切换？从应用程序代码中获取大量数据库。问题是，如我们的监控软件所示，个别查询已经和我们现在可以获得的一样好，那么我们还能做些什么来帮助解决这个问题呢？
我的管理员对上下文切换的使用已经澄清。根据他的澄清，似乎问题是有很多相对较小的调用，这将要求数据库服务器将它们排队，因为它依次处理每个调用，在脚本等待的时候加快响应时间他们要求的数据。那么，是否有任何策略可以组合这些数据库调用，或者调整MVC结构的PHP应用程序如何调用数据库，以便脚本不会一直等待数据库？
答案 0 :(得分：2)
您遇到SQL Server性能问题，将其作为SQL Server性能故障排除方法。有一些众所周知的方法，如Waits and Queues。 SQL Server Performance Troubleshooting Flowchart可以很好地综合各种文章，工具，方法和指标来识别瓶颈。
说问题是'上下文切换'是无信息的，无益的，不可行的。为了记录，在SQL Server故障排除中甚至没有“上下文切换”这样的概念，因为SQL Server scheduling architecture的工作方式非常具体。这不是SQL Server性能故障排除的完成方式，它甚至不接近真正的根本原因分析。在尝试解决方案之前，您需要确定问题。如果您的管理员无法帮助您，请寻求合格顾问的专业帮助。
是的，如果您可以在客户端缓存任何内容，并且根据定义，避免查询服务器总是好的。如果客户端和代理可以缓存页面并避免甚至命中您的HTTP服务器，那就更好了。任何技术堆栈都是如此。
正在进行大量相对较小的调用 要求数据库服务器在处理每个数据库服务器时对它们进行排队 转，在脚本等待他们的时候提高响应时间 要求的数据。那么，是否有任何策略来组合这些 数据库调用
没有银弹。考虑一下，经过良好调整的数据库可以驱动很多每秒小的请求（每秒数千个）没有问题。您是否在以下方面衡量指标：
这些是有趣的指标，可以说明您应该集中精力的地方。