我的公司正在开发一款基于 Web 的数据查看器应用程序，它需要相当多的带宽才能正常运行。然而，最近我们一直在改变很多事情。例如，我们改变了内部网络基础设施，以便数据可以托管在通过千兆以太网连接的单独机器上。最重要的是，由于我们仍处于 alpha 和 beta 测试阶段，因此应用程序本身不断推出新版本。
最近我们进行了一些更改，导致性能下降，我们希望在开始拆解之前尝试找出问题所在。这是一个非常小的网络，我作为 IT 管理员的经验有限。我对从哪里开始有一些想法，但我想先从专业人士那里获得一些智慧：您如何解决/避免类似的问题？您使用过的最有用的（Windows）工具是什么？
答案1
我总是遵循这种方法：尝试一次测试一件事。
值得信赖的“科学方法”对于解决问题非常有效：
- 想出一个解释应用程序运行缓慢的原因
- 设计一个可以证实该理论的测试。
- 重复。
对于 Web 应用程序来说，这可能意味着：
- 可能是数据库的问题吗？运行一些独立的 SQL 查询
- 可能是 Web 服务器的问题？通过获取静态页面来测试 Web 服务器
- 可能是应用程序的问题吗？通过访问不涉及数据库的动态页面来测试 Web 服务器
- 这可能是应用程序与数据库的接口吗？通过访问与数据库相关的动态页面来测试 Web 服务器。
另外，运行测试 CPU、内存、磁盘速度的基本基准测试也可以帮助您在进行进一步的操作之前排除其中一个问题。
我经常看到这样的事情：
在新服务器上备份所花的时间比在旧服务器上更长。
但是没有人进行基本的磁盘基准测试来发现旧服务器的主轴数量是新服务器的两倍……或者进行网络基准测试来发现新服务器的千兆以太网仅以 100M 的速度运行。
尽管如此，如果这是一个自定义的 Web 应用程序，那么您使用的框架肯定有办法将性能信息转储到日志文件中......但这更像是 stackoverflow 的一个问题。
答案2
我认同“福尔摩斯”的故障排除方法，又称二分搜索故障排除方法：
- 将问题空间一分为二。
- 排除问题空间的一半。
- 对剩余的问题空间重复上述操作。
根据我的经验，有时你会因为先尝试一些显而易见的事情而获得好运，但是一旦你用尽了真正快速的解决办法，你就需要迅速采取有条不紊的方法。
该方法与科学方法和“一次测试一件事”兼容。
答案3
上面的答案加起来占了我想说的 90%，下面是另外 10%：
- 关于控制环境，更具体地说是环境变化，我们有一个教训需要学习。即使您已经在测量性能，一次更改多个内容也意味着任何问题都会变成一个两步问题：找到结果和原因。如果您一次更改一个内容，并且有一个有效的计划来回滚任何性能问题，通常都与该更改有关（通常，有时会发生奇怪的事情，或者有人更改了您不知道的内容），并且希望通过回滚更改来解决。
- 最有益的做法是尽早并经常进行测量。事实和准确的数据使解决性能问题变得更容易。
- 你能做的最无益的事情就是猜测哪里出了问题，然后不加测量就做出改变。你会惊讶地发现，一个看似合理的猜测往往不能解决问题，甚至会使问题变得更糟。
- 您无法衡量尚未定义的东西。每当您遇到性能问题时，请定义最终用户的期望是什么，然后找到一种可以重复的方式来衡量是否成功或未能满足该期望。尽可能具体地做到这一点，您将缩小需要调查的范围以及为此需要运行的测试。
- 对于 Windows，我非常喜欢性能计数器日志并使用 PAL 来处理和帮助解释它们。系统概览报告和该报告的建议计数器涵盖了大多数可能的瓶颈来源。http://pal.codeplex.com
答案4
是哪些更改导致了性能问题？如果只是更改了代码，那么我会从那里开始进行故障排除。