对(软)实时延迟有一个普遍接受的定义吗?

美国国防部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.001秒的响应时间。

在任何情况下,如果响应时间大于0.5秒,那么您需要提供反馈,如throbber或沙漏精灵。如果响应时间至少为5-15秒(取决于您使用的标准),请提供一个进度条。使用进度条,只要将用户的响应时间设置为“批处理”而不是交互程序,则可以接受非常长的响应时间(在订单上或数分钟甚至数小时内)。对于用户来说,输入和等待一个小时要比在四个场合输入要好得多,每次输入后等待15分钟。

上述清单具有可接受的标准。你的用户有多长时间 乐意的 等待(例如,在放弃之前)本质上归结为用户进行成本效益分析。我的等待值得吗?我的沉没成本是多少?是否有其他更好的选择(例如,另一个网站)?我能在等待充分利用我的时间的时候做其他事情吗?但是,无论用户愿意做什么,您都可以打赌他们会对比上述标准更大的延迟感到不满。

人类的反应时间似乎就在眼前 200 ms -周围的一切都会被认为是瞬间的。这类数字很难实现,尤其是在从远程服务获取信息的应用程序中。

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

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

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

随着计算机的普及,我们(消费者)对速度的期望不断提高,远程服务、网站甚至应用程序都需要继续快速响应。一般来说,你希望一切尽可能快。

有了这句话,我将了解一下您的远程服务的用途。既然你说,“这是非常有用的……”对我来说,这意味着它可能会经常被使用。人们倾向于使用有用的东西。如果是这样的话,我会寻找让远程服务快速响应的方法。

当然,还有一个警告,即在编写服务之前,您不想开始优化。当前响应时间是多少?这将在什么环境中使用?这些因素对确定最长用户愿意等待服务的时间有很大作用。

您可能需要搜索 “SLA” 或 “服务水平协议” . 这些是Web业务中的文档,它们可以保证返回用户所需的数据时间,无论是HTML文档还是Web服务调用。