如何优化LAMP网络应用程序的导出功能？

Question

我有一个功能，允许用户创建项目并在此页面上查看它。 他们可以导入资源（pdf，img等）以保持他们的项目。 所以现在我想创建一个功能，允许用户导出他们所有的东西和那些在同一组中的人，因为他们都整齐地用漂亮的丝带绑在一个zip文件中。

当前我正在使用存档：Zip以抢先压缩文件，保留其CRC32校验和并将其作为每日cronjob运行以减少用户等待时间。但是如果任何文件有任何变化，我将不得不重新运行整个事情。

我的初始基准测试显示，103MB的文件最多需要47秒才能运行。 该过程涉及生成将它们链接到XSL的XML，复制图像，iframe的html以及不包含的内容。

我正在考虑创建一个表或文本文件，以保持临时存储区域中所有文件的CRC32校验和或上次修改日期，并且每次用户单击导出时都会与此列表进行比较，如果有任何新文件，我将从缓存的zip文件中删除相同的文件并添加到新文件中。或者我会保留所有松散的文件并复制并替换较新的文件，然后在每次点击时进行存档。

我的问题是：

1. 这被认为是为早产儿或 坏优化技术？
2. 我应该如何正确地优化这个？
3. 是否有一些书或资源 我可以学习这些 优化技术？

Answer 1

有什么不好的想法：

• 设置某种每当用户文件发生更改（添加，删除或更改文件）的标志。
• 对其文件已更改的每个用户运行夜间压缩，然后重置该标志。
• 如果用户在设置标志时请求导出，则必须在导出完成之前再次执行压缩（这是没有办法的）。

为了进一步加快用户体验，还可以将导出请求与导出操作分离。例如，当一个用户（其标志被设置）请求导出时，通知他们它将在压缩发生时完成，并设置一个不同的标志。然后修改上面的第二步，如果设置了第二个标志，也导出新创建的包。

这给用户即时的反馈，即将发生的事情，但将咕work的工作转移到未来。

或者，您不必将导出与压缩绑定。您可以每天晚上压缩，但需要时可以在一天中允许额外的压缩/导出作业。然而，将事件请求分开仍然很好。

回答您的具体问题。

1 /我不认为这是过早或不好的优化。'代码'在功能上是完整的，因为它可以满足您的所有要求，所以现在是优化的正确时机。此外，您已经确定了瓶颈并正在优化正确的区域。

2请参阅上面的我的文本。您应该通过完成您所做的工作来优化它 - 确定瓶颈并专注于改进。考虑到你不太可能获得更好的压缩性能，我建议的解耦“技巧”是一个很好的解决方案。像进度条和启动画面一样，它通常更多的是与速度而不是速度本身相关的用户感知。

3 /书？不要打扰，网络上有成千上万的资源。继续询问SO并打印出所有回复。最终你的大脑会像我一样完整，每一个新的代码片段都会让你暂时忘记你妻子的名字:-)。