常见的服务器性能指标有哪些及简要介绍

当前业界常见的服务器性能指标有:
TPC-C
TPC-E
TPC-H
SPECjbb2005
SPECjEnterprise2010
SPECint2006 及 SPECint_rate_2006
SPECfp2006 及 SPECfp_rate_2006
SAP SD 2-Tier
LINPACK
RPE2

一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发 布主要基准测试为:

TPC-C : 数据库在线查询(OLTP)交易性能
TPC-E : 数据库在线查询(OLTP)交易性能
TPC-H : 商业智能 / 数据仓库 / 在线分析(OLAP)交易性能

1.TPC-C测试内容:数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现. 正规 TPC-C 测试结果发布必须提供 tpmC值, 即每分钟完成多少笔 TPC-C 数据库交易 (TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把 TPC-C 测试结果写成为 tpm, TPM, TPMC, TPCC 均不属正规。
2.TPC-E测试内容:数据库事务处理测试,模拟一个证券交易系统。与TPC-C一样,实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现。正规TPC-E测试结果必须提供tpsE值,即每秒钟完成多少笔TPC-E数据库交易(transaction per second),同时提供$/tpsE。测试结果写成其他形式均不属正规。
对比:TPC-E测试较TPC-C测试,在测试模型搭建上增加了应用服务器层,同时增加了数据库结构的复杂性,测试成本相对降低。截止目前,TPC-E的测试结果仅公布有50种左右,且测试环境均为PC服务器和windows操作系统,并无power服务器的测试结果。除此之外,TPC官方组织并未声明TPC-E取代TPC-C,所以,说TPC-E取代TPC-C并没有根据。
附 TPC-C与TPC-E数据库结构对比

3.TPC-H测试内容:对大型数据仓库进行决策支持(decision support)的基准测试。TPC-H包含一组复杂的业务查询及修改操作,属于商业智能/数据仓库/在线分析(OLAP)交易性能测试。测试结果按数据仓库的大小分为100GB/300GB/1TB/3TB/10TB/30TB。不同容量级别的测试结果不能进行对比。
测试结果必须包含QphH@size及$/QphH@size。因各厂家测试选择的测试级别不同,所以结果的可比性较低。

二、SPEC (Standard Performance Evaluation Council) 即标准性能评估协会,成立于1988年的非盈利组织,最初由多家工作站厂家建立及后发展到各主要软硬件供应商均参与,成立目标 : 为业界提供现实而标准化之性能测试,为市场提供公平和各种有用的量度标准,并在发挥厂家优势及严格遵守法则之间取得平衡。SPEC发布各种不同种类的基准测试, 包括 :

SPECjbb2005: 作为 JAVA 应用服务器之性能
SPECjEnterprise2010: 服务器执行 J2EE 应用之性能
SPEC CPU 2006: 处理器单核或多核在处理整点及浮点计算性能

4.SPECjbb2005 (Java Business Benchmark)基准测试模拟一个三层架构环境来进行 JAVA应用服务器测试,目的是衡量应用服务器端 JAVA 应用 (Server-side Java Application) 之性能。正规SPECjbb2005 测试结果发布必须提供 bops 值, 即每秒钟完成多少笔JAVA 业务操作 (Business Operation Per Second), 同时要求提供完整的测试环境资料,包括:服务器名称,处理器内核数量,线程数量,JVM名称,JVM数量,bops/JVM性能等。

5.SPECjEnterprise2010基准测试:模拟汽车供应链系统,来测试采用J2EE (Java 2 Enterprise Edition) 5.0 技术之应用服务器性能。正规 SPECjEnterprise2010 测试结果发布必须提供 EjOPS 值, 即每秒钟完成多少笔企业级JAVA操作 (Enterprise java Operation Per Second), 同时要求提供完整的测试环境资料,包括:Java EE 应用服务器名称,DB服务器名称,处理器内核数量,J2EE服务器数量等。

6.SPECint2006 及 SPECint_rate_2006 基准测试之目的,分别是衡量单处理器(吞吐量)及多处理器(整机)的整点计算能力和编译器的优化能力.测试结果为相对性能值,主要反映处理器整点计算、吞吐量、缓存性能及编译器之优化能力, SPEC整点计算能力提供共4类型测试结果,分别如下:

SPEC标准选项来编译测试应用

厂家最优化选项来编译测试应用

单处理器(吞吐量)整点计算能力

SPECint_base2006

SPECint2006

多处理器(整机)整点计算能力

SPECint_rate_base2006

SPECint_rate_2006

7.SPECfp2006 及 SPECfp_rate_2006 基准测试之目的,分别是衡量单处理器(吞吐量)及多处理器(整机)的浮点计算能力和编译器的优化能力. 测试结果为相对性能值, 主要反映处理器浮点计算、缓存性能及编译器之优化能力. SPEC浮点计算能力提供共4类型测试结果,分别如下

SPEC标准选项来编译测试应用

厂家最优化选项来编译测试应用

单处理器(吞吐量)浮点计算能力

SPECfp_base2006

SPECfp2006

多处理器(整机)浮点计算能力

SPECfp_rate_base2006

SPECfp_rate_2006

三、SAP基准测试组织由SAP及其技术合作伙伴代表组成,包括各主要软硬件供应商支持,设立目标 : 提供一个专门为 SAP ERP 企业资源管理应用设计的基准测试工具, 所有厂家必须通过SAP测试性能作为SAP服务器配置(Sizing)的标准指标。SAP基准测试组织发布各种不同种类的基准测试, 包括 :

SAP SD (2-Tier / 3-Tier) Standard Application Benchmark : SAP Sales & Distribution Module
SAP BW Standard Application Benchmark : SAP Business Information Warehouse Module
SAP TRBK Standard Application Benchmark : SAP Banking Account & Deposite Management
SAP Enterprise Portal-ESS Standard Application Benchmark : SAP NetWeaver Portal

8.SAP SD 2-Tier 基准测试内容 :衡量不同硬件厂家加上数据库后执行SAP企业资源管理应用销售及分销 (SD 即Sales & Distribution) 模块时的性能表现。SAP SD 两层结构基准测试将应用服务器及数据库服务器安装在同一台物理服务器上。测试结果会被标准化成 SAP SD 应用模块的 SAPS 应用标准性能值(SAP Application Performance Standard)。SAPS 为一个独立于硬件的性能指标。100 SAPS 值在 SAP SD 应用定义里等同于每小时2000笔商业处理定单项目 (fully business processed order line items per hour)。每一笔商业处理定单项目包含新定单产生、发货单产生、定单显示、改变发货内容、货品录入、列出定单及产生发票;从技术角度来说,等同于每小时2400笔SAP交易或每小时6000笔对话 (控制台改变) 加上每小时2000笔录入操作。

四、Linpack是业界应用最广的的用于测试高性能计算机系统浮点性能的benchmark, 在目标集群中运行Linpack测试程序,测试结果以浮点运算每秒(Flops)给出。
MFlops=每秒一百万次(10^6)浮点运算
GFlops=每秒十亿次(10^9)浮点运算
TFlops=每秒一万亿次(10^12)浮点运算
PFlops=每秒一千万亿次(10^15)浮点运算

五、RPE2是relative performance estimate 2的缩写,由IDEAS international公司发布。它只是理论上,通过对TPC-C,TPC-H,SAP SD 2-Tier,SPECjbb,SPECint_rate,SPECfp_rate等benchmark进行几何运算得来,并不经过真实的测试环境。主要为了在不同的产品在不同的benchmark各有优劣时进行比较。

### 软件性能评估中常见性能指标及判断方法 #### 常见性能指标 在软件性能评估中,常见性能指标包括但不限于以下几类: 1. **系统性能指标** - **TPS(Transactions Per Second)**:每秒系统能够处理的事务数。这是衡量系统事务处理能力的重要指标[^1]。 - **QPS(Queries Per Second)**:每秒系统能够响应的查询数。它通常用于描述服务端的请求处理能力[^2]。 - **响应时间(Response Time, RT)**:从用户发起请求到收到完整响应的时间间隔。响应时间直接影响用户体验,是评估系统性能的关键指标之一。 - **成功率**:成功完成的请求占总请求的比例。高成功率表明系统稳定性较好。 2. **资源指标** - **CPU资源利用率**:CPU的使用率反映了系统的计算负载情况。过高或过低的CPU利用率都可能提示潜在问题[^1]。 - **内存利用率**:内存使用情况直接关系到系统的运行效率和稳定性。内存泄漏会导致系统性能下降甚至崩溃。 - **I/O性能**:磁盘读写速度和网络带宽使用情况对系统性能有重要影响。 3. **应用指标** - **空闲线程数**:服务器中未被占用的线程数量,可用于评估系统的并发处理能力。 - **数据库连接数**:数据库连接池的大小和使用情况会影响系统的响应速度和吞吐量。 - **GC/FULL GC次数**:垃圾回收的频率和耗时可以反映Java应用的内存管理效率。 #### 如何判断系统性能是否达标 判断系统性能是否达标需要综合考虑多个方面,包括业务需求、行业标准和技术限制等。 1. **基准测试** 在固定条件下测量系统的初始性能,作为后续优化的参照基准。通过基准测试可以确定系统在理想环境下的最大TPS和QPS。 2. **压力测试** 模拟多用户同时访问系统,观察TPS和QPS的变化趋势以及响应时间是否满足要求。当RPS(Requests Per Second)持续增大时,如果TPS不变甚至下降,且响应时间变长,则表明系统已达到性能瓶颈。 3. **负载测试** 逐步增加负载,直到系统达到性能瓶颈,记录此时的TPS和QPS。例如,假设系统最高TPS为1000,每天工作时间为8小时,则日吞吐量为 `1000 * 60 * 60 * 8 = 2,880,000` 事务[^3]。 4. **对比行业标准** 将实际测得的TPS和QPS与行业标准进行对比,判断是否满足业务需求。例如,金融行业的TPS通常要求在1000到50000之间,而小型网站可能只需要几百到几千的TPS即可满足需求。 #### 示例代码:模拟TPS和QPS的计算 以下是一个简单的Python代码示例,用于模拟TPS和QPS的计算: ```python def calculate_tps(total_transactions, duration_seconds): return total_transactions / duration_seconds def calculate_qps(total_queries, duration_seconds): return total_queries / duration_seconds # 示例数据 total_transactions = 10000 # 总事务数 total_queries = 20000 # 总查询数 duration_seconds = 60 # 测试持续时间(秒) tps = calculate_tps(total_transactions, duration_seconds) qps = calculate_qps(total_queries, duration_seconds) print(f"TPS: {tps} transactions per second") print(f"QPS: {qps} queries per second") ``` #### 注意事项 - 不同类型的系统对TPS和QPS的要求差异较大,需根据实际业务场景设定合理的性能目标。 - 在评估性能时,还需综合考虑响应时间、错误率等其他关键指标。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值