如何诊断和修复我荒谬的Meteor构建时间？

Question

我有一个使用meteor 1.5，react和redux的中小型网络应用程序。很长一段时间以来，我经历了大约3-4分钟的可怕启动时间。我的应用程序使用npm包，流星包和本地流星包。我能够删除一堆不需要的本地软件包，并且我将构建时间缩短到大约2分钟以上，但这并没有持续，现在它已经达到了20分钟。

我尝试过多次使用流星分析仪，虽然它报告的时间本身仍然是不可接受的，但它们比实际加载时间短得多。大部分等待是在'prepareProjectForBuild'步骤完成和'Build App'步骤开始之间，其中探测器输出任何内容。当“构建应用程序”步骤完成时，它声称需要大约200秒。仍然是一个糟糕的建设时间IMO，但我现在为此杀了它。

Answer 1

我有一个类似大小的项目，并将构建时间缩短到大约1分钟。我只能从我的经验告诉你我做了什么来缩短我的构建时间：

A - 代码注意事项

<强> 1。尽可能多地将“手动”代码移动到工厂方法中

这意味着，重复很多的类似创建代码可以很容易地简化为一些创造性的工厂功能。这也提高了测试覆盖率。

其中：

• 特别是收藏品的创作。大多数收藏品只有不同 在他们的架构和一些特殊的pubs /方法案例中。很多代码 是重复的。
• 模式
• 常见出版物（例如，经常出现的标题和身份证）
• 遵循某种“标准”模式的方法
• 在运行时创建的任何重复的对象模式

<强> 2。不要乱用数千个循环导入

它不会导致您的应用崩溃。但保持清晰的封装结构可能会减少导入的查找时间。使您的代码更易于维护。

第3。将资产文件移出项目

我知道这很难，特别是当结构随着时间的推移而收紧时。但是，当我不得不将所有资产文件移到cdn并仅引用路径时，它会大大提高我的构建时间。

<强> 4。软件包中的Npm依赖项

您可以使用

而不是在包中（或您控制的地方）硬连接npm deps

tmeasday:check-npm-versions

软件引用它们，以便你的meteor应用程序负责管理它们，减少npm重复数据包的冲动。

<强> 5。尽可能移动到npm

时机将到来，无论如何，流星会转移到npm。因此，现在就尽可能使你的软件包成为npm软件包，并在以后安全地构建时间。

编辑： ..................................................

<强> 6。将应用程序中的服务绘制到独立服务中

当您拥有仅提供一项功能的服务时，请将其移出您的应用。这可能适用于：

• 通知服务
• 引擎（工作流程，流程网络）
• 记录/跟踪
• 简单交易
• 管理面板（通常只是操纵集合）
• 应用的其他部分，仅用于管理目的

............................................... ...

B - 其他注意事项

<强> 1。不要在Windows上开发meteor（除非你需要）

这个建议有点缺陷，因为我不能告诉你为什么，但我在几台机器（我自己的，同事，同事，工作场所）上发现方式更慢，更新，构建和包构建过程比在linux或mac上。像bcrypt一样编译本机代码在这里很慢。也许有人对此有所了解？

<强> 2。 SSD使一切更快

已经常识。

注意：我无法通过这些描述的方法中的特定方法来判断提升有多好。我随着时间的推移尝试了所有这些，随着时间的推移得到了很好的构建。