language-agnostic - 定期性能调整和维护

Question

您多久进行一次定期维护，例如对应用程序进行压力测试和/或为应用程序调整数据库索引？

例如，您是否每周、每六个月或仅在输入大量数据后调整（碎片整理、重组或重建）您的数据库索引，并且您是否在每个主要或次要构建之后对您的应用程序进行压力测试，每周，每年，绝不？

Answer 1

在代码不断发展的实时生产系统中，每一天都是压力测试。同样，数据库调优是关于知道何时停止；当性能可以接受时，你就停下来。

特别是对于 Oracle，关于是否重建索引的争论已经激烈了多年。有些人相信这样做，有些人不相信。索引是一个 B*tree 结构；它将准确地反映表中的数据。在许多情况下（有例外情况），重建索引类似于节食；当然，这些索引在短期内会变瘦，但随着时间的推移——可能只需几天或几个小时的处理时间——它们会恢复到以前的状态。只要绩效达到目标，何必担心呢？重建索引会产生大量的 I/O 活动（必须读取表和/或索引），并且会产生大量的重做活动（为新的索引条目写入重做向量）或需要立即备份（如果您使用 NOLOGGING 重建索引，

例外：

• 位图索引通常应该脱机并在数据加载之间重建，因为它们可以通过 DML 活动病理性膨胀

• 如果从根本上卸载大量数据并使用全局索引或其他一些非本地分区索引，则合并（不是重建，只是将相邻叶子上的相邻空间推到一起）可能是谨慎的。

Answer 2

当我在一家大型 3D CAD 公司工作时，我们进行了以下测试：

• 每当您想签入代码时。大约40个测试。您必须通过所有测试才能签入代码（您还必须通过代码审查）。
• 每当构建服务器完成滚动构建时
• 每天晚上（许多测试，大约需要 8 小时）。
• 每周一次（甚至更多测试 - 这组测试需要很多天才能完成）。

每个测试都加载了一个由 QA 团队创建的特定 3D 模型，以强调各种问题。我确信某些模型是客户提供的，以强调以前已知的客户错误。在所有 3 个方向上，模型的尺寸范围从微米到 1 公里。

Answer 3

我的猜测是，当客户第一次抱怨性能时，可能会这样做，而不是之前。

Answer 4

在实时安装任何新版本之前，我们的（网络）应用程序在上线前的环境中进行了压力测试。测试计划由直接向客户报告的外部公司制定和执行。

唯一的问题：在实时环境中经常会出现性能问题，即使在实时压力测试完美无缺的情况下——“合成”负载似乎与“真实”负载相差太大。