如果我的web应用程序需要20秒来完成一个请求，这是一个糟糕的设计吗？

Question

我有一个web应用程序，它在后台做一些可靠的文档处理工作。用户上传文档进行处理后，最多需要20秒才能完成处理。现在，我尝试使用每秒更新一次的进度条来吸引用户。

1. 如果一个Web应用程序需要20秒来做一些严肃的后端处理，它是一个糟糕的应用程序吗？
2. 您是否遇到过处理时间超过10-15秒的Web应用程序？互联网上有没有流行的网站也这样做？
3. 将这种耗时的应用程序重新设计为批处理驱动的应用程序有意义吗？在处理完成后将向用户发送异步消息的应用程序（例如，电子邮件/短信）。
4. 现在，我每分钟最多可以服务30个用户。从基础设施的角度来看，如果我必须扩展到服务超过5000个用户，横向扩展（购买更多机器）有意义吗？如果有，我如何计算我需要多少台机器？例如，该应用程序在工作时间（9-5）被500个用户使用。

Answer 1

这个问题有点太依赖观点了，但不管怎样。

1）取决于用户的期望。如果我知道我发送的任务请求会很重，也许我不会觉得太慢。如果是浏览静态内容，那就是。同样，我不希望下载图片的时间和下载电影的时间一样。

据我所知没有。但是，你的网站能为用户提供什么呢？

3）在15-20秒内，我不会说它需要重新设计以支持批处理作业。当它进入几分钟时，也许。

4）没有详细的研究就不可能知道。只是你需要更多的CPU/内存？或者可能存在同步问题，并且拥有更多用户将导致问题呈指数级增长？别忘了，当你解决瓶颈时，只是因为其他东西已经成为瓶颈。

Answer 2

在我看来：

>

考虑到严重的后端处理，我不会将其标记为坏应用程序。

肯定会有这样的网站有密集的后端处理:文档、图像、音频、视频等。

在可能的情况下，我认为这种处理器密集型任务应该在批次处理作业模式下处理。这样的任务可能会委托给辅助机器。如果作业超过设定的持续时间，用户可以选择作业完成通知。您还可以向在作业仍在处理时退出的用户发送作业完成通知。

考虑到用户规模，扩大资源规模可能是有意义的。计算资源规模需求可能不是一件容易的事情。你可以通过日志了解处理的文档数量、平均持续时间以及高峰使用时间。这些数字与当前平均并发用户数相结合，可以帮助您粗略估计资源规模。

Answer 3

对于需要很长时间并且由于技术原因(依赖于你无法控制的外部系统，资源稀缺)而无法加速的请求，做facebook和youtube所做的:在后台完成工作，并提供通知系统让用户知道工作何时完成。这样用户就不需要等待他们的请求完成(也不用担心如果他们不小心返回或者刷新页面会发生什么)，但是他们仍然可以在请求完成后立即得到反馈。

一个执行良好的反馈系统甚至可以提供一个进度条作为“通知”的一部分。Android上的应用程序通过通知实现这一点。