1

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

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

3 回答 3

2

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

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

于 2013-09-21T21:53:20.377 回答
1

这个问题有点过于依赖意见，但无论如何。

1) 取决于用户的期望。如果我知道我发送的工作请求会很繁重，也许我不会觉得它太慢。如果它正在浏览静态内容，那就是。同样，我不希望下载图片和下载电影花费相同的时间。

2) 不是我知道的。但同样，您的网站向用户提供什么？

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

4) 没有详细研究是不可能知道的。只是你需要更多的 CPU/内存？或者可能存在同步问题并且拥有更多用户会导致问题成倍增长？并且不要忘记，当您解决瓶颈时，仅仅是因为其他东西成为了瓶颈。

于 2013-09-21T21:28:57.753 回答
1

在我看来 ：

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

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

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

  4. 考虑到用户扩展，扩展资源可能是有意义的。计算资源规模需求可能不是一件容易的事。您可以使用日志来了解处理的文档数量以及它们所花费的平均持续时间以及高峰使用时间。这些数字与当前的平均并发用户数相结合，可以帮助您对资源扩展进行粗略估计。

于 2013-09-28T17:17:56.887 回答