我发现了很多博客，并回答了延迟与吞吐量的关系。但是他们都没有把它与平行关系联系起来。 我想知道为什么我们不能把它们联系起来，如下所示：我们是否可以将延迟和吞吐量与并行性相关联
如果与延迟相比吞吐量较大，那么应该涉及到并行性。 （假设没有优化，同时批处理）
例如，延迟10ms和1000 tps意味着tps增加（因为10ms延迟意味着100tps），那么多线程或并行性参与的可能性很大，可能在CPU级别。如果多个事务批处理时没有优化。
另外， 什么因素会增加吞吐量而不是延迟。
延迟时间是纯粹的时间单位和吞吐量（这是每单位时间完成的工作量）部分与时间有关。
在单线程环境中，你可以认为这两个反向相关，潜伏期即更高，降低了吞吐量等
并行看作另一个层面这个矩阵。在可能的情况下（），并行会提高吞吐量，达到一定限度。然而，这可能会受到系统中设备的延迟的影响。例如，设想一个工作频率为2GHz的单线系统和一个工作频率为300MHz的4元件并行系统。为简单起见，假设应用程序是embarrassingly parallel。在这种情况下，单线程将比平行线更好。现在，如果我们将并行单元的运行速度提高到501 MHz，那么它们将超越单线程单元。
好吧我已经更新了这个问题，因为一些清晰度问题。我的问题是，与延迟相比，增加吞吐量的因素是什么？ – Krishas
简而言之：与并行性无关的批处理（以延迟为代价增加吞吐量）可能有很多优点。有时会有固定的单位成本;有时更全局的优化可能会产生很大的影响;有时可以找到并丢弃重复等等。
747个硬盘可能是在世界范围内发送数据的最高吞吐量方式，与并行性无关。
正确投票，正如我在我的问题中提到的优化是肯定存在的（增加了更多的清晰度问题）。 但在目前的情况下，第三方供应商表示他们的产品有3ms延迟和100万tps（可能是某些内存数据库，队列等）。这让我感到困惑。他们以3节点集群为例进行论证。在这种情况下，可能会有10-20个内核和20-50 GB的内存和延迟，这就涉及到单个事务，这隐藏了当我们谈论TPS时并行性是主要部分的事实。 – Krishas
我认为你不能这样简化它，因为在所有的并行管道所依赖的地方可能有数据不能被并行化。 – JDC
我同意你的意见。我认为在我的问题中存在一些清晰度问题，所以我删除了方程并更新了它。 – Krishas