我有一个Web应用程序，它在后台做一些可靠的文档处理工作。用户上传文档进行处理后，最多需要 20 秒才能完成处理。现在，我尝试使用每秒更新的进度条来吸引用户。
- 如果一个 Web 应用程序需要 20 秒来执行一些严肃的后端处理，那么它是一个糟糕的应用程序吗？
- 您是否遇到过处理时间超过 10-15 秒的 Web 应用程序？互联网上是否有任何流行的网站可以做同样的事情？ 将
- 这种耗时的应用程序重新设计为批处理驱动的应用程序是否有意义？在处理完成后向用户发送异步消息的应用程序（例如，电子邮件/短信）。
- 现在，我每分钟最多可以为 30 个用户提供服务。从基础架构的角度来看，如果我必须将其扩展为超过 5000 个用户提供服务，那么横向扩展（购买更多计算机）是否有意义？如果是，如何计算我需要多少台机器？例如，该应用程序在工作时间 （9-5） 由 500 个用户使用。
对于需要很长时间并且由于技术原因（依赖您无法控制的外部系统，资源稀缺）而无法加速的请求，请执行Facebook和YouTube所做的工作：在后台完成工作并提供通知系统，让用户知道工作何时完成。这样，用户就不需要等待他们的请求完成（并担心如果他们不小心返回或刷新页面会发生什么），但他们仍然会在完成后立即获得反馈。
执行良好的反馈系统甚至可以提供进度条作为"通知"的一部分。Android 上的应用程序通过通知来执行此操作。
在我看来：
-
考虑到严重的后端处理，我不会将其标记为糟糕的应用程序。
-
肯定会有这样的网站进行密集的后端处理：文档，图像，音频，视频等。
-
在可能的情况下，我认为这种处理器密集型任务肯定应该以批处理模式处理。此类任务可能可以委派给 辅助机器 .如果作业超过设定的持续时间，用户可以选择作业完成通知。您还可以向在作业仍在处理时注销的用户发送作业完成通知。
-
考虑到用户扩容，扩容资源可能是有意义的。计算资源规模要求可能不是一件容易的事。您可以使用日志来找出处理的文档数量以及它们平均花费的持续时间以及高峰使用时间。这些数字与当前的平均并发用户数相结合，可以帮助您粗略估计资源扩展。
过于依赖意见，但无论如何。
1）取决于用户的期望。如果我知道我发送的工作请求会很重，也许我不会觉得它太慢。如果是浏览静态内容，那就是。同样，我不希望下载图片的时间与下载电影的时间相同。
2）不是我知道的。但同样，您的网站为用户提供了什么？
3）对于15-20秒，我不会说它需要重新设计以支持批处理作业。当它进入分钟时，也许。
4）没有详细的研究就不可能知道。只是你需要更多的CPU/内存？或者可能存在同步问题，拥有更多用户会导致问题呈指数级增长？不要忘记，当你解决瓶颈时，只是因为其他东西已经成为瓶颈。