我的开发团队致力于使用Oracle数据库（PL / SQL）的Web应用程序（JSP报告，HTML，JavaScript）。应用程序提供的关键功能在于报告，用户可以在高级别获取报告的PDF，并深入到较低级别的支持详细信息。
随着支持详细记录的数量增长到数百万，系统的性能显着下降。根据我们当前对指标的分析，瓶颈似乎在于达到数据库和数据库性能的逻辑。目前正在探索更改数据库模型并重新执行某些服务器端逻辑。
分区，索引，解释计划和运行统计信息是在数据库方面已经完成的尝试帮助提高性能的事情。虽然他们有所帮助，但他们还没有令人满意地解决这个问题。分析性能数据最棘手的部分是数据库和Web服务器由IT组织的不同部分远程管理，因此开发人员没有定期的完全访问权限来查看正在发生的事情（特别是在生产环境中，在任何其他开发/测试环境中都没有完全镜像。
答案 0 :(得分：6)
虽然我的回答可能没有任何具体步骤来帮助我始终在这里开始。
我要做的第一件事就是尽量抛弃所有关于问题所在的假设，并采取措施在任何地方安装指标。让指标指导你而不是你的直觉。我已经追赶了很多很多很多白兔，他们正在追逐......让我失望的次数比他们说的还多。
答案 1 :(得分：2)
您是否考虑过提前构建数据？换句话说，是否会一次又一次地请求数据组？如果是这样，在用户询问之前准备好它们。我并不是在谈论缓存，但我认为这是等式的一部分。
从代码中退一步并检查系统的使用模式可能是值得的。例如，如果您向人们显示月度库存或销售信息，他们是否仅在月底查看？如果是这样，只需在最后一天构建数据并存储它。如果他们每天查看它，可以尝试构建每个前几天的结果并存储结果并避免计算。我想我最终会推动你进入Dynamic Programming解决方案;如果你知道答案就不能再解决了。
答案 2 :(得分：2)
你看过这个吗？
来自Yahoo！的卓越绩效团队的Best practices for making web pages fast
如果你真的在后端遇到麻烦，这无济于事。但是我们使用他们的建议来提高我们网站的速度，还有更多工作要做。
也可以使用Firebug的YSlow插件。当你看到实际时间在哪里时，你可能会感到惊讶。
答案 3 :(得分：1)
正如Webjedi所说，指标是你的朋友。
还要查看您的堆栈，看看哪里有缓存机会 - 然后尽可能无情地使用！
答案 4 :(得分：1)
正如我在another question中所说：
使用分析器。是的，它们需要花钱，使用它们偶尔会有点尴尬，但它们确实为您提供了更多真实的证据而不是猜测。
人们普遍不愿意猜测性能瓶颈在哪里。它似乎是我们的大脑不能很好地建立的东西。看起来很明显，你可能对问题是什么有很好的想法，但现实世界常常会做出不同的事情。并且优化错误的代码部分意味着充其量只需要很少的工作以获得最小的利益。更常见的是，它会使事情变得更慢，有时它会完全破坏事物。因此，在您进行任何更改以进行优化之前，您应始终从分析器或其他准确工具中获得真实的证据。
答案 5 :(得分：1)
并非所有的分析师都花费（额外）资金。对于.Net，我成功地使用了一个旧版本的NProf（目前已经废弃，但它仍然适用于我）来分析我的ASP.Net应用程序。对于SQL Server，查询探查器是程序包的一部分。还有来自MS的CLF Profiler，但我从来没有能够让它成功运作。
话虽这么说，分析师肯定是要走的路。这样你就可以看到你的程序大部分时间花在哪里，而不是专注于你认为很慢的事情。此外，它意味着您无需在代码中编写任何内容即可实际记录指标。
正如我在开头所暗示的那样，有不同类型的剖析器。我发现最有用的三个是应用程序分析器，它们可以让您查看实际花费大部分时间的功能。第二个是SQL分析器，可以让您查看运行查询所需的时间。第三种是内存分析器，它有助于向您显示内存耗尽的对象类型。所有这三个都非常有用，虽然你不会每天都使用它们，但是你使用它们的时间会给你带来很多麻烦。