信令处理中IE机制的讨论.doc

IE机制的讨论 目前的IE机制 目前IE的操作比较简单, IE Buffer采用连续的空间, 需要事先分配, 大小固定. 提供的主要操作是Add和Find. 主要优点: 机制简单, 出错机率小, 效率比较高, 控制比较灵活. 主要缺点: 容量不能动态改变, 操作前需要事先估算空间大小, Add操作目前没有保护. 出现的问题 在小批量(3CPS, 5CPS)的性能测试中, 当CSCF呼叫实例达到600左右时, 马上出现Heap内存分配失败, 呼叫无法继续(目前配置CSCF Heap内存为95M, 实际可动态分配大小73M), 而600个实例中有300个是P-CSCF订阅的实例, 同时由于P/I/S-CSCF在一个板上, 实际同时进行的呼叫也就是100个多一点, 系统性能十分低下. 原因分析: IE机制问题: 由于IE Buffer不能动态改变, 在发送消息前需要分配所有可能的空间; CSCF和LEG之间的消息处理机制问题: LEG在收到USIP消息后, 分配足够大的空间(目前309600), 将SIP消息组成IE形式发给CSCF, CSCF再对该Buffer直接进行操作, 如增删, 移动等. CSCF在通过LEG发送任何响应消息(包括NXX, BYE, CANCEL等)时, 都需要分配一个足够大(目前309600)的IE Buffer, 构造成LEG需要的形式发送到LEG层. 导致一个呼叫可能同时占住几个300k的空间. 而事实上, 根据Abel的测试, 在以上的case下, 309600空间的实际利用情况如下: ###### SND_MSG_LEN_STAT [begin] ###### gStatOnSndMsgLen[ 0]= 7422, occupy: 12% gStatOnSndMsgLen[ 1]= 1290, occupy: 2% gStatOnSndMsgLen[ 2]= 7148, occupy: 11% gStatOnSndMsgLen[ 3]= 1946, occupy: 3% gStatOnSndMsgLen[ 4]= 3246, occupy: 5% gStatOnSndMsgLen[ 5]= 6839, occupy: 11% gStatOnSndMsgLen[ 6]= 3572, occupy: 5% gStatOnSndMsgLen[ 7]= 5207, occupy: 8% gStatOnSndMsgLen[ 8]= 2916, occupy: 4% gStatOnSndMsgLen[ 9]= 1296, occupy: 2% gStatOnSndMsgLen[10]= 2588, occupy: 4% gStatOnSndMsgLen[11]= 971, occupy: 1% gStatOnSndMsgLen[12]= 971, occupy: 1% gStatOnSndMsgLen[13]= 1617, occupy: 2% gStatOnSndMsgLen[14]= 1617, occupy: 2% gStatOnSndMsgLen[15]= 2262, occupy: 3% gStatOnSndMsgLen[16]= 2911, occupy: 4% gStatOnSndMsgLen[17]= 1621, occupy: 2% gStatOnSndMsgLen[18]= 1296, occupy: 2% gStatOnSndMsgLen[19]= 1298, occupy: 2% gStatOnSndMsgLen[20]= 1296, occupy: 2% gStatOnSndMsgLen[21]= 974, occupy: 1% gStatOnSndMsgLen[22]= 0, occupy: 0% gStatOnSndMsgLen[23]= 325, occupy: 0% gStatOnSndMsgLen[24]= 0, occupy: 0% gStatOnSndMsgLen[25]= 0, occupy: 0% gStatOnSndMsgLen[26]= 0, occupy: 0% gStatOnSndMsgLen[27]= 0, occupy: 0% gStatOnSndMsgLen[28]= 0, occupy: 0% gStatOnSndMsgLen[29]= 0, occupy: 0% gStatOnSndMsgLen[30]=