Performance （软）实时延迟是否有一个普遍可接受的定义？

我正试图找到一个基准，来衡量用户愿意等待远程服务响应的时间。在我的例子中，响应用于非常有用但不是关键业务的数据输入验证。我想在HCI空间中一定做了一些这方面的工作

如果你知道软实时响应的一个普遍接受的定义，那么很好，但我也很感激你的理性思考

---

克里斯

不幸的是，这个问题的答案通常不是一个定义明确的数字。用户的期望差异很大，可能会根据您所谈论的内容而变化

随着计算机越来越普及，我们（消费者）对速度的期望也越来越高，远程服务、网站甚至应用程序都需要继续更快地响应。一般来说，你希望一切尽可能快

说到这里，我想看看你的远程服务是为了什么。因为你说，“回复非常有用…”对我来说，这意味着它可能会被频繁使用。人们倾向于使用有用的东西。如果是这样的话，我会想办法让远程服务快速响应

---

当然，还有一个警告，您不希望在编写服务之前就开始优化。当前的响应时间是多少？这将在什么环境下使用？这些因素将在很大程度上决定用户愿意等待服务的最长时间。

人类的反应时间似乎很长——周围的任何东西都会被认为是瞬间的。这种数字很难实现，尤其是在从远程服务获取信息的应用程序中

如果你看一下谷歌的搜索建议框，它的延迟是最小的——不到一秒钟。它的速度惊人，对于一个web应用程序来说真的很了不起。这对谷歌的用户来说真的很好，但对你来说却是个坏消息。如今，用户期望大多数应用程序以同样的速度和效率做出反应；任何慢一点的都被认为是相当滞后的。然而，值得注意的是，人们的耐心通常随着手头任务的复杂性而变化。一个简单的表单提交应该不会花费太多的时间，但是像上传照片这样的事情需要一段时间

---

我的感觉是：凭直觉行事。如果您的应用程序相当简单，那么您应该尝试将等待/加载时间缩短到不到一秒钟。如果不能，那么最好的办法就是添加一个指示器，这样用户就知道一些计算是在后台进行的。这可以是一个小动画或进度条的形式。

您可能需要搜索“SLA”或“服务级别协议”。这些是web业务中的文档，保证数据返回用户所需的时间，无论是HTML文档还是web服务调用。

美国国防部MIL-STD 1472-F人体工程学标准对最大允许响应时间有最广泛接受的要求（见表XXII，第196页，秒数）:

关键响应（按下关键点直到正面响应，例如“单击”）：0.1

按键打印（按下按键直到出现字符）：0.2

翻页（请求结束，直到前几行可见）：1.0

页面扫描（请求结束，直到文本开始滚动）：0.5

XY输入（从选择字段到目视验证）：0.2

功能（从选择命令到响应）：2.0

定点（从输入点到显示点）：0.2

草图绘制（从点的输入到线的显示）：0.2

本地更新（使用本地数据库更改图像，例如，新菜单列表）：0.5

主机更新（从显示缓冲区）：2.0

文件更新（数据以易于访问的形式在主机上的更改）：10.0

查询-简单（例如，现有图像的比例变化）：2.0

查询-复杂（图像更新需要访问主机文件）：10.0

错误反馈（从命令到显示常用消息）：2.0

如您所见，可接受的响应时间取决于用户等待的响应。对于出现的下拉菜单，最长为0.5秒。对于浏览器中的完整页面加载，您希望在1.0秒到2.0秒之间出现一些内容，并在10.0秒内加载完整页面。在上述所有情况下，响应时间越短越好。只有在奇怪的情况下，用户才会反对0.001s的响应时间

在任何情况下，如果响应时间大于0.5秒，那么您需要提供反馈，例如跳动器或沙漏精灵。如果响应时间至少为5-15秒（取决于您使用的标准），请提供进度条。有了进度条，很长的响应时间（订单上的响应时间或几分钟甚至几个小时）是可以接受的，只要您将其设置为“批处理”过程，而不是交互式程序。对于用户来说，进行所有输入并等待一个小时比进行四次输入（每次输入后等待15分钟）要好得多

---

上述清单具有公认的标准。用户愿意等待多长时间（例如，在放弃之前）基本上取决于用户进行成本效益分析。我要得到的东西值得等待吗？我的沉没成本是多少？是否有其他方法（例如，另一个网站）可以做得更好？我可以在等待充分利用时间的同时做其他事情吗？然而，无论用户愿意做什么，你可以打赌他们都会对超过上述标准的延迟感到不满。

谢谢。顺便说一下，200毫秒是不可能实现的，往返网络延迟很容易被淹没。我想，对于基于Web的应用程序来说，标准的浏览器进度机制（旋转地球仪等）将不足以表示进步。我会考虑浏览器节拍。