问题标签 [latency]

I am playing around with linux network programming and I wrote a little client server app which bounces a small message between a client and a server process and measures the round trip time. Consistently I see around 80ms for localhost round trip (this is after connection setup). This seems extraordinarily high. The same machine running the same code will clock substantially below 1ms on Vista.

Any ideas on where this difference could come from? The code is pretty straightforward, accept on one end, connect on the other and then just send/receive through the peer socket.

I am just begining on Linux, apologies if this is a silly question.

我正在研究制作一些使键盘功能像钢琴一样的软件（例如，用户按下“W”键，扬声器播放 D 音符）。我可能会使用 OpenAL。我了解数字音频的基础知识，但是响应按键播放实时音频会带来一些我无法解决的问题。

问题是：假设我有 10 个音频缓冲区，每个缓冲区保存一秒钟的音频数据。如果我必须在通过扬声器播放缓冲区之前填充缓冲区，那么我将在播放缓冲区前一两秒填充缓冲区。这意味着每当用户尝试弹奏一个音符时，在按键和播放音符之间会有一到两秒的延迟。

你如何解决这个问题？您是否只是使缓冲区尽可能小，并尽可能晚地填充它们？有什么我错过的技巧吗？

发布订阅场景下如何实现WCF服务器的低延迟？具体来说，客户端订阅数据并接收更新，有问题的延迟是在数据更改和客户端接收更改之间？CPU、内存、带宽要求并不重要，可能很高。

基础很明显：二进制序列化、命名管道等。但是，例如，通过始终连接的流发送数据是否有意义？或者将批量更新作为单个消息发送以减少 RPC/标头开销？

可能有一些带有代码或接口的项目可用作示例吗？

这里有几个问题。

想象一下，我有客户端 A 将向服务器发送以下消息：“开始移动”。

服务器不会立即收到此消息，因为延迟会导致延迟。

问题 1：ping（或更好：往返时间​​）是客户端向服务器发送消息并收到响应所需的时间。如果您可以忽略服务器注意到它已收到消息并开始发送响应所需的时间（这应该很短），这是否意味着以下情况？

1. 客户端向服务器发送某些信息所需的时间 = 往返时间 / 2
2. 服务器向客户端发送内容所需的时间 = 往返时间 / 2

因此，当客户端 A 发送该消息时，服务器应该会在客户端发送消息后的往返时间/2 毫秒内收到该消息。这引出了下一个问题。

问题 2：客户端是否应该先发送包，然后等待往返时间/2 毫秒，然后才能在客户端实际执行该命令（在这种情况下：向前移动）以补偿延迟/滞后？

现在，服务器将向附近的所有玩家发送以下消息：“客户端 A 正在向前移动”。然后，这些客户将确保客户 a 的角色开始移动，这将引导我进入下一个问题。

问题3：接收其他客户端移动的消息的客户端是否应该考虑到该消息是由服务器往返时间/ 2毫秒前发送的？因此，用于移动计算时间戳的当前时间应该减少往返时间/2？

在我看来，所有这些方法都会确保客户端之间的同步得到改善，因为考虑到了延迟。这是正确的做事方式吗？大多数其他优秀的多人游戏都这样做吗？您想给出任何评论、建议、替代方案或随机但相关的呼喊？提前致谢。

我正在寻找选择“最佳”网络服务器的最佳方法。用例：在家中的用户需要通过任何一个地理上分散的服务器访问网络，我们希望我们的桌面应用程序在一秒钟内自动选择一个。服务器阻止 ICMP 数据包，因此 ping 不起作用。我们正在考虑向每个服务器发送 HTTPS HEAD 请求并测量响应时间。我们不得不排除地理上的邻近性。

有什么建议么？

我有一个客户端-服务器应用程序，它从几个表中获取所有数据，重新计算并存储它。

例子：

每个项目都有一个“材料清单”= 其他项目的清单和数量。因此，一个项目的成本是其 BOM 中项目的成本 * 它们的数量之和。最终，一些“基础”项目没有 BOM，只是独立设置成本。（即：原材料）

即：A 的 BOM 说它由 2xB 和 3xC 制成。

我现在所做的，我不记得我为什么这样做，是我从数据库中获取所有项目和所有 BOM，并一次针对每个项目递归计算其成本。一旦我计算了一个项目，我就会标记它，这样我就不会再重做成本了。（也防止无限递归）

事情是，这有点愚蠢：首先，它很慢并且会重新计算没有改变的东西，更糟糕的是，给它一个足够大的数据库，它会耗尽内存。

相反，我可以按需重新计算项目：当一个项目的 BOM 发生变化时，我重新计算该 BOM，然后选择包含此更新项目的所有 BOM，并重新计算它们；冲洗并递归重复，直到到达顶部，数据库中没有 BOM 依赖于任何更改的项目。

这在实践中意味着什么：假设一些项目是原材料，其成本可能会经常更新，而一些项目是“最终用户”的东西，它们的 BOM 很少会改变。当用户更改其中一种材料的成本时，可能意味着要处理数千个项目，重新计算它们。假设 1 个项目/BOM 的 SELECT 需要 15 毫秒（我在 Postgresql 上），然后仅 SELECTing 1000 个项目/BOM 将需要 15 秒，然后您必须将重新计算的成本更新回数据库中的项目......哦亲爱的，延迟现在可以变成几分钟。

我工作的公司使用的 ERP 软件采用第一种方法：一次批量重新计算整个数据库。从字面上看，这需要几个小时，而且在 10 多年的使用中，这种方法似乎已经出现了问题。批量重新计算每周进行一次。

既然我实际上已经“大声写出来”，我认为几分钟的时间并不重要。问题是我不太了解数据库，而且我担心并发性：由于在项目 A 上更新需要很长时间，因此很可能有人会在项目 A 正在更新期间更新第二个项目 B更新。

假设 D 项是由上面的 A 和 B 组成的。用户 1 更新 A，因此服务器软件开始与数据库自慰几分钟，最终更新 D。但与此同时，用户 2 更新 B，因此服务器最终将再次更新 D。

使用 Postgresql 的事务会解决问题吗？事务从数据库的当前状态开始，因此事务 1 看到 D 由 A1 和 B1 组成，并将 A 从 A1 更新到 A2，但在它完成并提交之前，事务 2 将开始，也看到 A1和 B1。T1 重新计算并提交，D = A2 + B1。但是T2已经开始了，并没有看到新的A，A2。因此，它最终将 D = A1 + B2 提交给 DB，这是不正确的。它应该是 D = A2 + B2。

此外，一些处理会重叠，浪费服务器时间。

如果我按顺序而不是并行执行 T1 和 T2，那么万岁，答案是正确的，但用户 2 将不得不等待更长时间。此外，如果一组事务彼此没有关系（完全独立的......依赖树；即：A=X+Y 和 B=N+M），那么并行计算将给出正确的答案并且对于用户。

重要提示：即使按顺序处理，我仍然会使用事务，因此软件的其余部分仍然可以并行处理该数据，除了重新计算成本的功能。

现在，如果……数据库延迟不会那么“糟糕”，那么整个“按顺序处理”的事情就不会那么糟糕了。比如说，如果整个数据都保存在 RAM 中，那么处理 1000 个对象将是轻而易举的事。啊，但是即使我构建了一个系统来快速将大块数据移入/移出磁盘/RAM并进行一些缓存 - 以替换 DB - ，那也行不通，因为我仍然需要事务，以便服务器的其余功能可以并行工作。（上面的“重要说明”）所以我最终会建立另一个数据库。可能会快一点，但它愚蠢/浪费时间。

我“缓存”每个项目的成本的全部原因是我每次使用它时都不会重新计算它，因为它不仅浪费了有限的资源，而且数据库延迟太大而且并发问题的规模更大。

现在我不需要奇怪为什么“他们”会大批量这样做……这让我很头疼。

Q1：你们如何以“最佳”方式解决这个问题？

根据我目前的理解（即在遇到之前我默默忽略的并发问题之后），我会让那个函数按顺序使用事务，而应用程序的其余部分仍然可以并行使用数据，我相信最适合用户。这就是目标：对用户最好，但保证系统的正确性。

也许稍后我可以向它扔硬件并使用软件黑魔法来减少延迟，但我现在开始对自己撒谎。

另外，在过去的几个月里，我对一些显而易见的事情完全视而不见（有些与编程无关），所以我期待有人会指出一些我设法错过的可耻的明显事情......： |

嘿，我有一个应用程序的临时分发，我正试图放在客户手机上。在使用 iTunes 同步到我们的测试手机后的初始加载中，我看到 30 秒的加载时间，直到应用程序显示主屏幕。然而，随后的每一次加载都快如闪电。

我只是想知道临时分发的第一次加载是否会出现更多延迟，或者我只是做错了什么？

我有多个应用程序进程，每个进程都连接到服务器并从它们接收数据。通常，连接到的服务器和正在检索的数据在进程之间重叠。因此，整个网络中存在大量不必要的数据重复，超出应有的连接数量（这会对服务器造成负担），并且数据最终会冗余地存储在应用程序的内存中。

一种解决方案是将多个应用程序进程组合成一个进程——但在大多数情况下，它们在逻辑上确实是不同的，这可能需要多年的工作。

不幸的是，延迟非常重要，并且数据量很大（任何一个数据都可能不会太大，但是一旦客户端发出请求，服务器就会随着数据的变化发送快速的更新流，这可能超过20MB/s，所有这些都需要以尽可能短的延迟提供给请求的应用程序）。

想到的解决方案是编写一个本地守护进程，应用程序进程将从中请求数据。守护进程将检查是否已经存在与适当服务器的连接，如果不存在则建立连接。然后它会检索数据并使用共享内存（由于延迟问题，否则我会使用套接字）将数据提供给请求的应用程序。

短期内只解决冗余连接的一个更简单的想法是使用 unix 域套接字（这将在 unix 操作系统上运行，尽管我更喜欢在可能的情况下坚持使用跨平台库）在所有进程，因此它们共享一个连接。这样做的问题是消耗缓冲区——我希望所有进程都能看到来自套接字的所有内容，如果我对这种方法的理解正确，则在套接字上的一个进程中读取将阻止其他进程在其上看到相同的数据下一次读取（共享描述符中的偏移量将被碰撞）。

是否有参考列出了通过网络（udp 与 tcp/ip）、磁盘、内存（顺序/随机访问）、进程内与进程间等传输信息大约需要多长时间（以相对或绝对术语） .?

最终我将不得不测量这些，但我会欣赏指向球场数字的指针。

内存 vs 磁盘并不难找到，但我想了解其余数字的方位。

我的 Web 应用程序需要尽可能少的延迟。我曾尝试将其托管在专用服务器上，但世界另一端的用户抱怨延迟问题。

所以我正在考虑使用 CDN 或亚马逊服务.... 会帮助解决这个问题吗？

该应用程序使用了大量的 AJAX，因此延迟可能是一个问题。