说服产品经理改变长期运行的同步过程的设计

Question

在我们的web应用程序中，我们有一个功能：

products

• Writes

• 将它们的列表获取到excel文件中，

• 将此excel文件返回给用户以供下载

。

这个过程花费更多的时间取决于产品的数量>2分钟。有些请求需要超过5分钟！平均而言，用户下载100到500个产品，请求大约需要1到5分钟。

我认为，对于任何web服务器线程来说，1分钟太长，无法在任何单个请求上活动。除了耗时太长这一事实外，进程本身还会导致服务器内存错误，并使其崩溃。

我想让他们相信，这是错误的做法，因此必须通过引用软件架构师撰写的文章或书籍或研究来改变设计，这些文章或研究报告都是这样的，同时也提出了在这种情况下应该做什么的建议。

有人知道这样的书/文章/研究吗？

如果您不同意我的假设，即1分钟太长，任何web服务器线程都无法在单个请求上活动，请告诉我原因。

Answer 1

您是否尝试过重新考虑逻辑以生成xls？因为如果这是一个业务需求，那么他们可能真的不愿意改变它。

我使用apache来生成xls和创建报告，并且性能令人满意(最多只有几个秒来生成报告)。我们使用服务器端缓存来缓存数据。然后我们就把xls拉出来。

Answer 2

如果下载的优秀列表是固定的，您可以考虑在后台线程中生成它们，并返回一个直接链接供下载。即使它每小时或两个小时改变一次，它还是值得这样做，而不是按需生成。

另一种方法可能是，当用户选择产品列表并请求Excel时，如果他们希望接收带有下载链接的电子邮件，或者甚至接收文件作为电子邮件的附件，则提供一个选项。如果接受，请将每个请求提交到队列中，并运行一个批处理作业，该作业生成Excel表并将其作为邮件附件发送。这样，您就不会节流web服务器。

此外，我的主要问题是，为什么要花一分钟以上，这一过程的哪一部分要花很长时间。值得研究的领域(数据库连接{池，服务器的共同定位}，巨大的表{分区}，excel生成)？

您是否在每个excel中添加固定图形？如果是这样的话，请使用已经具有标头/页脚等的模板。

它值得重新审视那些造成瓶颈的部分，而不是盲目地说它是一种糟糕的设计/方法。

调查可能会解决当前的问题，或者至少你不会在未来的设计中继续犯同样的错误。