我的开发团队致力于开发一个使用 Oracle 数据库 (PL/SQL) 的 Web 应用程序（JSP 报告、HTML、JavaScript）。该应用程序提供的关键功能是报告功能，用户可以在其中获取高级别的 PDF 报告，并深入了解较低级别的支持细节。
随着支持详细记录的数量增长到数百万，系统的性能显着下降。根据我们目前对指标的分析，瓶颈似乎在于影响数据库的逻辑和数据库性能。目前正在探索更改数据库模型并重新执行一些服务器端逻辑。
分区、索引、解释计划和运行统计是在数据库端已经完成的事情，以试图帮助提高性能。虽然他们提供了帮助，但他们并没有令人满意地解决问题。分析性能数据最困难的部分是数据库和 Web 服务器由 IT 组织的不同部分远程管理，因此开发人员没有定期、完全的访问权限来查看正在发生的事情（尤其是在生产环境中，这没有完全反映在任何其他开发/测试环境中）。
虽然我的回答可能不包含任何具体的步骤来帮助这始终是我开始的地方。
我要做的第一件事是尝试抛弃所有关于问题所在的假设，并采取措施在任何地方安装指标。让指标指导您，而不是您的直觉。我已经追逐了很多很多很多的白兔，我有预感……这让我失望的次数比他们正确的次数还要多。
您是否考虑过提前构建数据？换句话说，是否存在一次又一次请求的数据组？如果是这样，请在用户询问之前准备好它们。我并不是在谈论缓存，但我认为这是等式的一部分。
从代码中退后一步并检查系统的使用模式可能是值得的。例如，如果您向人们展示每月库存或销售信息，他们是否只在月底查看？如果是这样，只需在最后一天构建数据并存储它。如果他们每天查看它，也许尝试构建前几天的结果并存储结果并避免计算。我想最终我会把你推向动态编程解决方案；如果您知道答案，请不要再解决它。
你检查过这个吗？
Yahoo! Exceptional Performance 团队快速制作网页的最佳实践
如果您真的在后端遇到问题，这将无济于事。但是我们使用了他们的建议来使我们的网站更快，并且还有更多工作要做。
还可以使用 Firebug 的 YSlow 插件。当您看到实际时间被占用的地方时，您可能会感到惊讶。
正如 Webjedi 所说，指标是您的朋友。
还要看看你的堆栈，看看哪里有缓存的机会——然后尽可能无情地使用！
正如我在另一个问题中所说：
使用分析器。是的，它们要花钱，使用它们有时会有点尴尬，但它们确实为您提供了更多真实的证据，而不是猜测。
人类普遍不善于猜测性能瓶颈在哪里。这似乎是我们的大脑不能很好地完成的事情。看起来很明显，您可能对问题所在有很好的想法，但现实世界往往会做一些不同的事情。优化代码的错误部分，充其量意味着做大量工作以获取最小的收益。更常见的是，它会使事情变慢，有时它会完全破坏事情。因此，在为优化而进行任何更改之前，您应该始终拥有来自分析器或其他准确工具的真实证据。
并非所有的分析器都需要（额外）钱。对于 .Net，我成功地使用了旧版本的 NProf（目前已被废弃，但它仍然适用于我）来分析我的 ASP.Net 应用程序。对于 SQL Server，查询探查器是包的一部分。还有来自 MS 的 CLF Profiler，但我一直无法让它成功工作。
话虽这么说，剖析器绝对是要走的路。这样你就可以看到你的程序大部分时间都花在了哪里，而不是专注于你认为很慢的事情。另外，这意味着您不必在代码中编写任何内容来实际记录指标。
正如我在一开始所暗示的那样，有不同类型的分析器。我发现最有用的三个是应用程序分析器，它可以让您查看您实际上花费了大部分时间的功能。第二个是 SQL 分析器，它可以让您了解您的查询需要多长时间才能运行。第三个是内存分析器，它有助于向您展示您的内存正在被哪种类型的对象占用。所有这三个都非常有用，虽然你不会每天都使用它们，但你使用它们的时间会为你省去很多麻烦。