跳到导航
dev2dev.bea.com.cn
首页 资源中心 dev2dev学堂 在线技术论坛 专家Blog User Group CodeShare
dev2dev 首页 > 资源中心 > 技术文章
BEA WebLogic SIP Server在Intel Xeon处理器上的基准测试

时间:2008-03-05
作者:David VerbeirenStefano Gioia
浏览次数:
本文关键字:sip benchmark WebLogic Communications Platform jrockit WebLogic Communications Platform基准测试
文章工具
推荐给朋友 推荐给朋友
打印文章 打印文章

摘要

  为测试BEA WebLogic Communication Platform 在最新的Intel服务器平台上的性能,比利时安特卫普省的Intel实验室进行了一次简单的基准测试。这次基准测试的目的是测量在基于Intel Xeon处理器(采用最新的Intel Core微架构)的服务器平台上运行BEA WebLogic SIP Server和BEA JRockit Java Virtual Machine所能实现的性能、吞吐量和延时。

  这项努力是BEA和Intel之间的一个大型合作项目的一部分,该项目的目的是验证和改进BEA WebLogic SIP Server在下一代Intel架构服务器平台上的性能。

基准测试

  所执行的基准测试将测量受测系统(System Under Test,SUT)的SIP处理性能,方法是执行一个基于SIPstone "Proxy 200"测试用例 的SIP场景。SIPstone提供了“一组度量标准,用于评估和测试SIP代理、重定向和注册服务器的性能”。开放源码的SIP加载生成工具 SIPp 可作为模拟系统通过WebLogic SIP Server发起呼叫,并在另一端响应呼叫。图1显示了所执行的SIP场景。

  The SIP scenario

  图 1. SIP场景

  应用服务器上部署了一个非常简单的SIP servlet应用程序。该SIP servlet只是充当代理的功能,它将从User Agent Client (UAC)模拟程序接收到的呼叫转发给INVITE消息中To头部所指定的接收方。该接收方作为User Agent Server (UAS)与SIPp客户端通信。您可以 点击此处 下载该应用程序的副本。

  然后,100 Trying、180 Ringing、200 OK和ACK消息将完成会话的建立。我们分别测试了0秒、40秒和80秒的呼叫持续时间,目的是确定代理服务器对保存SIP呼叫会话信息的影响。为了实现高吞吐量并限制SIP servlet代理应用程序和BEA WebLogic SIP Server维持的SIP会话数量,servlet将在响应BYE消息的200 OK经过代理时立即解除会话的有效性,而不是依赖SIP会话的内部超时。

  为确保结果的一致性,我们在运行各基准测试之前都重启了BEA WebLogic SIP Server,并依次执行预先定义的一系列预热测试(逐渐提高受测系统的SIP呼叫率)。这样可以确保JRockit Java Virtual Machine在实际基准测试开始之前实现代码的最优化。

  经过预热期之后,我们将维持固定的呼叫率不变,从而使系统的负载在一个小时之内保持稳定。在测试过程中,系统将采集会话的建立时间和受测系统的CPU利用数据。然后,我们对这些数据进行后期处理,并计算出会话建立时间的95%和CPU平均使用情况的数据图(所有数据总数的平均)。

  只有当%95以上的呼叫的建立时间(从INVITE到200 OK,以UAC为标准)低于50毫秒时,运行于特定呼叫率的基准测试才认为是有效的。

测试系统配置

  测试系统由运行SIPp UAC和UAS模拟程序的两个服务器和一个Gigabit Ethernet交换机(用于将这两个服务器连接到受测系统)组成,如图2所示。

  High level system configuration

  图 2.高级系统配置

受测系统

  受测系统由一个系统总线速度为1333 MHz,内存为8GB ECC FBDIMM的 Intel Server Board S5000PSL 组成。该主机板含有两个频率为3.0GHz的 Dual-Core Intel Xeon Processor 5100 Series。网络连接由双Intel Gigabit Ethernet接口提供。

  在整个基准测试过程中,WebLogic SIP Server 3.1都是在 BEA JRockit JVM R27.3.1 32-bit之上执行的。

  所使用的操作系统为Red Hat Enterprise Linux 4 Update 4 64-bit。

  Dual-Core Intel Xeon Processor 5100 Series基于最新的Intel Core微架构。这一创新的微架构集成了比较有效的流水线和内存架构设计,从而提供了更佳的处理器吞吐量。并且其低功耗的电源管理技术并不会影响性能。

  BEA JRockit JVM 是一款高性能的Java虚拟机(JVM),专用于确保Java应用程序的可靠性、可伸缩性、可操纵性和灵活性。

  BEA WebLogic SIP Server是行业中首款集Java EE-SIP-IMS-SOA于一体的应用服务器,并且能交付很高的可用性、可靠性、可伸缩性和性能。它是BEA WebLogic Communications Platform家族网络中间件的IMS-SIP应用服务器组件。网络设备供应商(NEP)、系统集成商(SI)和独立软件开发商(ISV)合作伙伴组成的全球生态系统对BEA WebLogic SIP Server进行了标准化,使之成为下一代通信的IMS-SIP基础。

  BEA WebLogic SIP Server在SIP Servlet技术中集成了J2EE 1.4和1.3以及其他一些领先的Internet标准,为开发高度可用、可伸缩和安全的电信应用程序提供了一个可靠的框架。BEA WebLogic SIP Server可无缝集成全异且异构的平台和应用程序,因此允许您的网络利用已有软件投资并共享企业级的服务和数据(这些服务和数据对于构建下一代电信应用程序至关重要)。

BEA JRockit配置

  测试中所使用的JRockit JVM是当前可用的JRockit R27.3.1,并且结合使用了以下命令行参数:

-Xmx3500m -Xms3500m

  该参数指定了最大、初始和最小堆大小。这是32位版本的JRockit JVM中可用的最大堆大小。但是,这对应用程序已经足够了。

-Xgc:gencon

  命令行选项-Xgc将确定JVM所使用的垃圾收集器的类型。在本例中,我们使用的是分代式(generational)并行垃圾收集器。该垃圾收集器将可将堆分成两个或多个区域,称作“代(generation)”。普通垃圾收集器都是将对象分配于一个空间中,并在空间内容满时对整个空间执行垃圾收集操作。而这种垃圾收集器有所不同,其大多数对象分配于“年轻代(young generation)”中,我们称之为托儿所。由于大多数对象在年轻时便会消亡,因此该收集器将把大多数时间花在收集托儿所中的对象上,而不是整个堆。分代式并行垃圾收集器具有一个适当大小的托儿所空间,并且使用的是并行收集器算法(用于标记(mark)和清扫(sweep)阶段),因此它对于低延时的应用程序(大多为电信应用程序)来说是极好的选择。

-XXnosystemgc

  该选项允许JRockit垃圾收集器使用启发式方法。我们应该优先使用该方法,而不是使用system.gc()方法的直接调用垃圾收集。

-XXnocompaction

  禁用Java堆紧凑(Compaction)。

-Xns40m

  该选项受到可承受的托儿所收集暂停长度的限制。包括普通的响应时间和暂停造成的实际工作集增加的时间。

-XXtlasize:min=3k

  线程本地空间的最小大小。

-XXkeeparearatio=0

  该选项指定托儿所中不保存任何年轻的对象。

BEA WebLogic SIP Server配置

  基准测试所使用的版本为WebLogic SIP Server 3.1。我们对其默认参数进行了修改,改动结果如下:

  • WebLogic SIP Server Transport queue size: 50000
  • WebLogic SIP Server Overload Protection onset queue length: 40000
  • WebLogic SIP Server Overload Protection abatement queue length: 5000

基准测试结果

  这些测试是由Intel工程师在BEA的技术支持下执行的,时间为2007年7月,地点是位于比利时安特卫普省的Intel嵌入式和通信解决方案实验室。下表概述了对不同呼叫持续时间测试得到的结果。

呼叫持续时间 JVM数量 处理器 每秒处理的呼叫数 CPU利用率
0s 1 Xeon 5160 1300 57.6%
40s 1 Xeon 5160 1100 54.9%
80s 1 Xeon 5160 860 50.1%

  正如预期的那样,系统在运算极限内可维持的负载将随着呼叫持续时间的增加而降低。其原因是更多数量的动态会话将造成堆使用的增加并且在将消息发送给会话上下文时要求SIP服务器完成更多的工作。但是,其负载的降低并不是很明显,因为SIP会话对象将占用相当大的内存(30-50 KB)。

  从CPU利用率的数值可以看出,还有足够的活动空间供应用程序使用,而不会显著地影响所实现的呼叫率。

  还有一点值得注意,该基于Java的实现所获得的性能与原生(C/C++)SIP代理实现在类似平台上的所获得的性能并没有多大差距。

详细结果

  本节中的图将显示在不同呼叫持续时间下呼叫建立时间和CPU利用率随呼叫率增加的变化情况。同时图中还显示了重发率和失败率。

0秒持续时间

  Detailed results for 0s call duration

  图 3. 0秒持续时间的详细结果

  由于呼叫将立即断开连接,因此CPU使用情况将随着呼叫率的增加呈线性增长。

40秒持续时间

  Detailed results for 40s call duration

  图 5. 40秒持续时间的详细结果

  由于SIP会话将在40秒内处于活动状态,因此将消息发送给适当的会话处理程序需要更多的CPU周期,并且需要管理更大的Java堆。这可能就是CPU利用率的增长高于线性的原因。

80秒持续时间

  Detailed results for 80s call duration

  图 6. 80秒持续时间的详细结果

  在80秒持续时间的情况下,CPU利用率的增长趋势比40秒持续时间更强。

结束语

  首轮基准测试的性能图显示:BEA WebLogic Communication Platform解决方案的处理能够超过每秒1000个SIP呼叫,并且可以维持足够低的CPU利用率(大约为50%),还提供了一定的空间用于部署额外的Java应用程序或引入一些高可用的特性,如集群和重复(eplication)特性。

  通过扩展BEA WebLogic SIP Server实例的数量并利用该平台的集群和重复功能,并结合Intel Xeon Processor 5100和5300系列的性能和可靠性,还可以获得巨大的提升空间。这表明Intel和BEA是绝妙的一对组合,并且应该成为应用程序和解决方案部署的基础。

  显然,这还表明基于Java的解决方案能够处理高吞吐量和低延时,从而满足当今电信网络的需求。

下载

参考资料

感谢

  我要对Francois Deza(BEA Systems业务开发部门的高级管理人员)和Stefan Sarne(BEA Systems的高级工程师)表示感谢。他们对本文提出了许多宝贵的意见并在测试阶段给予了大量的支持。

  原文出处:http://dev2dev.bea.com/pub/a/2007/10/wl-sip-server-benchmark.html

 作者简介
David Verbeiren 是Intel嵌入式和通信小组(Embedded and Communications Group)的应用程序开发工程师。
icon
Stefano Gioia
Stefano Gioia 是EMEA的BEA WebLogic Sip Server 技术专家。他把主要精力都放在让IMS及其工作人员和合作伙伴能够跨越欧洲、中东和非洲的努力上。
dot dot dot

dot
  作者其它文章
您对本文的评价
您对这篇文章的看法如何?
太棒了!5分 不错啊 4分 一般般 3分 有待提高 2分 不好 1分

   
相关产品