partysip框架优化计划-阿里云开发者社区

Partysip优化计划

先说一下服务器构成，是使用开源的partysip项目，底层协议栈用的osip。修改了里面的注册服务器，在注册服务器上，连接mysql数据库。现在初步作了一些测试，但是感觉partysip处理过程并不满意，测试结果如下

客户端数量	客户并发数	持续时间（分钟）	服务器状态	备注
1	100	90	运行正常	单CPU占用为40%，注册服务器内存消耗为24M
1	200	12	不能处理数据	注册服务器器无响应，mysql数据无问题
2	100	10	不能处理数据	注册服务器器无响应，mysql数据无问题
2	50	30	运行正常

测试服务器的配置如下
硬件：4G memory， CPU 4核1.6GHZ，网卡：1000M双网卡

操作系统：windows2003+sp1

测试环境：注册服务器，mysql服务器同时运行。

总体上来说，注册服务器并发在200/秒时（还是客户端），只能同时保证5000人左右在线，这个数据太不理想了。这个过程肯定和数据库的访问有一定的关系，因为在注册服务器上，每有一个注册用户都需要首先遍历数据库中的表，之后根据遍历结果，决定是把用户记录写入数据库，还是修改数据库里面的记录，同时，在返回ACK时，需要再次遍历数据库，找到此用户的contect信息，并返回。访问mysql数据库的模块为单线程的。

研究过partysip，osip朋友可能知道，partysip里面对于每个插件，都开启一个线程，另有一个管理线程。整个处理过程是串行处理的，所以执行效率并不是很高，我知道基于以上的测试结果提出优化方案是比较草率的，我也需要更深入的测试，我也将进行更深入的测试，但是这需要我们充分了解partysip框架，只是现在我只是忽略了解一下，但是发现不少问题，所以，提出此优化方案，当然随着理解的深入，测试结果的详细，可能在很多细节上修改我的认识，但是从大的方面来说，partysip设计并不适合做一个产品服务器（我的个人认识），因为在代码分析中，发现了很多问题（也不能说是问题，因为partysip并没有保证说这是一个完美的服务器，确切的讲不太适合对于大并发量的数据处理），比如没有采用内存池，线程池，基于系统级别的优化（比如完成端口，epoll），所以我想从大的方面开始逐步优化，也需要然后逐步验证我的设计方案是否真实有效。

1：增加buffer（cache）

主要使用方向是：对于频繁操作数据由文件系统，转移到内存统一管理，减少访问磁盘I/O的次数，从而所以数据访问时间。

主要应用点是对数据库信息的缓存。从而减少二次访问数据库的时间消耗。

原理：对于数据库中表数据进行缓存，对于注册信息首先从此buffer中检索，如果没有找到再进行数据库查询，并把查询结果保存到buffer表中。

适用性：主要是为了优化，数据库访问功能模块，减少数据库的访问。从另一方面来说，我还考虑过把访问数据库的功能模块做成多线程的，并采用线程池进行管理，不过现在的首要目标可能是建立一个此buffer

2：内存池策略

目的：对内存空间的统一分配和管理，减少直接对内存的分配和销毁的操作，较少内存碎片的产生，保障服务器长时间高效运行，要在多线程间运行，需要采用好的信号，互斥体等机制做保障，内存池策略并非内存垃圾回收策略，对于内存泄露，内存池策略无法解决。

内存池策略的概要设计

程序首次运行时，首先获取一定容量的内存，所以其他内存内存申请，都从这个内存中获得，当内存空间不足时，再次申请一定容量的内存。其内部实现时，可以把内存空间按大小不同的结构进行划分，并用一张空闲分配表（链）进行管理，分配算法可以参考操作系统内存分配算法（最佳分配算法），关于内存分配表的建立可以参考sccot meyer《more effective C++》上面的内存池策略，令网上有大量内存池方面的论文可以参考。

适用性：使用partysip时，发现其所有的内存申请和内存释放采用的函数均为osip_malloc和osip_free，而不是直接调用C中的malloc和free。osip_malloc和osip_free函数只是对malloc和free的简单封装。这样我们创建内存池策略时，只需修改osip_malloc和osip_free函数即可，可以非常方面应用。

3线程池

目的：增加服务器的响应时间，增大服务器的吞吐量，减少线程创建销毁和切换的时间损失。

线程池的概要设计

基于线程池的设计，目前比较流行的有两种1：生产者/消费者策略2：Loader/Follower策略，基于服务器特性考虑（需要并发处理大量数据）以及参考一些成功例子，决定采用2策略：L/F策略的主要方式时，程序启动时创建一组线程，并通过一组策略来管理，其中一个线程为loader线程,此线程处于活动状态，当有信息到来时有loader线程处理，如果此时有来一个信息，线程池中一个被挂起的线程，被唤醒，来处理这个数据，处理完成后，如果还有活动线程就挂起，否则此线程讲作为loader线程，等待数据的到来，更详细的设计，参考同目录下的lf.pdf文档

适用性：partysip采用为每个插件创建线程的方式，如果增加线程池，必须在数据到来的端口出，虽然有多个线程处理数据，但是由于每个插件只有一个线程，所以在具体处理数据时也必须等待插件线程处理完毕后，再次调用，所以如果快速实现，也需要把每插件有单一线程修改为每插件线程池策略，修改这两部分，几乎是partysip底层流程的修改。虽然增加线程池策略是服务器提速的最好方法，但是考虑其修改的复杂性，需要仔细partysip框架以及sip协议，分析后修改。

4基于系统的优化

说明：系统的优化，主要针对操作系统所提供的高级I/O访问功能的优化，比如windows

下的完成端口，linux下的epoll，比使用简单的socket机制，要快很多。普通的绑定端口，监听机制，并发总数只有几百个，而采用完成端口或epoll后，处理并发的数量在几万个左右，参考msdn上的完成端口性能测试。

简单实现：

由于基于系统的优化是与操作系统息息相关的，不同操作系统下，具体实现方式不同，所以，为了有更好的适用性，需要提供windows下和linux下两种机制。

适用性：根据目前掌握的资料来看，由socket机制转换为linux下的epoll和windows下完成端口，并不是很难，本质上讲完成端口或者epoll都是在socket绑定端口的基础增加了线程池（lp策略），可以方便异步调用。因为修改涉及到partysip底层逻辑的修改，所以需要仔细分析partysip框架以及sip协议。

我知道从整体上来说，提高系统得并发数是一项非常系统的优化工作，涉及到硬件选择，操作系统的支持，辅助工具的优化，软件的设计等多方面工作。因此在具体过程中，并不是简单的通过更新硬件，更换操作系统，优化辅助工具，更改部分软件设计就可以解决。需要系统级别的架构和设计，在具体操作过程中，只修改一部分，并不会马上看到优化结果，需要一个长期的测试过程。所以，基于这些考虑，服务器端的设计必须建立一个良好的设计框架之上，以及具有足够的优化余地。

在这里希望各位做过基于partysip服务器的朋友，多多提建议，并且谈谈你们服务器在具体设计过程中碰到的问题，以及是如何解决。同时希望做过服务器的朋友，多多给我提到的优化方案提建议，谈谈你们做服务器时的一些心得，并且在不影响商业版权的情况，仅可能的多告知一些技术，非常感谢大家。同时也希望本文能够对正在做partysip或者在项目中打算使用partysip的朋友提供借鉴的作用。

参考资料：

在即时通信软件中，如何提高服务器支持的最大连接数
（http://www.linuxforum.net/forum/gshowthreaded.php?Cat=&Board=program&Number=529852&page=1&view=expanded&sb=5&o=all）

Writing Windows NT Server Applications in MFC Using I/O Completion Ports

（http://msdn2.microsoft.com/en-us/library/ms810436.aspx）

Win32 Multithreading Performance

（http://msdn2.microsoft.com/en-us/library/ms810437.aspx）

网络的基础架构: ACE

www.chinaunix.net上的大量文章

《UNIX网络编程》I卷

Linux下通用线程池的构建（http://blog.csdn.net/tingya/archive/2004/12/23/226614.aspx）

微软msn服务器设计思想初步理解

（http://blog.csdn.net/fangzhengzhu/archive/2005/01/21/262886.aspx）