问SQL/IIS (经典ASP) Web应用程序性能优化

EN

这不是一个简单的问题，也没有一个简单的答案。整本书都是关于性能优化的。

也许试着从这些文章开始(在第一部分)，找出性能问题。http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server，-第1部分/

http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server，-第2部分/

我也可以推荐一本书。"SQL 2008性能调优蒸馏“，由格兰特弗里奇和萨哈尔大坝。

如果你能找到表现最差的查询，在这里或者在一个好的SQL论坛上发布，肯定会有人帮你的。事实上，这个问题太宽泛了，没有一个简单的答案。

在SQL方面，使用side来标识任何需要长时间运行的查询或存储过程可能是个好主意。如果您能在这里发现任何真正的问题，它可以帮助加快您的应用程序。

请记住，Profiler工具通常需要进行大量的过滤才能获得正确的信息。您可以记录正在运行的查询的开始时间，并尝试将它们与CPU尖峰时间匹配，这是一个很好的事实。

我怀疑你需要做一些分析。在总体水平上，您需要知道瓶颈在哪里，因此适用典型的Windows性能监视准则。图表CPU的总体性能(%利用率，%用户模式与内核模式，上下文切换)，磁盘(队列长度，%磁盘时间)和内存(页错误/秒，工作集大小)。您将需要开始将其缩小到哪些进程(IIS WAM、Server等)会给您带来痛苦。

就像其他海报上说的--如果是你正在运行的SQL查询，那么这可能是一个数据库优化问题。但是，不要忽视脚本执行愚蠢的查询(选择*和过滤脚本中的结果等)导致异常数据库加载的可能性。

如果您深入到各个脚本(即您发现瓶颈指向IIS / WAM进程)，那么请查看这个堆栈溢出问题：https://stackoverflow.com/questions/398028/performance-testing-for-classic-asp-pages中有一个代码片段，它是一个基本的执行定时器。冒着进一步影响性能的风险，但为了获得更多的可见性，您还可以考虑将传入的参数和脚本的执行时间记录到数据库中。在这些数据中寻找异常值可能会帮助您在脚本中找到边缘条件。理想情况下，您希望从一开始就考虑到概要分析，而改进可能会很困难。