写点什么

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:471052

评论

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

作业八:设计消息队列存储消息数据的 MySQL 表格

燕燕 yen yen

#架构实战营

Apache ShenYu源码阅读系列-基于WebSocket的数据同步

子夜2104

Java 开源 网关 shenyu

没想到专科的我也能拿到年薪30W的offer,仅凭阿里这份JDK源码笔记

Java架构师迁哥

【预告】网络研讨会|下一代汽车操作系统微内核seL4:seL4基金会主席谈物理系统安全工程实践

鉴释

自动驾驶 操作系统 微内核

闲鱼消息发展回顾

OpenIM

来一份全面的面试宝典练练手,6年老Java面经总结

Java 程序员 后端

不愧是阿里内部“千亿级并发系统架构设计笔记”面面俱到,太全了

Java 架构 面试 后端 高并发

每个程序员都必须掌握的8种数据结构,springmvc源码流程总结

Java 程序员 后端

没想到我也可以入职阿里!二本毕业、两年crud经验,侥幸通过面试定级P6

Java架构师迁哥

求职季,我是这样拿到百度AI Offer的!

百度开发者中心

百度 AI 求职

MySQL日志15连问

Java MySQL 数据库 面试 后端

Fish-Lottie:纯Dart如何实现一个高性能动画框架?

阿里巴巴终端技术

flutter 开源 dart 客户端

普通二本的辛酸Java面试之路,34岁Java程序员裸辞

Java 程序员 后端

从 0 到 1 开发一个聊天通讯 服务 复盘总结分享

程序员海军

Vue 大前端 websocket 实时通讯 引航计划

包头市企业如何申请等保测评?去哪里申请?联系电话是多少?

行云管家

网络安全 等级保护 等保测评 等保评测 包头

三年开发经验,从抖音组离职后,一口气拿到15家公司Offer

Java架构师迁哥

鲲鹏BoostKit虚拟化使能套件,让数据加密更安全

华为云开发者联盟

鲲鹏

主机监控用什么软件好?监控机制是怎样的?

行云管家

运维 IT运维 主机监控

软件真的可以定义汽车么?

SOA开发者

软件 物联网 汽车

来自阿里巴巴佛系Java程序员的指南,惊喜

Java 程序员 后端

每个程序员都必须掌握的8种数据结构,2021Java开发面试解答

Java 程序员 后端

“人类高质量数据”如何训练计算机视觉模型?

澳鹏Appen

计算机视觉

垃圾弹窗广告,如何清除互联网世界的牛皮癣

石头IT视角

互动赠新书|当云原生遇到混合云:如何实现“求变”与“求稳”的平衡

阿里巴巴云原生

云计算 云原生 混合云

普通二本的辛酸Java面试之路,Java程序员架构之路该如何继续学习

Java 程序员 后端

某大厂开发者对于Java多线程的总结,Java排序算法面试

Java 程序员 后端

译介:《电动滑板车的崛起》

姬翔

音视频编解码流程与如何使用 FFMPEG 命令进行音视频处理

声网

音视频 ffmpeg

在外包做开发3年,为了进大厂,耗时半年,整合出25W字Java全栈面试题,这就是我的决心

Java架构师迁哥

60w“跳”进腾讯!你知道我经历了什么吗?

Java架构师迁哥

ShardingSphere 分片利器 AutoTable:为用户带来「管家式」分片配置体验

SphereEx

数据库 开源

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