|
在Linux操作系统上使用Dialogic Netstructure DM/V和DM/V-A系列板卡建立高密度系统,
和优化性能
■ 概 述
在今天的经济环境中, 快速建立高密度,可扩展和可靠的通信平台并把它们推广到市场对于OEM, 集成商, 和独立软件开发商来说是至关重要的,
这可以为这些厂商提供竞争力和持久的成功.
随着增值服务需求的增长, 大的企业和服务提供商不断地打破系统密度的界限. 对于客户需求的低价格,高密度媒体服务器,
并满足关键密度和性能, Dialogic测试了1200端口媒体服务器方案,并对超高密度的系统作了系统软件的优化. 因此,客户现在可以放心地建造各种各样的复杂的应用例如呼叫中心,
会议和交换应用.
这个参考设计指南会描述媒体服务器测试环境, 使用了什么建筑模块, 并提供性能测试结果. 这些可以揭示了创建高密度系统的性能指标,
如何达到这个性能指标, 使用Dialogic Netstructure DM/V和DM/V-A系列板卡和Linux操作系统还有为电信级关键应用创建的媒体服务器软件.
■ 简 介
在目前市场环境下, dot-com泡沫破裂后和激烈的基本服务的竞争, 使运营商的销售额下降, 网络资源得不到有效利用还有设备投资也同样下降.
他们迫切希望寻找新的销售额来源, 而且是投资不高的. 同时, 大中型企业也在寻找改进客户满意度, 留住客户和增加员工效率的方法,
同减少运营和架构投资.
因此, 企业和运营商都在寻找创新的增值服务, 也希望建立在开放的,基于标准的建筑模块. 还有, 两种客户都需要灵活的,
很快集成的, 投资不高的, 但能提供很强的投资回报的方案. 为了满足这些需要而且达到商业增长需要的密度要求, 通信网络和方案必须保证可扩展性而且不会让系统的性能受到影响.
媒体服务器是实施这些增值服务的平台. 而且, 侧重于控制成本, 今天的重点是高密度,可扩展,需要空间不大的媒体服务器.
Dialogic 提供开放的基于标准的建筑模块, 可以用来开发和实施高性价比, 高密度的媒体服务器. Dialogic NetStructure™
DM/V 语音和 DM/V-A 多功能系列卡支持语音处理, 语音识别, 会议, 都只在一块PCI或CPCI插槽中.
一台计算机中可以插多块这个系列的板卡, 减少了需要的可扩展的高密度方案的硬件空间.
Linux 操作系统提供电信级的功能, 对于运营商和大企业环境来说是关键的 - 高效的资源管理, 灵活的功能增强,
可扩展到高密度而性能不会下降.
为了减少客户推向市场的时间, Dialogic在下面环境开发和测试了1200端口媒体服务器系统: DM/V语音卡和DM/V-A多功能卡,
RedHat* 7.2 Linux , Linux版 Dialogic® Dialogic® 系统软件 5.1.
通过严格的测试和分析, 关注在超高密度方案的可扩展性和性能上, Dialogic工程师成功地建立了最优的板卡参数, 客户可以有信心地在单一系统中密度达到更高的密度.
这个1200端口媒体服务器参考手册就是记录了他们实现和性能测试的步骤.
高密度媒体服务器的应用有
- 统一消息 - 把语音,传真和通常的文本消息作为对象来处理, 在统一的一个信箱中, 用户可以使用电子邮件或者电话来访问.
如果一个用户的计算机有多媒体功能, 用户可以打开和播放语音消息. 传真的图像可以被保存或者打印. 一个用户可以通过电话访问同一个油箱,里面的电子邮件文本可以被转换成语音文件放给用户听.
- 网络呼叫中心/联络中心 - 一个集中的地方, 客户和其他电话被一个组织来处理, 通常有部分呼叫被计算机自动处理.
呼叫中心可以在任何组织里需要使用电话产生销售或提供服务里实施.
- 自动语音回复(IVR) - 这是一个软件应用, 它接收电话语音的输入和按键选择并提供相应的回复,
可以是语音, 传真, 回呼, EMAIL和其它媒体. IVR通常是一个大应用程序中的一部分.
- 语音门户 - 一个网站或者其它服务, 用户可以通过电话来访问信息, 例如天气, 体育成绩, 或者股票价格.
可以使用自然语言或按键来发出请求, 语音门户使用文本转语音(TTS)技术播放语音或者通过Email形式回复.
- 会议 - 使多方可以加入一个电话谈话中
- 预付费/预付费卡 - 一个客户为了打电话事先购买了一定量的呼叫时间或者一定的金额话费, 随着打电话卡的价值也随之减少.
计费一般都是在一个远程的交换机, 用户拨入来进行呼叫.
- 语音邮件 - 让用户可以接收,编辑和转发消息到一个或多个语音信箱
- 国际回呼 - 是一个系统为了避免电话公司的长途话费, 让美国境内产生一个呼叫然后把原始呼叫者加入到会议中
- 网关交换 - 一个网关是一个网络节点, 作为到另一个网络的入口. 一个网关经常与路由器和交换机联系起来,
路由器知道把到达网关的特定的数据包转到相应的地方, 交换机提供提供一个包进出网关的实际路径.
■ 高密度(1200端口)媒体网关
Dialogic创建, 测试和优化一个1200端口媒体服务器参考系统主要关注的是可扩展性和性能. Dialogic如何增加更多的端口而不会影响客户期望和要求的高性能呢?
系统必须要可扩展, 客户需要从一个T-1或E-1线到40个而不会引起性能的降级.
最新的性能结果是一个系统中插了10块Dialogic NetStructure™ DM/V 语音系列板卡 (1200
通道), 执行同时的放音／录音功能, CPU利用率为 35-38% , 密度升高也不会引起性能下降. CPU使用率和通道数是一个线性比率,说明这个架构有良好的扩展性.
■ 方 法
再配置1200端口媒体服务器架构时, Dialogic工程师选择了Dialogic建筑模块和第三方模块, 组合起来可以达到较高的性能和较低的CPU使用率.
这个服务器配置了10块Dialogic NetStructure DM/V 语音系列板卡 (DMV1200-4E1-PCI
/ DM/V1200-4E1-CPCI), 提供网络连接和语音处理, 它们支持4个网络接口和120端口的语音处理能力.
类似的测试也在10块DM/V-A多功能系列板卡上作过, 它有4个数字网络接口和增强型媒体能力, 还支持连续语音处理(CSP).
了解更多功能请参阅在线文档: .
这些板卡被装在一个机箱里, 配置了 Dialogic® Pentium® III 处理器, 1000
MHz CPU, 运行 RedHat 7.2 Linux 操作系统. 使用Linux和 Linux版Dialogic Dialogic
系统软件 5.1让开发者拥有高可用性, 高性能, 满足电信级, 运营商和大企业应用方案.
这个媒体服务器测试了可扩展性和性能. Dialogic工程师开发了一个简单的消息应用, 然后在1200通道的系统上进行了测试,
每个通道只能连续的放音和录音操作. 系统软件包括库和固件也进行了优化; 每一方面都达到极限来确定系统的灵活性, 某种资源在什么密度下是极限.
一旦发现, 立即作系统优化, 这个过程不断在进行, 直到达到合适的密度要求而且不会有性能的下降.
不同的编程模式也进行了测试. 同步和异步, 单线程和多线程 - 工程师测试了不同的情况来判断如何达到最优的性能.
基于1200通道, Dialogic工程师测试了每个线程不同的通道数(例如每个线程120端口和240端口). 测试结果表明,
在1200端口的配置中, 每个线程120个端口是最高效的.
异步单线程是推荐使用的编程模式, 它可以比扩展异步模式达到更低的CPU使用率; 而且系统显示了很好的扩展性, PCU使用率和端口数是一个线形关系.
创建1200端口媒体服务器的方法被记录下来, 开发者可以在写自己程序的时候进行参考:
- 放音／录音终止
- 编程模式
- 使用连接地/索引放音而不是调用多个dx_play()命令
- 调用dx_stopch( )
- 优化设备的性能
- 设备初始化
这些参考建议都在本手册的 部分.
■ 开发环境
为了创建一个可以超过过去系统瓶颈密度要求, Dialogic工程师选择了Dialogic产品和第三方产品, 集成起来可以达到电信级媒体服务器的高可用性和高性能.
Linux (RedHat 7.2) 操作系统
这个1200端口的媒体服务器是建立在 RedHat 7.2 Linux 操作系统上, 使用 Dialogic Dialogic
SR 5.1 软件 Linux版, 它支持高密度高可用性的通信平台. 这个模块化的架构支持快速的开发周期, 提供定义良好的,
标准的接口, 保证了硬件的兼容. 不只是密度大大地增加了, 也达到了更好的系统性能. 这个系统的高密度和高性能让复杂的消息,呼叫中心,
会议和交换应用成为可能.
Dialogic® NetStructure® 语音和多功能系列板卡
DM/V 和 DM/V-A 办卡系列是建立在强大的DM3架构上 - 一个灵活的,模块化的和开放的架构平台, 用来开发先进的呼叫处理应用,
满足媒体服务器的高密度和高性能要求. 开发者在一个机箱中可以开发的系统密度从48到1200端口的T-1/E-1 网络连接,
还有办卡上的语音, 讲话和会议媒体的功能.
DM/V-A 办卡系列提供了创新性的连续语音处理技术, 它是一个基于DSP的信号处理方案, 可以与业界领先的语音识别软件无缝连接提供友好的用户界面.
板卡上的会议功能一共了业界最强大的功能集, 给最终用户提供了非常愉快的会议的体验. 高级的算法可以防止会议中的噪音和回声.
它也可以平衡参与者的语音音量, 提供DTMF检测限制进入退出会议的音频. 板卡上的会议可以让Dialogic的客户实施电信级的会议系统,
提供丰富的功能, 良好的语音质量和密度, 费用比私有的系统降低很多.
高密度媒体服务器测试环境
- 硬件: Dialogic Pentium III 处理器, 1000 MHz CPU
- 操作系统: RedHat Linux 7.2
- 开发软件: Dialogic Dialogic SR 5.1 Linux版
- 机箱: Transduction Berta 1000
- 内存: 512 MB SDRAM PC133
- 硬盘: Seagate ST330620A-30GB IDE (7200 rpm, 8.5ms Seek Time)
- 通信电话板卡: 10块 Dialogic NetStructure DM/V 或 DM/V-A 系列板卡: DM/V1200A-4E1-PCI
或 DM/V1200-4E1-CPCI. 尽管这个文档中的结果都是基于E-1板卡来做的测试, 对于T-1板卡来说编程指南和结果也是一样的.
DM/V 语音系列板卡
DM/V-A 多功能系列板卡
包含所有的DM/V板卡的功能,还有:
- 支持连续语音处理
- 提供板卡上的高密度会议方案, 可以用来实施电信级会议系统.
- 支持 G.726, GSM, 和 TrueSpeech* 语音编码
软 件
Linux版系统软件 5.1 提供了很多的媒体资源 (声音, 传真, 语音和会议) 和数字网络接口, 在Redhat
7.2 Linux操作系统和Dialogic DM3板卡上. 而且, Linux SR 6.0 的方案使用 CompactPCI*
总线支持热插拔(PHS), SNMP, 检测, 单板启动和停止操作, 固件跟踪, 更快的系统下载和初始化时间.
本文档剩下部分详细介绍了1200端口媒体服务器的性能指南, 测试环境和性能结果. 客户希望了解创建1200端口媒体服务器的更多信息请与Dialogic技术销售代表或客户经理联系.
■ 高密度系统性能指南
当为包含DM/V语音卡和DM/V-A多功能卡进行编程的时候, Dialogic建议采用下面方法来使系统的性能最大化.
这些方法包括:
- 放音/录音终止
- 编程模式
- 使用连接/索引放音而不是调用多个 dx_play() 命令
- 调用 dx_stopch( )
- 优化设备的性能
- 设备初始化
放音／录音终止
终止事件
在DV_TPT结构中使用DX_DIGMASK作为终止条件, 而不是调用DX_CST结构然后用dx_stopch()来终止通道上的I/O操作.
DV_TPT结构定义了终止的条件.
最长时间
在DV_TPT结构中使用DX_MAXTIME最长函数时间参数, 而不是通过DX_IOTT结构中的io_length的长度来终止.
DV_TPT结构定义了录音终止条件.
最长函数时间就是录音／放音的时间.
编程模式
为了使性能最大化, 使用异步单线程编程模式和sr_waitevt() 函数
下面介绍了关于编程模式的信息:
使用异步单线程模式
对于这种系统来说, 异步单线程编程模式是推荐的. 应用程序要正确取出和处理事件. 例如, 应用程序可能会与数据库交互,
它可能需要把事件交给另一个线程来处理以免数据库操作会阻塞取事件的县城. 这种方法可以让你实现事件处理的方案来达到更高的性能.
注意: 不支持信号编程模式
线程数
根据应用程序的不同, 最佳的线程和通道数的组合也不同. 如上面所说, 我们建议一个线程来处理DM3的事件. 有可能需要调整编程模式来达到更好的性能.
例如, 让单独的线程专门做系统的I/O操作可能会提高系统性能. 而且, 如果应用程序使用了从内存录音／放音功能, 增加上面一个专门的线程也许不会改进整体系统的性能.
总之, 对于Linux系统, 我们的结果表明如果没有大量的硬盘操作, 越少的线程数系统的性能越好. 但是,这只是一个笼统的推荐.
你需要根据你的应用的特点来调整编程模式来达到最佳的结果.
进程数
这里有两点考虑:
1. 根据你的服务的可用性需求来决定你系统的进程数 因为进程是单独运行的. 如果一个进程遇到错误或者停止服务了,
其它的还是可用的. 如果, 你用一个进程来处理所有的资源, 那么如果这个进程停止了服务, 整个系统都不可用了.
2. 多个进程会增加系统的负担从而降低整体系统的性能. 总之, 你要避免一个系统中的大量的进程. 操作系统处理多个进程的负荷会影响到系统的性能.
因此, 你需要根据服务的可用性和整体系统的性能来寻找一个平衡点. 建议你使用多种不同的组合来判断哪种模式是最佳的.
注意: 一个设备不能被多个进程访问.
减少磁盘 I/O 操作
减少磁盘I/O操作(例如从内存中放音和录音)可以是高密度系统的性能最大化. Dialogic提供个API可以让放音/录音对内存而不是对磁盘文件操作.
Dialogic 建议应用程序管理磁盘I/O来减少磁盘I/O的操作来达到系统的高性能.
使用连接/索引放音而不是调用多个dx_play()命令
不要使用多个Play命令, 而是要使用DX_IOTT机构中来定义从内存或磁盘的数据传输. DX_IOTT是一个结构连接,
可以制定从某个文件或某个文件的一部分(使用lseek() 来设定偏移量) 以一个序列进行放音. 这会减少调用 dx_play()
的数目. 这也被称作连续放音或索引放音. 同样对于录音来说道理也是一样.
调用 dx_stopch( )
对了达到高性能, 要异步调用 dx_stopch( ) 而不是同步模式. 异步调用这个函数就不会让线程阻塞等待它的终止,
在这个通道终止的过程中, 程序可以继续处理其它设备和事件. 对于要达到最佳性能的应用程序, 要使用异步编程技巧.
优化设备的性能
如果你打开和关闭设备或者你的应用程序使用GlobalCall来自动打开关闭设备, 应用程序的性能可能会受到影响.
为了优化性能, 我们建议你在应用程序初始化时打开所有的DM3设备, 然后保持它们打开状态直到系统终止. 所有设备都应该在空闲状态被关闭,
所有设备应该在应用程序终止的时候关闭.
设备初始化
设备初始化的方法可以参见手册 Compatibility Guide for the Dialogic Dialogic
R4 API on DM3 Products for Linux
xx_open( ) 函数包括声音 (dx), Global Call (gc), 网络 (dt), 和传真 (fx)
API, 它们在DM3上是异步函数, 和标准R4的同步不同. 这对于应用程序来说不会有影响, 只有在当设备在初始化时对这个设备的下一个函数调用开始了.
在这种情况下, 初始化必须要结束以后后面的函数才能开始. 那个函数可能不会返回错误, 但是它会阻塞在那里直到设备初始化完成.
例如, 你的应用程序调用了下面两个函数:
dx_open() dx_getfeaturelist()
dx_getfeaturelist( ) 被阻塞, 直到设备的初始化完全完成, 即使dx_open( ) 已经返回成功.
换句话说, 初始化dx_open( ) 可能看起来已经完成, 但是实际上它还在继续进行. 在某些应用中, 这可能会引起设备初始化性能下降.
幸运的是, 你可以通过重新配置打开和配置设备的序列来避免这种问题的发生. 推荐的方法是调用别的函数前, 首先调用所有的
xx_open( ) 函数打开所有通道. 例如,你可以用一个循环轮询所有的设备调用所有的xx_open( ) 函数,
然后开第二个循环来配置它们, 这样就可以避免你调用一个xx_open( ) 函数以后,马上在相同设备上调用其它API函数.
使用这种方法, 当所有 xx_open( ) 命令结束的事后, 第一个通道就已经初始化完毕,你就不会遇到任何问题.
这种改变不是对于所有应用都是需要的, 但是如果你遇到了很差的初始化性能, 你可以使用这种方法来进行改进.
■ 高密度媒体服务器测试环境
下面描述了Dialogic如何建立媒体服务器来完成性能测试.
硬件和软件
这部分主要描述了在测试高密度媒体服务器中使用了什么. 这里介绍了PCI总线的
PCI 总线
硬件: Dialogic Pentium III processor, 1000 MHz CPU
操作系统: Red Hat* 7.2 Linux
开发软件: Dialogic Dialogic SR 5.1 for Linux
机箱: Transduction Berta 1000
内存: 512 MB SDRAM PC133
硬盘: Seagate ST330620A-30GB IDE (7200 rpm, 8.5ms Seek Time)
板卡: 10个 Dialogic NetStructure DM/V 语音和 DM/V-A 多功能系列板卡: DM/V1200A-4E1-PCI
或 DM/V1200-4E1-CPCI. 尽管这个文档测试的系统是E-1板卡的, 相同的编程方法和结果对于T-1板卡来说也是适用的.
■ 性能结果
呼叫控制
录音和放音
系统可扩展性: 放音CPU使用率
系统可扩展性: 录音CPU使用率
1200通道使用扩展异步模式放音时CPU使用率
1200通道使用扩展异步模式录音时CPU使用率
这部分主要介绍了测试的程序和性能指标. 性能测试程序是根据"VI.高密度媒体服务器测试环境"
部分来搭建的, 应用程序包括:
呼叫控制
呼叫控制应用设计为要达到最高的呼叫控制完成率. 呼叫控制完成率被定义为在一个E-1上一个小时之内完成的呼叫数(没有呼叫间的延迟和呼叫内的延迟).
设计考虑
这个应用程序设计时主要有以下考虑:
- 减少磁盘 I/O: 所有的录音和放音都是通过内存
- 这个应用程序基于 R4 API
- 这个应用程序用扩展异步模式写的
- 录音和放音前没有呼叫建立
呼叫控制序列
在这个呼叫控制应用中, 系统只能下面操作:
1. 双方都打开通道
2. 接收方等待呼叫
3. 发起方发出一个呼叫
4. 呼叫被建立
5. 接收方检测到呼叫建立然后马上挂断呼叫
6. 发起方接收到挂机信号也进行挂机
1200端口呼叫控制结果
呼叫控制完成率测试结果为: 2,116,800 呼叫每小时每个E-1板卡(120通道). 或者说它用了0.2秒的时间在任意一个通道上完成一个呼叫.
这个数据通过接收方五块卡和发送方五块卡测试得出, 它们就是在那个插十块卡的机箱里面用对接电缆来连接.
放音和录音
放音和录音是每一个媒体服务器的基本功能. 对于一个媒体服务器来说高性能是非常关键的. 这个例子程序演示了在测试系统上所有通道同时进行录音和放音操作.
CPU 使用率和系统可扩展性得到考量. 使用了两种不同的消息处理模型. 第一是异步单线程模式, 使用sr_waitEvt()
第二是使用扩展异步模式, 使用sr_waitEvtEx(). 结果表明在高密度系统中这两种模式有很大的不同.
现在的 sr_waitEvtEx() 实现是使用一个线形的查找来把事件来匹配sr_waitevtEx()里面定义的每一个设备句柄.
使用 sr_waitEvt()就不会有这种负担, SRL只是把事件返回给你,. 应用程序可以自己实现时间匹配机制.
我们使用的是STL的map类, 这可以有比线形查找更好的性能, 也就会有更好的结果.
这部分提供了使用正确的线程和通道数组合的测试结果, 使用的是扩展异步编程模式sr_waitEvtEx().
对于异步单线程模式(我们推荐), 显示对于一个系统中10块板卡来说, 放音和录音使用了24%到27%的CPU时间,
扩展异步模式使用了36%到28%. 系统显示了很高的扩展性, CPU使用率和通道数成线形增长.
下面部分和图介绍了按照"VI高密度媒体服务器测试环境"来创建的性能指标.
系统可扩展性: 放音CPU使用率
图 1 显示了推荐的异步模式使用 sr_waitevt() 和扩展异步模式使用 sr_waitEvtEX().
你可以看到, 推荐的编程模式有更好的结果.
系统可以很好的扩展. CPU使用率和系统中的端口数成线形比例. 图 1 显示了应用程序运行1, 2, 4, 6,
8, 10块板卡时的CPU使用率.
系统可扩展性: 录音CPU使用率
图 2 显示了推荐的异步模式使用 sr_waitevt() 和扩展异步模式使用 sr_waitEvtEX().
你可以看到, 推荐的编程模式有更好的结果.
系统可以很好的扩展. CPU使用率和系统中的端口数成线形比例. 图 1 显示了应用程序运行1, 2, 4, 6, 8,
10块板卡时的CPU使用率.
1200通道放音CPU使用率,使用扩展异步模式
图 3 显示了运行的线程数和不同的CPU使用率. 当有多个一个线程运行的时候, 每个线程处理一定的负荷. 例如,
如果有两个线程运行, 每个处理600个同时的放音.
1200通道录音CPU使用率, 使用扩展异步模式
图 4 显示了运行的线程数和不同的CPU使用率. 当有多个一个线程运行的时候, 每个线程处理一定的负荷. 例如,
如果有两个线程运行, 每个处理600个同时的录音.
[
本文英文版 ]
|
