应用架构考虑因素的延迟数量级

发布于 2024-08-07 04:21:30 字数 152 浏览 8 评论 0原文

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

最终我将不得不测量这些,但我会很高兴能提供大概的数字。

内存与磁盘的比较并不难找到,但我想了解其余数字的方位。

Is there a reference which lists approximately how long it takes (in relative or absolute terms) to transfer information over network (udp vs tcp/ip), disk, memory (sequential/random access), in-process vs inter-process, etc.?

Eventually I'll have to measure these, but I'll appreciate pointers to ball-park figures.

Memory vs disk is not hard to find, but I' like to get my bearings for the rest of the numbers.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

聊慰 2024-08-14 04:21:30

我还没有遇到过类似的事情,我认为除了测试您的特定场景之外,没有其他方法了。
涉及的因素太多,无法给出一致的答案:
例如,您使用什么网卡,它们是否进行 TCP 校验和卸载,您的交换结构的性能如何,您使用什么磁盘,它们有多少缓存,您传输多少数据,大量小数据包或一些大数据包 。

当您谈论 RAM 访问时间时,您现在谈论的是 10-100ns,而硬盘驱动器可能约为 4-8ms 任何基准测试工具都应该为您提供 RAM 和内存方面的良好结果。 硬盘驱动器测量

另一方面,如果 UDP 与 TCP,您确实无法给出任何具体数字。理论上,UDP 应该比 TCP 快 30-50%,因为它缺少 ACK 的额外行程并且具有较小的标头开销,但实际上,在很多情况下,TCP 仅仅因为拥塞控制而优于 UDP。此外,带有 Nagle 的 TCP 开启了批量数据包,这与不这样做的 UDP 相比又不公平。

总而言之,真正根据自己的需求去做自己的测试。即使周围有运行类似测试的人的基准表,它们也可能对您的应用程序和应用程序完全无效且不可重现。硬件堆栈

I haven't come across anything like that yet and I think there is not really any other way than testing for your specific scenarios.
There are way too many factors involved to give a consistent answer:
e.g. what NIC's are you using, are they doing TCP checksum offloading, how performant is your switching fabric, what disks are you using, how much cache do they have, how much data are you transferring, a lot of small packets or a few large packets, etc., etc.

When your are talking RAM access times you're talking about 10-100ns nowadays, vs probably around 4-8ms for harddrives. Any benchmark tool should give you good results for RAM & harddrive measuring

UDP vs. TCP on the other hand, you really can't give any specific numbers. Theoretically UDP should be be 30-50% faster than TCP because it's missing the extra trip for the ACK and has a smaller header overhead, however in reality there are many cases where TCP would outperform UDP just because of congestion control. Also, TCP with Nagle turned on batches packets, which again wouldn't be a fair comparison to UDP which doesn't do that.

All in all, really do your own testing according to your needs. Even if there was a benchmark sheet somewhere around of someone who ran similar tests, they might be completely invalid and non reproducible for your application & hardware stack

GRAY°灰色天空 2024-08-14 04:21:30

给汤姆+1 - 这就是我在看到他的答案之前要写的内容(只是不太清楚)。

另一件需要考虑的事情是

  1. 延迟需求与带宽需求

  2. 给定解决方案的可扩展性。例如

    • 升级网络速度(是否需要更换网卡?布线?路由器?)与可能规模的大小(100Mb 与 1Gb)相比有多困难?

    • 升级磁盘速度与速度提升回报有多困难?

    例如,更快的磁盘、具有更大缓存的磁盘(假设您的用例运行的是可缓存数据、RAID 或其他数据条带化、本地存储与网络存储)。

换句话说,您今天的情况可能表明,确切的指标表明磁盘是考虑到所有因素的最佳解决方案,但您很少可以将磁盘性能提高 10 倍,而如果确实需要,您可以通过网络来实现这一点。

+1 for Tom - that's what I was going to write (just less clearly) before I saw his answer.

Another thing to consider is

  1. latency needs vs. bandwidth needs

  2. scalability of a given solution. E.g.

    • How difficult is it to upgrade the network speed (Do you need to replace NICs? wiring? routers?) vs. magnitude of possible scale (100Mb vs. 1Gb)?

    • How difficult is it to upgrade the disk speed vs. speed increase payoff?

    E.g. faster disk, disk with bigger cache assuming your use case runs towards cache-able data, RAID or other data striping, local storage vs. network storage.

In other words, your situation today may indicate that exact metrics point to disk as the best solution all things considered, but you can rarely up disk performance by 10x whereas you can plausibly do so with network if really needed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文