论文部分内容阅读
性能是数字电视运营前端实时播出系统至关重要的因素之一。对于计算机本身,合理的软、硬件的配置可以使系统的使用达到最佳。
一、代码优化
对于一套系统,使用不同的变量,函数和逻辑虽然最终都可以达到目的,但程序可读性、易维护性、复杂性可能完全不同,效率可能截然不同。
在MSCAS中有一个实际需求就是通过三个数字合起来定位一个元素。也就是说以DWORD1+DWORD2+DWORD3作为Key,去获取一个Value。MFC和STL都没有通过多个键查找一个元素的类,所以采用变通的办法,即首先将3个DWORD类型键转换成一个字符串型键:“DWORD1_DWORD2_DWORD3”这时问题就变成了通过一个字符串型key值查找一个元素了。MFC有基于CMap类的CMapStringToPtr类,而STL中有::std::map,在经过大量的效率测试后发现后者比前者具有很高的效率。
鉴于MSCAS程序多处使用了CMap,为了保持代码的兼容性,将改进后的代码按照CMap的方式将::std::map进行了封装,这样可以保证代码的最小改动性以适应其他开发人员的开发习惯。
二、数据库优化与实现
2.1MSCAS数据库瓶颈分析
CAS数据库是整个系统的数据中心,它的性能直接影响着整个系统的性能,根据分析,其特点是:
·数据表结构简单,但数据量大。
·数据库类型属于OLTP和OLAP混合模式。
![](https://www.soolun.com/img/pic.php?url=http://img.resource.qikan.cn/qkimages/zgxt/zgxt201307/zgxt20130719-1-l.jpg)
针对上述特点,数据库在设计的时候应该充分考虑到数据压力对数据库性能的影响,使用Oracle提供的分区表选件对大表进行拆分;使用存储过程封装绝大多数数据库操作以及使用合理的备份、迁移、数据生成方式提高整体系统的效率。
优化前的MSCAS,在用户数量到达10000以后,整体性能明显下降。主要原因在于:
CAS数据库的表没有建立合适的索引,致使在数据库数据量增加以后,过多的全表扫描大大增加了Oracle数据库的磁盘读写I/O压力和内存访问压力。数据库配置不合理,分配内存过少引起数据库中不必要的磁盘页面交换和内存调整。
为了提升整个CAS系统的效率,调优方法如下:
通过对数据库的表结构和索引重新进行合理设计,减少不必要的高负荷数据库操作;对Oracle数据库进行运行时刻调优,让Oracle在不同数据量压力下都能运行在最佳状态。
2.2分区表和分区索引的使用
在分区表上建立三种索引模式:全局分区索引、全局不分区索引和本地分区索引。在CAS数据库中,对于查询效率比较高的索引采用全局分区索引,同时对更新频率相对比较高的字段建立本地分区索引。
2.3索引的使用
索引(Index)是常见的数据库对象,它的设置好坏、使用是否得当,直接影响着数据库应用程序和数据库的性能。通过建立B-TREE索引、复合索引和普通索引以及位图索引相,系统速度大大提高,同时数据库压力也减小不少。
2.4测试和验证
通过对100万用户量级批量授权速度进行测试,结果表明在大用户量的情况下,一次进行190条记录的批量设置,速度仍然可以达到1分钟以内,完全可以满足商用目的。
三、数据包的收发优化策略与实现
授权信息、OSD,E-mail等信息都要求用户能即时收到的信息都是通过EMM包来传送的。因此,如何设计一种高效的发送接收策略能让用户即时的收到EMM包是条件接收系统性能优化中的最重要部分。
3.1EMM包概述
EMM包是数字电视前端向终端发送的主要信息。EMM包的收发原理是所有数据在一个大的队列中循环发送。在终端,当用户将智能卡插入机顶盒后,机顶盒将根据此智能卡的卡号来过滤流中属于此智能卡的EMM数据。EMM包发送优化的目的就是使前端新产生的数据包在终端能在最短的时间内接收处理。
3.2终端的接收机制和策略
数字电视信息终端由机顶盒、智能卡和电视机组成。机顶盒接收所有前端传来的信号,其中与CAS模块有关的EMM包和ECM包需要送入智能卡解密。最终通过ECM包得到明文的CW后,机顶盒解扰芯片将加扰的节目流解开后就可以在电视机上正常的播放。
机顶盒的工作原理如图1所示:
对于EMM包的接收,机顶盒有一个过滤器,可以通过设置特定的过滤条件来接收需要的包。通过设置过滤器,机顶盒就可以收到制定卡号的包,当过滤到一个需要的包后,会有一定的判断、解析和处理时间。因此同一张卡的两个数据包需要有一定的间隔。
3.3前端的发送机制、策略和实现
前端的发送机制首先是建立在终端接收机制基础上,只有分析研究出一个准确的业务模型,才能建立好的发送策略。
以授权包的发送为例,一个新的业务交易流程如下:用户交费→SMS调用CAS发送授权→CAS生成EMM包通过复用器发送→终端接收到EMM包→解密节目,用户可以收看节目。
大部分情况下,新业务是由用户引起的,因此前端在发送数据的时候终端机顶盒处于开状态,智能卡插在机顶盒中等待接收数据,称为第一类用户,(约占90%)。发送授权数据的当时,终端机顶盒并没有处在准备好的状态,用户可能在晚上才看电视,称为第二类用户(约占8%)。对于自动扣款的用户,有可能出差等缘故几天都不看电视,称为第三类用户(约占2%)。
根据上述分布,为了保证对于用户响应的及时性,提出优先级不同的三个逻辑上的队列:即时队列、优化队列和惰性队列。所有的数据包最后通过复用器向终端发送的时候都是一个一个串行发送的,通过点名控制模块解决如何查找“下一个”的问题。不同的是三个队列包含的数据包不同,发送的频率不同。
三个队列优先级由高到低排列如下:即时队列>优化队列>惰性队列。
3.4测试和验证
在数据包的发送策略没有优化之前,用户接收到的数据最大时间依赖于惰性队列发送一轮的时间,这种劣势在数据量小的时候不明显,但当数据量较大时对于用户接收新数据包就体现的相当明显。表2为优化前与优化后的测试数据比较:(发送带宽500kbps,每天更新数据包4000个)。
由试验结果得出,在没有优化的情况下,接收数据的时间会随着数据量的增加的不断的增加,无法适用于大用户量的情况。
优化后即时队列和优化队列的接收时间基本上保持稳定,没有随着用户量的增加而增加,解决了98%的用户的接收问题。只有惰性队列的接收时间与用户量的增加有关并且比优化前的要慢。
四、结论
![](https://www.soolun.com/img/pic.php?url=http://img.resource.qikan.cn/qkimages/zgxt/zgxt201307/zgxt20130719-2-l.jpg)
MSCAS的设计在可扩展性、兼容性、稳定性、安全性等方面具有借鉴意义。在具体的设计和实现方面,对于在条件接收系统的设计和实现、C/S结构模式通信方式、性能优化、后台控制程序设计原则、数据广播的策略等方面也有一定的借鉴意义。
五、进一步探讨
对于MSCAS本身,操作系统平台的选择和裁剪方面还可以进一步优化,以增加系统的稳定性、安全性和效率。
而在监控方面,除了有良好的监控界面和完善的日志系统外,远程调试也是一个节省时间,提高效率的选择。
![](https://www.soolun.com/img/pic.php?url=http://img.resource.qikan.cn/qkimages/zgxt/zgxt201307/zgxt20130719-3-l.jpg)
一、代码优化
对于一套系统,使用不同的变量,函数和逻辑虽然最终都可以达到目的,但程序可读性、易维护性、复杂性可能完全不同,效率可能截然不同。
在MSCAS中有一个实际需求就是通过三个数字合起来定位一个元素。也就是说以DWORD1+DWORD2+DWORD3作为Key,去获取一个Value。MFC和STL都没有通过多个键查找一个元素的类,所以采用变通的办法,即首先将3个DWORD类型键转换成一个字符串型键:“DWORD1_DWORD2_DWORD3”这时问题就变成了通过一个字符串型key值查找一个元素了。MFC有基于CMap类的CMapStringToPtr类,而STL中有::std::map,在经过大量的效率测试后发现后者比前者具有很高的效率。
鉴于MSCAS程序多处使用了CMap,为了保持代码的兼容性,将改进后的代码按照CMap的方式将::std::map进行了封装,这样可以保证代码的最小改动性以适应其他开发人员的开发习惯。
二、数据库优化与实现
2.1MSCAS数据库瓶颈分析
CAS数据库是整个系统的数据中心,它的性能直接影响着整个系统的性能,根据分析,其特点是:
·数据表结构简单,但数据量大。
·数据库类型属于OLTP和OLAP混合模式。
![](https://www.soolun.com/img/pic.php?url=http://img.resource.qikan.cn/qkimages/zgxt/zgxt201307/zgxt20130719-1-l.jpg)
针对上述特点,数据库在设计的时候应该充分考虑到数据压力对数据库性能的影响,使用Oracle提供的分区表选件对大表进行拆分;使用存储过程封装绝大多数数据库操作以及使用合理的备份、迁移、数据生成方式提高整体系统的效率。
优化前的MSCAS,在用户数量到达10000以后,整体性能明显下降。主要原因在于:
CAS数据库的表没有建立合适的索引,致使在数据库数据量增加以后,过多的全表扫描大大增加了Oracle数据库的磁盘读写I/O压力和内存访问压力。数据库配置不合理,分配内存过少引起数据库中不必要的磁盘页面交换和内存调整。
为了提升整个CAS系统的效率,调优方法如下:
通过对数据库的表结构和索引重新进行合理设计,减少不必要的高负荷数据库操作;对Oracle数据库进行运行时刻调优,让Oracle在不同数据量压力下都能运行在最佳状态。
2.2分区表和分区索引的使用
在分区表上建立三种索引模式:全局分区索引、全局不分区索引和本地分区索引。在CAS数据库中,对于查询效率比较高的索引采用全局分区索引,同时对更新频率相对比较高的字段建立本地分区索引。
2.3索引的使用
索引(Index)是常见的数据库对象,它的设置好坏、使用是否得当,直接影响着数据库应用程序和数据库的性能。通过建立B-TREE索引、复合索引和普通索引以及位图索引相,系统速度大大提高,同时数据库压力也减小不少。
2.4测试和验证
通过对100万用户量级批量授权速度进行测试,结果表明在大用户量的情况下,一次进行190条记录的批量设置,速度仍然可以达到1分钟以内,完全可以满足商用目的。
三、数据包的收发优化策略与实现
授权信息、OSD,E-mail等信息都要求用户能即时收到的信息都是通过EMM包来传送的。因此,如何设计一种高效的发送接收策略能让用户即时的收到EMM包是条件接收系统性能优化中的最重要部分。
3.1EMM包概述
EMM包是数字电视前端向终端发送的主要信息。EMM包的收发原理是所有数据在一个大的队列中循环发送。在终端,当用户将智能卡插入机顶盒后,机顶盒将根据此智能卡的卡号来过滤流中属于此智能卡的EMM数据。EMM包发送优化的目的就是使前端新产生的数据包在终端能在最短的时间内接收处理。
3.2终端的接收机制和策略
数字电视信息终端由机顶盒、智能卡和电视机组成。机顶盒接收所有前端传来的信号,其中与CAS模块有关的EMM包和ECM包需要送入智能卡解密。最终通过ECM包得到明文的CW后,机顶盒解扰芯片将加扰的节目流解开后就可以在电视机上正常的播放。
机顶盒的工作原理如图1所示:
对于EMM包的接收,机顶盒有一个过滤器,可以通过设置特定的过滤条件来接收需要的包。通过设置过滤器,机顶盒就可以收到制定卡号的包,当过滤到一个需要的包后,会有一定的判断、解析和处理时间。因此同一张卡的两个数据包需要有一定的间隔。
3.3前端的发送机制、策略和实现
前端的发送机制首先是建立在终端接收机制基础上,只有分析研究出一个准确的业务模型,才能建立好的发送策略。
以授权包的发送为例,一个新的业务交易流程如下:用户交费→SMS调用CAS发送授权→CAS生成EMM包通过复用器发送→终端接收到EMM包→解密节目,用户可以收看节目。
大部分情况下,新业务是由用户引起的,因此前端在发送数据的时候终端机顶盒处于开状态,智能卡插在机顶盒中等待接收数据,称为第一类用户,(约占90%)。发送授权数据的当时,终端机顶盒并没有处在准备好的状态,用户可能在晚上才看电视,称为第二类用户(约占8%)。对于自动扣款的用户,有可能出差等缘故几天都不看电视,称为第三类用户(约占2%)。
根据上述分布,为了保证对于用户响应的及时性,提出优先级不同的三个逻辑上的队列:即时队列、优化队列和惰性队列。所有的数据包最后通过复用器向终端发送的时候都是一个一个串行发送的,通过点名控制模块解决如何查找“下一个”的问题。不同的是三个队列包含的数据包不同,发送的频率不同。
三个队列优先级由高到低排列如下:即时队列>优化队列>惰性队列。
3.4测试和验证
在数据包的发送策略没有优化之前,用户接收到的数据最大时间依赖于惰性队列发送一轮的时间,这种劣势在数据量小的时候不明显,但当数据量较大时对于用户接收新数据包就体现的相当明显。表2为优化前与优化后的测试数据比较:(发送带宽500kbps,每天更新数据包4000个)。
由试验结果得出,在没有优化的情况下,接收数据的时间会随着数据量的增加的不断的增加,无法适用于大用户量的情况。
优化后即时队列和优化队列的接收时间基本上保持稳定,没有随着用户量的增加而增加,解决了98%的用户的接收问题。只有惰性队列的接收时间与用户量的增加有关并且比优化前的要慢。
四、结论
![](https://www.soolun.com/img/pic.php?url=http://img.resource.qikan.cn/qkimages/zgxt/zgxt201307/zgxt20130719-2-l.jpg)
MSCAS的设计在可扩展性、兼容性、稳定性、安全性等方面具有借鉴意义。在具体的设计和实现方面,对于在条件接收系统的设计和实现、C/S结构模式通信方式、性能优化、后台控制程序设计原则、数据广播的策略等方面也有一定的借鉴意义。
五、进一步探讨
对于MSCAS本身,操作系统平台的选择和裁剪方面还可以进一步优化,以增加系统的稳定性、安全性和效率。
而在监控方面,除了有良好的监控界面和完善的日志系统外,远程调试也是一个节省时间,提高效率的选择。
![](https://www.soolun.com/img/pic.php?url=http://img.resource.qikan.cn/qkimages/zgxt/zgxt201307/zgxt20130719-3-l.jpg)