NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

IBM 架构师谈 SPECj 创纪录测试结果和基准化进程

  • 2007-11-13
  • 本文字数:3800 字

    阅读完需:约 12 分钟

IBM 近期在用于进行高容量事务处理测试的行业基准上,以高出竞争对手 37% 的优势脱颖而出。这种高容量事务处理在当前客户环境中相当具有代表性。IBM 的 WebSphere 应用服务器在 SPECjAppServer2004 性能和可伸缩性的测试数据结果中达到了一个新的高度。[译者注:由SPEC 创立的SPECj AppServer 2004 基准测试专门设计用于测量JEE 应用服务器的性能]。

InfoQ 与 Andrew Spyker 和 John Stecher 就该测试结果进行了交流。Andrew Spyker 是负责 IBM WebSphere 应用服务器性能团队的高级技术员。Andrew 过去一直致力于研究 Web Services 和 SOA。John Stecher 则是 WebSphere 应用服务器 JEE 性能团队的领头人,同时也是当前和今后 SPECjAppServer 基准版本的首席开发者和架构师。John 已经在 SPECjAppServer 领域工作了至少五年。

能谈一下你们 IBM 的团队吗?

我们 WebSphere 应用服务器性能团队位于明尼苏达州的罗切斯特和美国北卡罗来纳州的 Research Triangle Park。我们团队致力于向我们的客户提供拥有业界领先水平的高性能应用服务器代码库。我们重点关注于"现实世界"的客户场景,这激励我们去创造多样的内部开发基准,同时也参与到像 SPECjAppServer 基准这样的标准基准合作中。我们正致力于了解我们客户在性能和交付上的所想所要。团队分成三个部分进行研究:未来的技术,目前的产品发布周期,以及服务流环境,以确保 WebSphere 应用服务器从性能角度上能够继续满足并超过我们客户的需求。我们性能团队正在撰写性能调优指南和最佳实践,用于指导我们的顾客如何在 WebSphere 应用服务器上使他们的应用程序达到最佳的性能表现。最近,Andrew 还通过 WebSphere 社区博客直接与我们的客户就性能方面进行交流。

以一个组织的立场,执行该基准从开始到结束需要多久(从第一次执行到数次之后准备提交)?与测试结果相比,你们还能有多少提升?

在规模较小的硬件配置上,从新硬件拆包开始到提交最终的结果给 SPEC 组织,实施该基准大约需要 2-3 周。涉及到更多的硬件以及复杂的网络和数据库的配置,将至少需要 1-3 个月才能完成。由于今天市场上的几乎所有软件产品最初都运行在旧的机器上,因此测试结果都有显著的改进;同时对于一个具体的硬件配置而言,即使运行在全新机器上并广泛采用适当的默认值,也不一定就能够获得很强烈的效果。但是,一旦你调整了几个参数(主要是 JVM 堆栈大小),在使用全部物理内存情况下运行就能达到很好的性能效果。通常一旦你正确设置了堆栈大小,相比在该基准上调整其他参数而言,可以得到高于预期 20-25% 的性能。

哪些方面是能够优化最多的?

在调优方面,IBM JVM 和线程池是我们优化得最多的方面。其中,JVM 可能是最关键的。在堆栈大小和垃圾回收策略方面逐步对 JVM 进行调优,可以显著提高性能。之后,调整 WebSphere 应用服务器内部的线程池对于这个基准也是很关键的,但在大多数情况下并不如使客户的应用程序得到最佳性能那么关键。这是因为当你试图在基准中脱离系统之外对每个当前事务进行调整时,你实际上终结了对特定硬件本身的调整。 SPECjAppServer 基准引导了对整个 JEE 容器的优化竞争。经过多年参与 SPECjAppServer 之中,WEB 容器、JSP 引擎、RMI 和 ORB、EJB 容器、持久化、事务管理、过载控制和网络代码都得到了显着的优化。此外,正如我们稍后将提及的,优化在 JDK 和 WebSphere 应用服务器上的进行,可以帮助在服务器级的硬件上达到最佳性能。

用什么工具进行调优,这些工具是现成的吗?

我们在基准中使用的最重要的调优工具是现成的,并随 WebSphere 应用服务器以及内含 JVM 发布。为了获得正确的堆栈大小和 JVM 参数,我们只需使用带参数的垃圾回收工具,然后查看垃圾回收的停顿时间和两次垃圾回收的间隔期。我们会设法调优堆栈让垃圾回收停顿时间最小,而间隔期达到最大。之后,在 WebSphere 应用服务器自身内,我们使用性能监控设施(PMI)和 Tivoli 性能监测器(TPV)来监测线程池的效率、连接池的使用情况以及 WebSphere 运行时其他重要统计资料。

为了这些性能改进而不得不做出的最大功能牺牲是什么?

首先,我们重点强调不会为了参与标准化基准而在 WebSphere 应用服务器的代码库上做出功能牺牲。 在配置 SPECjAppServer 时,对所有的供应商来说,最大的牺牲是缺乏实际的高可用性硬件拓扑配置。为了在这些基准所给出最小的硬件上达到最佳的性能,所有供应商都让每件硬件产品以接近 100%CPU 使用率来运行,然后在这个基础上提交测试结果。这也是因为基准并没有特别要求故障场景。在现实中,如果你想要高可用性,还需要留出额外的故障处理的硬件资源。如果基准将来要求负荷下的故障控制以及确定的服务级别,那将会很有意思。 不过现在,这还是规范标准和客户代表拓扑之间的隔阂。

当我们做定期的性能测试时,测试配置方案是以"现实顾客"高可用性拓扑为场景,用以确保这些代码路径在客户的生产环境也是最优的。

有些人觉得 SPEC 的结果并不能很好转化到现实生活的应用程序中,对此你有什么看法吗?

SPEC 的成果在向现实生活的转化,因为在基准上的竞争已经使得当今所有供应商的应用服务器做出了令人难以置信的快速发展。单就我们这方面的结果而言,在一个四核的硬件系统上,能达到每秒执行近 1200 个复杂业务水平的事务。SPEC 基准竞争机制引导厂商通过 WebSphere 应用服务器和客户日常使用软件栈的不同部分去优化公共代码路径。对客户而言,基准给客户带来的价值远远超过任何一个网页上的性能数据结果所能表示的。 而这些基准不能很好向现实生活转化的原因是,你不能只是拿着一个 SPECjAppServer2004 的数据,就拿到你的应用中使用相同的调优,以期望如此可以获得同样的性能。在大多数情况下你的应用使用的是不同的编程方法、数据库访问模式或其他的东西,这些需要特别的调优才能获取最大的性能。此外,还有许多 WebSphere 应用服务器所支持的其他功能领域,是 SPEC 基准无法测试的。这也正是为什么我们要在内部同样开发和使用多种不同的基准以改善所有代码路径,而非仅仅是使用该规范这一个具体个案。同样我们正努力工作于下一版的 SPECjAppServer 及其他新的规范标准。我们继续承诺并引导规范标准去关注在所有客户代表场景下的性能。

整体上,SPECjAppServer 测试数据作为指导。这些数据公布在一个与厂商中立的论坛上,以开放的观点显示了应用服务器整体潜在的性能。SPEC 和其他规范基准组织是最值得信赖的公开的性能数据消息源。然而,为了获得同样性能,你必须做出相应的工作和努力,来优化你的应用程序运行时的行为和模式。这正是我们一直推荐的最好的一种惯例。及早并频繁地做自己的应用性能测试,然后进行调优。

你期望这些基准支持那些非 IBM 的类似硬件 / 软件吗?

我们期望基准支持类似的非 IBM 硬件和软件栈(以一种较小变化的方式)。我们直接与其他支持的硬件和操作系统公司的性能工程师一同努力工作,以确保我们的产品在他们的硬件和 OS 堆栈上运行性能良好。我们还与其他支持的数据库公司的性能工程师一同工作,以确保我们的数据库访问机制有良好的性能表现。

你认为谁对基准的影响最大(JVM ,CPU,数据库,还是其他)?

这实在是一个很难的问题。所有的基准测试结果同时受硬件性能( CPU、内存和网络等)和软件栈性能(JVM、数据库、应用服务器和基准代码等)的影响,就如同在现实中的性能数据一样。最近,大多数基准测试结果突出表明,在最新的硬件产品上性能会有较大提升。增加硬件性能可直接使 WebSphere 应用服务器的软件栈变得更快。不过,要对最新硬件进行充分使用,我们要确保我们的软件栈(包括 JVM 和 WebSphere 应用服务器)已经为该硬件做好了能够最大程度使用该硬件能力的准备。有两个很好的例子可以显示硬件上的变化和软件相应的开发,一个是 64 位硬件上的变化,一个是大容量多核心处理器硬件上的变化。我们早在这些硬件普及到普通消费者手中之前,就开始了对 64 位和多内核的硬件变化的关注。

反过来,WebSphere 应用服务器的软件代码同样对基准性有较强的影响力。正如前所述,为了达到上面基准所体现的性能,我们对 WebSphere 应用服务器软件代码进行了积极的优化。基于整个栈对基准性能所做出的贡献这一事实,我们必须感谢我们所有性能团队,谢谢他们帮助 IBM 的整个硬件和软件栈在 SPECjAppServer 性能上做到了业界领先。同时也要感谢我们的系统和服务器团队,我们的 JVM/JIT 团队和我们的 DB2 团队。

WebSphere 应用服务器 V6.1 的评价报告,可以在这里下载。

SPEC 是一个非赢利性组织,它建立、维护并签署标准化基准,用于衡量最新一代高性能计算机的性能。它的成员是全球性的,包括世界领先的计算机硬件和软件供应商,大学和研究机构。欲了解完整的基准测试结果细节和标准性能评估公司,请参看网站 www.spec.org 。截止于 2007 年 10 月 3 日每 CPU 核的 SPECjAppServer2004 JOPS@Standard 的测试数据结果都公布在 www.spec.org。

查看英文原文: IBM Discusses Record Setting SPECj Results and the Benchmarking Process


译者简介:王军,长期从事软件开发工作,实际项目偏重于 JBOSS 平台上构建网管软件。对于性能测试工具有较多的关注,关心软件技术和相关工具的动态,将其中相对成熟的技术和工具应用到实际的项目之中。长期担任技术管理和项目管理工作,一直关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。参与 InfoQ 中文站内容建设,请邮件至 china-editorial@infoq.com

2007-11-13 00:471002

评论

发布
暂无评论
发现更多内容

快速摆脱在线扩容难的噩梦,华为云数据库有妙计!企业级Redis 包年18元~

华为云数据库小助手

GaussDB GaussDB ( for Redis )

SACE分析专家认证总结

万里无云万里天

RISC-V开发板关机流程浅析

优麒麟

Linux 技术 risc-v开发板 优麒麟

“中国牛”、“天生要强”翻新,2022蒙牛继续大满贯

科技新消息

蒙牛:以新营销和“更好”的年轻一代共鸣

科技新消息

精彩回顾 | 金融服务数字化生态的开放与安全

FinClip

金融 数据安全

基调听云直播回顾 | 让业务系统不再深不可测

基调听云

APM 可观测性 智能运维 基调听云

音视频开发—时间戳相关整理(时间基tbr,tbn,tbc)

Linux服务器开发

WebRTC ffmpeg SRS 音视频开发 流媒体服务器开发

蒙牛中国乳业产业园牧场建设项目全面复工

科技新消息

启动报名2022南京智博会 第十四届南京国际智慧城市、物联网、大数据博览会

InfoQ_caf7dbb9aa8a

物联网

ElasticSearch写入流程详解

IT巅峰技术

elasticsearch

Postman中文版客户端

Liam

Jmeter Postman API swagger Mock

北京市支援合作办公室党组书记、主任丁勇一行到正镶白旗调研京蒙协作工作

科技大数据

安装配置GPU训练环境

十三

“天生要强”的迭代和蒙牛体育IP大满贯

科技新消息

AIOps(智能运维)中的指标算法场景分享 | 内附视频&ppt资料

云智慧AIOps社区

人工智能 AI 算法 运维 告警

持续精进,性能突破,openGauss 3.0社区版正式发布

Geek_32c4d0

GaussDB(for openGauss) 社区版

你的产品越来越难卖?是时候关注价值流了

基调听云

DevOps APM 智能运维 基调听云

沙龙:如何使信息系统更加稳定

博睿数据

传统数据库改造难?华为云GaussDB“五心”解决

华为云数据库小助手

GaussDB

TDengine 荣获 CSDN IT 技术影响力之星 “年度开源项目” 、 “年度IT领军人物”奖项

TDengine

数据库 tdengine 开源

SACA分析师认证总结

万里无云万里天

AI 加持实时互动|ZegoAvatar ⾯部表情随动技术解析

ZEGO即构

计算机视觉 即构科技 Avatar

Whats On Tap | Tapdata Cloud 如何助力大型家居连锁商城推进数字化经营?

tapdata

解决方案体现的是一个公司的深度思考能力

基调听云

APM 智能运维 业务运维 基调听云

WhiteSource 是否容易受到“Spring4Shell”漏洞 CVE-2022-22965 的影响?

龙智—DevSecOps解决方案

Spring4Shell WhiteSource

东方园林应邀参加人民网《人民会客厅——两会时刻》栏目访谈

科技大数据

Tapdata Cloud 2.1.2 来啦:大波细节已就绪!字段类型可批量修改、支持微信扫码登录、新增支持 Vika 为目标

tapdata

2022第十四届南京国际人工智能产品展会

InfoQ_caf7dbb9aa8a

大数据洞察画像自动化实践

网易云信

大数据

信通院牵头数列科技参与主编的《信息系统稳定性保障能力建设指南》正式发布

TakinTalks稳定性社区

IBM架构师谈SPECj创纪录测试结果和基准化进程_Java_Scott Delap_InfoQ精选文章