服务器上的 NIC 越多，是否意味着具有更持续的并发 I/O 潜力？
如果您正在尝试构建一个需要尽可能高的持续网络带宽的应用程序，以进行多个重复的文件传输（不适用于流媒体），那么拥有 2 个或更多 NIC 会有好处吗？
If you're trying to build an application that needs to have the highest possible sustained network bandwidth, for multiple and repetitive file transfers (not for streaming media), will having 2 or more NICs be beneficial?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为您的答案将取决于您的服务器和网络架构，不幸的是可能会随着它们的变化而变化。
您本质上所做的就是尝试消除整个应用程序或设计中的“当前”瓶颈，您可能已将其识别为当前的 NIC（如果您实际上尚未确认这一点，那么我会停止并检查这一点，以防其他限制达到 NIC 限制之前的吞吐量）。
关于此类性能优化的一些一般要点：
值得检查一下您是否可以选择将当前的 NIC 升级到更高带宽的接口 - 如果可以避免添加负载平衡硬件，这对您来说可能是一个更简单的解决方案/software/configuration 到您的应用程序。
同样，值得检查一旦做出此更改，如果流量继续增加，下一个瓶颈将会是什么。如果在您需要新服务器之前添加新 NIC 只能增加 5% 的吞吐量，那么立即寻找具有更好 IO 的新服务器可能会更便宜。
您的流量概况及其预测变化可能会影响您的决定。如果您的日常峰值仅略微超出您的负载，那么简单的修复可能会为您服务很长一段时间。如果您的流量稳定增长，那么可能需要对您的系统架构进行更基本的了解。
根据上面的最后一点，可能值得查看各种云产品，看看是否有任何以合理的成本满足您的要求，甚至可能作为每天的临时资源，只是为了帮助您度过高峰流量时间。
最后，您应该意识到，一旦您确定了一个解决方案并启动并运行该解决方案，组织中的其他人就会更改或升级该应用程序，从而引入新的意外瓶颈......
I think your answer will depend on your server and network architecture, and unfortunately may change as they change.
What you are essentially doing is trying to remove the 'current' bottleneck in your overall application or design which you have presumably identified as your current NIC (if you haven't actually confirmed this then I would stop and check this in case something else restricts throughput before you reach your NIC limit).
Some general points on this type of performance optimization:
It is worth checking if you have the option to upgrade the current NIC to a higher bandwidth interface - this may be a simpler solution for you if it avoids having to add load balancing hardware/software/configuration to your application.
As pointed out above you need to make sure all the other elements in your network can handle this increased traffic - i.e. that you are not simply going to have congestion in your internet connection or in one of your routers
Similarly, it is worth checking what the next bottle neck will be once you have made this change, if the traffic continues to increase. If adding a new NIC only gives you 5% more throughput before you need a new server anyway, then it may be cheaper to look for a new server right away with better IO from new.
the profile of your traffic and how it is predicted to evolve may influence your decision. If you have a regular daily peak which only exceeds your load slightly then a simple fix may serve you for a long time. If you have steadily growing traffic then a more fundamental look at your system architecture will probably be necessary.
In line with the last point above, it may be worth looking at the various Cloud offerings to see if any meet your requirements at a reasonable cost, possibly even as temporary resource every day just to get you through your peak traffic times.
And finally you should be aware that as soon as you settle on a solution and get it up and running someone else in your organization will change or upgrade the application to introduce a new and unexpected bottle-neck...
它可能是有益的，但不一定是“开箱即用”的。
您需要确保两个 NIC 都得到实际使用 - 通过将客户端分离到不同的网段、使用循环 DNS、使用通道绑定、使用负载均衡器等。最重要的是，您需要确保您的网络基础设施实际上有足够的带宽来允许更多的吞吐量。
但一般原则是合理的 - 服务器上可用的网络带宽比磁盘 I/O 少，因此添加的网络带宽越多越好，直到它达到或超过磁盘 I/O，然后它没有帮助不再是你了
It can be beneficial, but it won't necessarily be that way "out of the box".
You need to make sure that both NICs actually get used - by separating your clients on different network segments, by using round robin DNS, by using channel bonding, by using a load balancer, etc. And on top of that you need to make sure your network infrastructure actually has sufficient bandwidth to allow more throughput.
But the general principle is sound - you have less network bandwidth available on your server than disk I/O, so the more network bandwidth you add the better, up until it reaches or exceeds your disk I/O, then it doesn't help you anymore.
可能是的。实际上，它还取决于网络结构，以及网络 I/O 是否是应用程序的瓶颈。
Potentially yes. In practice, it also depends on the network fabric, and whether or not network I/O is a bottleneck for your application(s).