partysip框架优化计划

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介:

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 41.6GHZ,网卡:1000M双网卡

操作系统:windows2003+sp1

测试环境:注册服务器,mysql服务器同时运行。

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

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

1:增加buffercache

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

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

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

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

2:内存池策略

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

       内存池策略的概要设计

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

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

3线程池

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

       线程池的概要设计

       基于线程池的设计,目前比较流行的有两种1:生产者/消费者策略2Loader/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下的epollwindows下完成端口,并不是很难,本质上讲完成端口或者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

高性能服务器软件开发
The C10K problem

http://www.kegel.com/c10k.html

MMORPG游戏服务器端的设计

http://blog.csdn.net/yahle/archive/2005/01/12/250034.aspx

线程池的介绍及简单实现

http://blog.csdn.net/IOKE/archive/2004/10/25/150874.aspx

部分参考资料,参考同目录下的pdf文件

用完成端口开发大响应规模的Winsock应用程序(1)(2)(3)(4)(5

http://dev.csdn.net/develop/article/15/15211.shtm
Write Scalable Winsock Apps Using Completion Ports

http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/Winsock.asp

Improving Runtime Performance with the Smooth Working Set Tool

http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/

UDP并发服务器设计讨论一:一台主机、一个CPU,实现单位时间内最大并发数

http://www.linuxforum.net/forum/showflat.php?Cat=&Board=program&Number=599334&page=4&view=expanded&sb=9&o=all&fpart=all&vc=1

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
1月前
|
NoSQL 算法 Java
后端接口性能优化分析-程序结构优化(中)
后端接口性能优化分析-程序结构优化
30 0
|
1月前
|
NoSQL Java Redis
后端接口性能优化分析-程序结构优化(上)
后端接口性能优化分析-程序结构优化
114 0
|
1月前
|
缓存 Java 应用服务中间件
后端接口性能优化分析-程序结构优化(下)
后端接口性能优化分析-程序结构优化
44 0
|
7月前
|
移动开发 前端开发 JavaScript
前端工程化的前端性能的性能优化方案的渲染层面优化之DOM优化
DOM 优化是一种非常重要的前端性能优化方案,因为它可以在不同的环境中提高网页的响应速度和可接受性。
63 0
|
8月前
|
分布式计算 关系型数据库 BI
KYLIN 建模设计学习总结(概念、空间优化、查询性能优化)
KYLIN 建模设计学习总结(概念、空间优化、查询性能优化)
88 0
|
9月前
|
SQL 缓存 NoSQL
记一次接口性能优化实践总结:优化接口性能的八个建议
最近对外接口偶现504超时问题,原因是代码执行时间过长,超过nginx配置的15秒,然后真枪实弹搞了一次接口性能优化。在这里结合优化过程,总结了接口优化的八个要点,希望对大家有帮助呀~
|
9月前
|
数据采集 算法 数据可视化
MMdetection框架速成系列 第03部分:简述整体构建细节与模块+训练测试模块流程剖析+深入解析代码模块与核心实现
按照抽象到具体方式,从多个层次进行训练和测试流程深入解析,从最抽象层讲起,到最后核心代码实现,希望帮助大家更容易理解 MMDetection 开源框架整体构建细节
449 0
|
9月前
|
SQL 监控 NoSQL
技术组件优化分析:原理、方法与实战分享
对一个固定的技术组件的分析优化思路,即组件不是我们开发的,但又要分析优化它,怎么办? 当数据库的CPU并没有全部用完,而是只用了几颗的时候,如何具体定向?将用到查看数据库本身线程栈的方法,这和前面直接看trx表有所不同。
88 0
|
JSON 前端开发 JavaScript
优化封装方案分析| 学习笔记
快速学习优化封装方案分析。
61 0
|
XML JSON 前端开发
优化封装方案实现| 学习笔记
快速学习优化封装方案实现。
73 0
优化封装方案实现| 学习笔记