我正在开发自己的UDP协议(在Linux下),用于缓存应用程序(类似于memcached),它只对对象执行INSERT / READ / UPDATE / DELETE操作,我不确定哪种设计是最好的:
请求的大小(即记录数据)可以是32字节到1400字节,我不知道平均是哪一个,它完全取决于用户的应用程序。
如果为每个数据包选择单个请求,我将不得不管理很多小数据包,并且内核会被多次干扰。这将减慢操作,因为内核在从用户空间切换到系统时必须保存寄存器。数据传输也会有开销,如果用户的应用程序发送许多32字节的请求(udp的数据包开销大约是28字节)网络流量将翻倍,我将对传输速度产生很大影响。然而,高网络流量不一定意味着低性能,因为NIC具有其自己的处理器并且不会使CPU停滞。如果出现网络瓶颈,可以安装额外的网卡。 使用单个数据包的最大好处是服务器和客户端将非常简单,我将节省指令并提高速度,同时我将有更少的错误,项目将提前完成。
如果我每个数据包使用多个请求,我将拥有更少但更大的数据包,因此可以通过网络传输更多数据。我将减少系统调用的数量但是服务器的复杂性将需要更多的内存和更多的指令来执行,因此我们不知道是否以这种方式执行更快的执行。可能会发生CPU将成为瓶颈,但更便宜的是添加CPU或网卡?
应用程序应该有大量数据加载,例如最新CPU上每秒100,000个请求。我不知道该怎样做。我正在考虑“每个数据包的单个请求”,但在重写我已经为多个请求处理编写的所有代码之前,我想请求建议。
提前致谢。
答案 0 :(得分:1)
您更关心的是什么:延迟或带宽?
注意:除非您在极速网络上运行,否则网络(而非CPU)可能是您的主要瓶颈。即使你这样做,数据库中的INSERT / READ / UPDATE / DELETE可能会花费更多的CPU和I / O而不是数据包所需的CPU工作量。
答案 1 :(得分:0)
每个数据包发送多个请求的另一个折衷是
但是,如果不了解部署体系结构(例如NIC,交换机和路由器的缓冲区大小以及其他网络硬件),则分析是不完整的。
但建议是从一个相对简单的实现(每个数据包的单个请求)开始,但是以这样的方式编写代码,以便在需要时添加更多复杂性并不困难。