我开始阅读著名的Martin Flowler的书（企业应用程序体系结构的模式）
不得不提的是，我正在阅读翻译成母语的书，这可能是我误会的原因。
我找到了定义（回译为英文）：
响应时间-处理某些外部请求的时间
等待时间-在获得任何响应之前的最短时间。
对我来说也是一样。能请您高亮显示差异吗？
答案 0 :(得分：3)
正如Martin Kleppman在他的《设计数据密集型应用程序》中所说：
等待时间是等待处理请求的持续时间-在此期间潜在的等待服务。用于诊断目的，例如：延迟峰值
响应时间是客户端发送请求到接收响应之间的时间。它是往返延迟和服务时间的总和。它用来描述应用程序的性能。
答案 1 :(得分：1)
一种查看方式是说传输延迟+处理时间=响应时间。
传输等待时间是将请求/响应发送到处理组件/从处理组件传输所花费的时间。然后，您需要添加处理请求的时间。
例如，假设有5个人尝试同时打印一张纸，并且打印机花费10秒来处理（打印）每张纸。
首先处理其打印请求的人等待时间为0秒，而处理时间为10秒-因此 >响应时间为10秒。
处理打印请求的人最后看到的等待时间为40秒（他之前的4个人）和处理时间 10秒-因此响应时间为50秒。
答案 2 :(得分：0)
此article很好地说明了两者之间的区别，最好用这个简单的方程式进行总结，
等待时间+处理时间=响应时间
其中
如果处理时间相当短（在设计良好的系统中就是这种情况），则出于实用目的，响应时间和等待时间在感知的时间流逝方面可以相同。也就是说，确切地说，请使用定义的术语，不要混淆或混淆这两个术语。
答案 3 :(得分：0)
我通过以下示例对此进行区分
已从A-B-C发送包裹 A-B花了10秒，B（处理中）花了5秒，B-C花了10秒
等待时间=（10 + 10）秒= 20秒
响应时间=（10 + 5 + 10）秒= 25秒
答案 4 :(得分：0)
延迟 从源发送数据包到目的地接收数据包的时间
等待时间是指消息或数据包从其原始点传播到目标点所花费的时间。这是一个简单而有用的定义，但它通常隐藏许多有用的信息-每个系统都包含多个源或组件，这对传递消息所花费的总时间有所贡献，因此了解这些组件的含义很重要以及决定其性能的原因。
让我们仔细研究一下Internet上典型路由器的一些常见贡献组件，这些组件负责在客户端和服务器之间中继消息：
传播延迟
消息从发送者到接收者所需要的时间，它是信号传播速度与距离之间的函数。
传输延迟
将所有数据包的位压入链接所需的时间，这是数据包的长度和链接的数据速率的函数。
处理延迟
处理数据包标头，检查比特级错误并确定数据包的目的地所需的时间。
排队延迟
数据包在队列中等待直到可以处理的时间。
客户端和服务器之间的总延迟是刚刚列出的所有延迟的总和 响应时间 数据包从接收方发送和接收数据包之间花费的总时间
答案 5 :(得分：0)
Q ：能否请您高亮与众不同？
让我开始使用ITU-T专业人士（前CCITT）的专业知识，他们数十年来在最高水平的专业经验上花费了数千人*年的努力，并且已经形成了准确而负责的衡量两者的方法：
自从国际行业标准成立之初（甚至在60年代的深处），这些行业专业人员就提出了以可重复和可重新检查的方式测试复杂系统的概念。
System-under-Test (SuT), inter-connected and inter-acting across a mediation service mezzo-system
SuT-component-[A]
|
+------------------------------------------------------------------------------------------------------------[A]-interface-A.0
| +------------------------------------------------------------------------------------------------[A]-interface-A.1
| |
| | SuT-component-[B]
| | |
| | +-------------------------[B]-interface-B.1
| | | +---------[B]-interface-B.0
| | ???????????????? | |
| | ? mezzo-system ? | |
+-----------+ ???????????????? +---------------+
| | ~~~~~~~~~~~~~~~~~~~~~~~~ ??? ... ... ??? ~~~~~~~~~~~~~~~~~~~~~~~~ | |
| | ~~<channel [A] to ???>~~ ??? ... ... ??? ~~<channel ??? to [B]>~~ | |
| | ~~~~~~~~~~~~~~~~~~~~~~~~ ??? ... ... ??? ~~~~~~~~~~~~~~~~~~~~~~~~ | |
+-----------+ ???????????????? +---------------+
|
无论这种方法看起来多么形式化，在制定（与设计，测试和验证时一样）与SuT组件，SuT接口，SuT通道和产品紧密相关的要求时，它都会带来清晰度和准确性。还限制了跨外部系统的交互，包括对任何外部（通常是不利的）噪声/干扰事件的出现的响应的限制。
最后，为了清楚起见，可以针对一组明确定义和记录的 REFERENCE_POINT（s）声明预期SuT行为的所有部分，该标准为此进行了定义并记录所有属性。
LATENCY （最常表示为运输 -LATENCY（在一对 REFERENCE_POINT 之间））与持续时间有关。在某种渠道上进行琐碎/原始的事件传播，其中事件处理不会转换传播事件的内容。 （参考内存访问延迟-不会重新处理数据，而只是传递数据，需要一些时间来“制作”）
处理是指在SuT组件内部以某种特殊方式转换事件的方式。
响应时间（在相同SuT组件的REFERENCE_POINT上观察到）是指某种相当复杂的端到端事务处理的持续时间，即既不是整个通道上的琐碎的 TRANSPORT LATENCY ，也不是简单的In-SuT组件内的 PROCESSING ，而是由几个（可能很多）这样的相互影响的步骤组成的某种组合，沿着因果关系链工作（在需要时添加随机刺激以表示噪声/错误干扰）。 （参考数据库引擎响应时间随着工作量的增加而蠕变，这是由于某些处理资源的并发使用增加，而在获得结果之前，这种请求的信息需要内部检索，内部重新处理以及最终交付重新处理， “答复”请求的交易方）
|
| SuT_[A.0]: REFERENCE_POINT: receives an { external | internal } <sourceEvent>
| /
| / _SuT-[A]-<sourceEvent>-processing ( in SuT-[A] ) DURATION
| / /
| / / _an known-<channel>-transport-LATENCY from REFERENCE_POINT SuT-[A.1] to <mezzo-system> exosystem ( not a part of SuT, yet a part of the ecosystem, in which the SuT has to operate )
| / / /
| / / / _a mezzo-system-(sum of all)-unknown-{ transport-LATENCY | processing-DURATION } duration(s)
| / / / /
| / / / / _SuT_[B.1]: REFERENCE_POINT: receives a propagated <sourceEvent>
| / / / / /
| / / / / / _SuT_[B.0]: REFERENCE_POINT: delivers a result == a re-processed <sourceEvent>
| / / / / | / | /
|/ /| /................ / |/ |/
o<_________>o ~~< chnl from [A.1] >~~? ??? ... ... ??? ?~~<chnl to [B.1]>~~~~~~? o<______________>o
| |\ \ \
| | \ \ \_SuT-[B]-<propagated<sourceEvent>>-processing ( in SuT-[B] ) DURATION
| | \ \
| | \_SuT_[A.1]: REFERENCE_POINT: receives \_an known-<channel>-transport-LATENCY from <mezzo-system to REFERENCE_POINT SuT_[B.1]
| |
| | | |
o<--------->o-----SuT-test( A.0:A.1 ) | |
| | | |
| | o<-------------->o---SuT-test( B.1:B.0 )
| | | |
| o<----may-test( A.1:B.1 )-------------------------------------------->o |
| | exo-system that is outside of your domain of control, | |
| indirectly, using REFERENCE_POINT(s) that you control |
| |
| |
o<-----SuT-End-to-End-test( A.0:B.0 )------------------------------------------------------------->o
| |
使用这种ITU-T / CCITT方法，定义明确的响应时间测试的示例将是完成交易的测试，该测试将测量将源事件传递到目标事件之间的净持续时间。 REFERENCE_POINT [A.0]（输入SuT-component- [A]），然后在此处等待，直到整个SuT从任何远程部分传递答案（例如从[A]至[B]的传递，再加上一个在SuT-component- [B]内部进行处理，并从[B]-向后-[A]传递答案，直到在给定的REFERENCE_POINT上收到预期的响应（是相同的[A.0]还是另一个特定目的的[A.37]。
尽可能明确，可以避免将来可能引起的误会（国际行业标准从那时以来一直在努力避免这种误解）。
所以要求表达如下：
1） RESPONSE_TIME（A.0：A.37）必须低于125 [ms]
2）在每个BAU小于0.1％的情况下，净运输延迟（A.1：B.1）应超过30 [ms]
清晰，合理（且易于测量），每个感兴趣的人都可以解释SuT设置和测试结果。
满足这些明确要求的条件是，这样定义的SuT行为可以安全地符合一组预期的行为，或者让专业人员廉价地检测，记录和取消那些不符合条件的行为。
>