关于Exosip的效率问题

最近一段时间利用boost多线程和ACE多线程，对eXosip的性能进行了比较深入一些的测试。现将测试方法分享一下，在此抛砖引玉，希望大家也可以提供一些建议。
首先，原始的EXOSIP只有2个线程，一个做的事情很简单，是等待事件，另外一个线程非常忙，要做事务状态的转换，要收消息，要解析消息，要上报事件。
我所做的修改就是将不同的事情分开到不同的线程，相当于简单地修改EXOSIP。
修改步骤如下：
1 exosip_wait保持原来的调用方法，但是这个方法中有一些多余的代码暂时屏蔽（也可能是暂时不能理解）
2 将从5060端口收数据放到一个线程池A中做，这样SOCKET就不会阻塞了。
3 将处理收到的消息放到线程池B中做，消息处理很复杂，这个线程池中线程的数量也是最大的。
4 将做事务状态转换的事全放到一个线程中做，事务状态转换是关键，量也很大，状态的转换速度决定着exosip_wait的返回频率。
以上是多线程的改造
在以上四个线程池的线程数达到48:64:128:256的时候性能达到最优，处理能力达到2500条每秒。测试的机器是我们机房的那个CVSS上面安装的虚拟机。这个机器是4核的，如果配置再高一些，线程数可以再提高一些，数据也会更好。

下面解释一下和四个状态机相关的四个时间：
//sufu#define DEFAULT_T1 500 /* 500 ms 国标推荐 */

#define DEFAULT_T1 2 /* 测试使用的值*/
//sufu #define DEFAULT_T2 4000 /* 4s 国标推荐*/

#define DEFAULT_T2 2 /* 测试使用的值*/
//sufu #define DEFAULT_T4 5000 /* 5s国标推荐 */

#define DEFAULT_T4 2 /* 测试使用的值*/
这四个数字的具体使用，可以再代码中搜索，并调试程序去了解。
其实这几个值并不是影响测试数据的最终原因！！！
我有一个粗浅的解释，osip的状态机使用了定时机制，比如，一个事件的处理有S1 S2 S3个状态，服务端在将S1状态转换到S2状态前，要看所定的时间到了没有。时间没有到，就不做状态转换，当然，状态转换是要做一些其他的工作的。

试想一下，如果S1到S2花500毫秒，S2到D3花500毫秒，那我处理一个完整的事件就花掉了1秒，那我一个客户端1个线程1分钟就干60件事情，60个线程才做3600件事情，10台电脑1分钟也就做36000件事情。当然，理论上如果有30台电脑，每台电脑上开60个线程，1分钟就可以做72000件事情，但我们的目标是1分钟要做3000*60甚至更多事情。
所以只能暂时修改一下服务端的状态机转换间隔，一步步地缩小，直到2ms,甚至1ms，来替代客户端数量的不足。

改造以后，数据达到2500条每秒，激励我们的目标还差每秒500~1000，但是我们的服务器性能还是可以提升的，我们的程序研究也还在初步阶段（大约8个工作日），所以优化工作还是可以继续进行的，而一旦程序优化成果，我们后面要做的sip服务器的开发工作量就少了很多。