我开始阅读著名的 Martin Fowler 书（企业应用架构模式）
我不得不提到我正在阅读翻译成我的母语的书，所以这可能是我误解的一个原因。
我找到了他们的定义（回译成英文）：
响应时间 - 处理某些外部请求的时间量
延迟 - 得到任何响应之前的最短时间。
对我来说是一样的。你能强调一下区别吗？
【问题讨论】：
标签： performance latency throughput low-latency
看待这个问题的一种方式是说传输延迟 + 处理时间 = 响应时间。
传输延迟是请求/响应传输到/从处理组件所需的时间。然后您需要添加处理请求所需的时间。
例如，假设有 5 个人尝试同时打印一张纸，打印机需要 10 秒来处理（打印）每张纸。
处理打印请求的人首先看到 延迟 为 0 秒，处理 时间为 10 秒 - 所以 >响应时间为 10 秒。
而处理打印请求的人最后看到 延迟 40 秒（他之前的 4 个人）和 处理 时间10 秒 - 所以 响应 时间为 50 秒。
【讨论】：
正如 Martin Kleppman 在他的《设计数据密集型应用程序》一书中所说：
延迟是请求等待处理的持续时间 - 在此期间它处于潜伏状态，等待服务。用于诊断目的，例如：延迟峰值
响应时间是客户端发送请求和接收响应之间的时间。它是往返延迟和服务时间的总和。用于描述应用程序的性能。
【讨论】：
article 很好地了解了差异，最好用这个简单的公式来概括，
延迟 + 处理时间 = 响应时间
在哪里
如果处理时间相当短（在设计良好的系统中就是这种情况），那么出于实际目的，响应时间和延迟在感知的时间流逝方面可能是相同的。也就是说，准确地说，使用定义的术语，不要混淆或混淆两者。
【讨论】：
我用下面的例子来区分这个，
已从 A-B-C 发送了一个包裹，其中 A-B 用了 10 秒，B（处理）用了 5 秒，B-C 用了 10 秒
延迟 = (10 + 10) 秒 = 20 秒
响应时间 = (10 + 5 + 10) 秒 = 25 秒
【讨论】：
延迟 从源发送数据包到目标接收数据包的时间
延迟是消息或数据包从其源点传输到目标点所需的时间。这是一个简单而有用的定义，但它通常隐藏了许多有用的信息——每个系统都包含多个源或组件，这会影响传递消息所需的总时间，了解这些组件的含义很重要是什么决定了他们的表现。
让我们仔细看看互联网上典型路由器的一些常见贡献组件，它负责在客户端和服务器之间中继消息：
传播延迟
消息从发送者传送到接收者所需的时间，它是距离与信号传播速度的函数。
传输延迟
将所有数据包的位推入链路所需的时间，它是数据包长度和链路数据速率的函数。
处理延迟
处理数据包标头、检查位级错误和确定数据包目的地所需的时间。
排队延迟
数据包在队列中等待处理的时间。
客户端和服务器之间的总延迟是刚刚列出的所有延迟的总和 响应时间 数据包从接收方发送和接收数据包之间所用的总时间
【讨论】：
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，最常表示为 TRANSPORT-LATENCY（在一对 REFERENCE_POINT 之间）与跨某种通道的琐碎/原始事件传播，其中事件处理不会转换传播事件的内容。 （参考内存访问延迟 - 不重新处理数据，而只是交付它，需要一些时间来“制作”）
PROCESSING 意味着以某种非凡的方式在 SuT 组件内转换事件。
响应时间（在同一 SuT 组件的 REFERENCE_POINT(s) 上观察到）表示某种相当复杂的端到端事务处理的结果持续时间，即既不是一个微不足道的TRANSPORT LATENCY 跨通道，也不是一个简单的 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]-back-to-[A] 传递答案）直到在给定的 REFERENCE_POINT 上收到预期的响应（无论是同一个 [A.0] 还是另一个，特定目的的 [A.37] ）。
尽可能明确可以避免未来潜在的误解（国际行业标准一直在努力避免这种误解）。
所以一个需求表达如下：
1) RESPONSE_TIME(A.0:A.37) 必须在 125 [ms] 之下
2) 在每个 BAU 不到 0.1% 的情况下，净 TRANSPORT LATENCY(A.1:B.1) 应该超过 30 [ms]
清晰可靠（易于测量），感兴趣的每个人都可以解读 SuT 设置和测试结果。
满足这些明确的要求有资格这样定义的 SuT 行为安全地符合预期的一组行为，或者让专业人员以低成本检测、记录和取消那些不符合要求的行为。 p>
【讨论】：