何时优化性能为时已晚？答案

【问题标题】：When is it too late to optimize for performance?何时优化性能为时已晚？
【发布时间】：2011-06-21 23:57:45
【问题描述】：

我知道您不应该过早地进行优化，而应该以可维护性为目标。我的问题是，什么时候为时已晚？

我在一个网站上工作，类似于 yahoo answers，我的数据库结构正是我觉得应该的。 users、questions、answers、question_comments、answer_comments 等的表格。

我的问题是，如果网站要发展，这个架构将如何扩展？我正在考虑将问题和答案放在一个表中 (posts)，按类型将它们分开，然后将 question_cmets 和 answer_cmets 放在同一个表中 (comments)。我相信这类似于 stackoverflow 的 DB 方案。

我知道你们会说什么，“不要担心它，直到它成为一个实际问题”。但到时候再担心会不会太晚了？

谢谢

【问题讨论】：

永远不会“太晚”，永远是“要花多少钱”:)
你总是可以重组它，对吧？以后可能会更难，但现在这样做会更难；）
一个数据库结构！=一个架构
回头永远都不晚！

标签： performance database-design optimization

【解决方案1】：

尽早优化是一种不好的做法，原因是您不知道瓶颈在哪里，直到您的网站看到大量流量。您的用户如何访问您的网站并与之互动目前尚不清楚。

几乎总是最好从一个“好的”架构（规范化数据库、MVC 架构、DRY、编写良好的前端代码等）开始，然后从那里开始。与过早优化的架构相比，扩展干净、有组织的架构会容易得多。

现在您最多可以通过ab 或其他负载测试工具进行一些负载测试，以查看您当前的瓶颈在哪里。它当然不会找到所有这些，但它会找到一些。

如果您真的对此感到担心（而且您现在不应该担心），请在您的服务器上安装 Nagios 或 Munin 以监控性能。使用第三方工具每天测量页面加载时间。一旦您开始发现问题，您就可以进行分析和调整。

【讨论】：

Ryan 完全正确！在您至少拥有基本架构之前，您不知道瓶颈在哪里。优化是一个迭代和持续的过程，理想情况下是在重构的基础上构建的，它涉及对代码的测量和改进。
这并不总是正确的（即使这是我最初的看法）——例如，（高性能！）游戏开发/开发人员应该从一开始就已经意识到瓶颈；并不是说一开始就应该进行微优化，而是需要从一开始就考虑这种对性能非常关键的设计。当然，当我编写我的桌面应用程序时......不同的故事:)

【解决方案2】：

如果快速服务是应用程序的基本要求，您绝对应该优化。

如果不要求亚秒级响应，那么您可以编写干净的代码并稍后进行优化。

在最新版本的浏览器之前的 JavaScript 就是一个很好的例子，为他们的页面编写漂亮、干净、可扩展的 JS 的人性能很差，不得不从头开始。

【讨论】：

(1) '过早的优化是万恶之源。' (2) 在 Spidermonkey 和 V8 出现之前，prototype.js 或 Dojo 是否充满了可怕的 hack？跨度>

【解决方案3】：

一张巨大的桌子通常更难维护。人们通常将他们的表分割成分区，甚至将他们的数据库分割成碎片。

我看不出将所有 cmets 放入同一个表中如何为您节省连接。确实，将问题和答案放在同一张表中也不会为您节省连接，您只会在同一张表中加入。

如果您想节省连接，我希望您使用面向文档的 NoSQL 数据库，例如 MongoDB。在那里，您可以将包含所有相关答案和 cmets 的问题存储在单个“记录”中，通过一次操作即可获取。

【讨论】：

【解决方案4】：

设计数据库时需要考虑性能，而不是等到以后遇到问题。过早的优化并不意味着不要在设计中这样做，而是意味着不要过分夸大它。但是，每个数据库后端都有已知的性能杀手，如果您熟悉一种不同的技术会更快并且花费相同的时间来编写代码，那么设计使用其中一种是愚蠢的。因此，在设计任何数据库之前，请阅读性能调整，您将永远不会再以相同的方式编写数据库代码。

【讨论】：