讨论:“一台主机、一个CPU”,用UDP实现单位时间内最大并发数的接入服务器的方案。设计方案不考虑特定OS系统。
为了简化讨论,我们简化该服务器的流程:接收UDP包---->处理数据包。流程就两步,且假设接收
UDP包的时间Tr和处理数据包的时间Tp的关系为:Tp = K*Tr。
设计方案一:一个线程处理整个流程。
设计方案二:一个接收线程+一个缓冲队列+一个处理线程。
设计方案三:N个接收线程+一个缓冲队列+一个处理线程,其中N > 1。
设计方案四:N个接收线程+N个缓冲队列+一个处理线程,其中N,M > 1,N和M可以相等。
为更有利于讨论,我们再假设Tp = K*Tr中的K相当大,也就说,相对Tp,Tr可忽略不计(现实应用中大部分情况也是这样的^-^)。
在K足够大的情况下,可以肯定,方案一并发性能是最差的。
方案二实现起来最直观,要作数据写入队列和从队列读出数据时的同步,由于我们关心的写入性能,所以不用Multi Read Single Write锁进行同步。这里在要注意的是,从队列读出数据后就要解锁。
方案三多了一些接收线程,但所有的接收线程和处理线程在写数据到缓冲队列列时都要作同步。
方案四是一个接收线程对应一个缓冲队列,接收线程之间不须要同步(通过TSS),但每一个接收线程还须要和处理线程同步。(有没有方法做到当两个读写线程同时访问公共资源的时候,不须要作同步?^-^)。
我在这方面的经验不多,就两年前做过一个即时通信的接入服务器。当时做这个系统的时候,领导们催得紧,选择方案三,也经得起压力测试。
但我现在想想,在一个CPU的情况下,方案二的性能比方案三的性能来得更高一些。方案四相对于方案二,可能可以支持更多的并发数,但性能会下降。为什么会得出这样的结论呢?因为方案四中的接收线程间不须要同步!可以肯定的是在多CPU的情况下,方案四是首选。
我现在不从事这方面的工作了,没有那么多机器做测试,所以没有办法做这几个方案的比较测试,得出实验结果。希望兄弟们说出自己的观点;有条件的请给出测试数据。
为了简化讨论,我们简化该服务器的流程:接收UDP包---->处理数据包。流程就两步,且假设接收
UDP包的时间Tr和处理数据包的时间Tp的关系为:Tp = K*Tr。
设计方案一:一个线程处理整个流程。
设计方案二:一个接收线程+一个缓冲队列+一个处理线程。
设计方案三:N个接收线程+一个缓冲队列+一个处理线程,其中N > 1。
设计方案四:N个接收线程+N个缓冲队列+一个处理线程,其中N,M > 1,N和M可以相等。
为更有利于讨论,我们再假设Tp = K*Tr中的K相当大,也就说,相对Tp,Tr可忽略不计(现实应用中大部分情况也是这样的^-^)。
在K足够大的情况下,可以肯定,方案一并发性能是最差的。
方案二实现起来最直观,要作数据写入队列和从队列读出数据时的同步,由于我们关心的写入性能,所以不用Multi Read Single Write锁进行同步。这里在要注意的是,从队列读出数据后就要解锁。
方案三多了一些接收线程,但所有的接收线程和处理线程在写数据到缓冲队列列时都要作同步。
方案四是一个接收线程对应一个缓冲队列,接收线程之间不须要同步(通过TSS),但每一个接收线程还须要和处理线程同步。(有没有方法做到当两个读写线程同时访问公共资源的时候,不须要作同步?^-^)。
我在这方面的经验不多,就两年前做过一个即时通信的接入服务器。当时做这个系统的时候,领导们催得紧,选择方案三,也经得起压力测试。
但我现在想想,在一个CPU的情况下,方案二的性能比方案三的性能来得更高一些。方案四相对于方案二,可能可以支持更多的并发数,但性能会下降。为什么会得出这样的结论呢?因为方案四中的接收线程间不须要同步!可以肯定的是在多CPU的情况下,方案四是首选。
我现在不从事这方面的工作了,没有那么多机器做测试,所以没有办法做这几个方案的比较测试,得出实验结果。希望兄弟们说出自己的观点;有条件的请给出测试数据。