数据库性能测试报告-1.0.0
Veeam Availability Suite-POC测试报告 v1.0

某某客户Veeam Availability Suite v9 POC 测试报告目录1测试介绍和目的 (4)2系统架构 (6)2.1部署拓扑图 (6)2.2测试环境信息 (7)2.3组件介绍 (7)Veeam Backup Server (7)Backup Proxy (8)Backup Repository (9)Veeam ONE Server (9)3功能验证 (11)3.1与VMware集成 (11)特点 (11)POC验证截图 (11)3.2备份任务的负载均衡 (13)特点 (13)POC验证截图 (14)3.3备份空间的灵活扩展 (14)特点 (14)POC验证截图 (15)3.4数据备份 (16)特点 (16)POC验证截图 (16)3.5数据恢复 (20)特点 (20)POC验证截图 (21)3.6即时恢复(高速迁移) (22)特点 (22)POC验证截图 (23)3.7SureBackup(验证备份可恢复性) (24)特点 (24)POC验证截图 (26)3.8Replication复制功能 (26)特点 (26)POC验证截图 (27)4测试记录 (31)4.1常规项目测试 (31)系统安装搭建过程 (31)系统操控性与界面友好性 (32)4.2备份策略与任务 (33)4.3虚拟机的备份功能、监测与性能 (36)虚拟机的image恢复功能、监测与性能 (37)虚拟机的instance恢复功能、监测与性能 (38)4.4虚拟机恢复验证测试策略功能(SureBackup) (40)4.5虚拟机复制功能、监测与性能 (41)4.6Veeam one监控报表功能 (42)5测试结论 (44)1 测试介绍和目的某某客户(以下简称:)使用了VMware虚拟化作为应用系统的基础架构,虚拟化环境已经投入xx百台ESXi物理服务器,当前VM虚机规模1xxx左右.虚拟机系统以Linux为主(Linux系统占虚拟机的x0%,Windows系统占虚拟机的x0%),为避免虚机系统因人员误操作、安全漏洞、设备故障等原因造成的数据损坏或业务中断,目前宜信正在为提升服务器虚拟化平台的数据完整性、业务连续性做调研和论证.本次测试主要针对用户VMWARE平台的备份/恢复工作,通过使用Veeam旗舰级产品Veeam Availability Suite软件套件进行全面、深入的测试,来检验Veeam数据保护和管理系统是否能满足用户对数据完整性和可用性、业务连续性等各类迫切的实际需求,为本次项目提供更有效、更可靠、更全面的技术参考与实际测试依据,此次测试内容如下:2 系统架构2.1 部署拓扑图本次POC部署拓扑图如下所示:图表2-1 POC环境部署图测试环境准备:1、采用了1台服务器(本次使用虚拟机进行测试)部署Veeam Backup Server和Veeam VeeamONE Server。
数据库性能测试:sysbench用法详解

数据库性能测试:sysbench⽤法详解1.简介和安装sysbench是⼀个很不错的数据库性能测试⼯具。
如果是编译安装,需要先安装好mysql的开发包(尽管编译错误时提⽰的是缺少Mysql库⽂件)。
yum -y install mysql-community-develtar xf 1.0.15.tar.gzcd sysbench-1.0.15./autogen.sh./configuremake -jmake install安装后,只有⼀个⼆进制⽂件sysbench,还提供了很多个lua脚本。
[root@s1 ~]# rpm -ql sysbench | grep 'bin\|lua'/usr/bin/sysbench/usr/share/sysbench/bulk_insert.lua/usr/share/sysbench/oltp_common.lua/usr/share/sysbench/oltp_delete.lua/usr/share/sysbench/oltp_insert.lua/usr/share/sysbench/oltp_point_select.lua/usr/share/sysbench/oltp_read_only.lua/usr/share/sysbench/oltp_read_write.lua/usr/share/sysbench/oltp_update_index.lua/usr/share/sysbench/oltp_update_non_index.lua/usr/share/sysbench/oltp_write_only.lua/usr/share/sysbench/select_random_points.lua/usr/share/sysbench/select_random_ranges.lua/usr/share/sysbench/tests/include/inspect.lua/usr/share/sysbench/tests/include/oltp_legacy/bulk_insert.lua/usr/share/sysbench/tests/include/oltp_legacy/common.lua/usr/share/sysbench/tests/include/oltp_legacy/delete.lua/usr/share/sysbench/tests/include/oltp_legacy/insert.lua/usr/share/sysbench/tests/include/oltp_legacy/oltp.lua/usr/share/sysbench/tests/include/oltp_legacy/oltp_simple.lua/usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua/usr/share/sysbench/tests/include/oltp_legacy/select.lua/usr/share/sysbench/tests/include/oltp_legacy/select_random_points.lua/usr/share/sysbench/tests/include/oltp_legacy/select_random_ranges.lua/usr/share/sysbench/tests/include/oltp_legacy/update_index.lua/usr/share/sysbench/tests/include/oltp_legacy/update_non_index.lua本⽂介绍的是新版本sysbench oltp lua脚本的⽤法(/usr/share/sysbench/*.lua),所以不涉及传统的lua(tests/include/oltp_legacy/*.lua),如果想要了解这些传统Lua脚本的⽤法,⽹上随便找。
移动通信网网络管理技术规范 OMC北向接口 PCRF性能测量数据V1.0.0

1范围 (1)2规范性引用文件 (1)3术语、定义和缩略语 (1)3.1术语和定义 (1)3.1.1性能测量族 (1)3.2缩略语 (1)4PCRF GX接口消息测量数据 (2)4.1CC发起请求次数 (2)4.2CC发起成功次数 (2)4.3CC发起失败次数 (3)4.4CC更新请求次数 (3)4.5CC更新成功次数 (4)4.6RA请求次数 (4)4.7RA成功次数 (5)4.8RA失败次数 (5)4.9RA超时次数 (6)4.10CC结束请求次数 (6)4.11CC结束成功次数 (7)5SCTP偶联性能测量数据 (8)6以太网端口性能测量数据 (8)7系统负荷测量数据 (8)8编制历史 (8)本标准主要用于PCRF OMC北向接口性能测量。
本标准包括的主要内容为PCRF性能测量数据定义。
本标准是LTE OMC北向接口信息模型系列标准之一,该系列标准的结构、名称或预计的名称如下:标准需与QB-W-002-2009《移动通信网网络管理接口技术规范OMC北向接口-公共性能测量参数》配套使用。
1范围本标准规定了LTE网络管理接口中PCRF性能测量参数。
本规范支持LTE核心网网络质量指标分析,有关指标算法定义参见核心网网络管理指标技术规范。
本标准的用户群可能包括:运营商管理人员、运营商网络维护人员、运营商业务流量分析人员、运营商客服服务人员、设备商性能建模分析人员和设备商工程建设人员。
2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件,其最新版本适用于本标准。
3术语、定义和缩略语3.1术语和定义3.1.1性能测量族3.2缩略语4PCRF Gx接口消息测量数据4.1CC发起请求次数a) 重要度:Ab) 英文名称:InitialRequestc) 中文名称:CC发起请求次数d) 定义:发起Credit Control请求次数;e) 触发点:PCRF收到CC-Request(CC-Request-Type=INITIAL_REQUEST)消息(见3GPP TS29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.2CC发起成功次数a) 重要度:Ab) 英文名称:InitialSuccessc) 中文名称:CC发起成功次数d) 定义:发起Credit Control的成功次数;e) 触发点:PCRF发出CC-Answer(CC-Request-Type=INITIAL_REQUEST,Result-Code=2001)消息(见3GPP TS 29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.3CC发起失败次数a) 重要度: (0)B (1)Cb) 英文名称:(0)InitialFail (1)InitialFail._Causec) 中文名称:(0)CC发起失败次数(1)分原因的CC发起失败次数d) 定义:发起Credit Control失败次数,并按不同的原因码分类统计e) 触发点:PCRF发出CC-Anwser(Result-Code≠2001)消息;f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:(0)否(1)否m) 备注:4.4CC更新请求次数a) 重要度:Ab) 英文名称:UpdateRequestc) 中文名称:CC更新请求次数d) 定义:更新Credit Control请求次数;e) 触发点:PCRF收到CC-Request(CC-Request-Type=UPDATE_REQUEST)消息(见3GPP TS29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.5CC更新成功次数a) 重要度:Ab) 英文名称:UpdateSuccessc) 中文名称:CC更新成功次数d) 定义:更新Credit Control的成功次数;e) 触发点:PCRF发出CC-Answer(CC-Request-Type=UPDATE_REQUEST,Result-Code=2001)消息(见3GPP TS 29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.6RA请求次数a) 重要度:Ab) 英文名称:DIAM.ReAuthRequestc) 中文名称:RA请求次数d) 定义:Re-Auth请求次数;e) 触发点:PCRF发出Re-Auth-Request消息(见3GPP TS 29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.7RA成功次数a) 重要度:Ab) 英文名称:DIAM.ReAuthSuccessc) 中文名称:RA成功次数d) 定义:Re-Auth成功次数e) 触发点:PCRF收到Re-Auth-Anwer(Result- Code=2001)消息(见3GPP TS 29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.8RA失败次数a) 重要度: (0)B (1)Cb) 英文名称:(0)DIAM.ReAuthFail (1)DIAM.ReAuthFail._Causec) 中文名称:(0)RA失败次数(1)分原因的RA失败次数d) 定义:Re-Auth失败次数,并按不同的原因码分类统计e) 触发点:PCRF收到Re-Auth-Anwser(Result-Code≠2001)消息;f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:(0)否(1)否m) 备注:4.9RA超时次数a) 重要度:Bb) 英文名称:DIAM.ReAuthTimeoutc) 中文名称:RA超时次数d) 定义:Re-Auth超时次数;e) 触发点:PCRF的等待定时器超时仍未收到Re-Auth-Answer消息(见3GPP TS 29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:否m) 备注:4.10CC结束请求次数a) 重要度:Ab) 英文名称:TerminateRequestc) 中文名称:CC结束请求次数d) 定义:结束Credit Control请求次数;e) 触发点:PCRF收到CC-Request(CC-Request-Type=TERMINATE_REQUEST)消息(见3GPP TS29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:4.11CC结束成功次数a) 重要度:Ab) 英文名称:TerminateSuccessc) 中文名称:CC结束成功次数d) 定义:结束Credit Control的成功次数;e) 触发点:PCRF发出CC-Answer(CC-Request-Type=TERMINATE_REQUEST,Result-Code=2001)消息(见3GPP TS 29.212);f) 采集方式:CCg) 数据类型:整型h) 单位:次i) 空间粒度:EpRpDynGxPcrfj) 时间粒度:15分钟k) 上报周期:15分钟l) 测试要求:是m) 备注:5SCTP偶联性能测量数据参见《移动通信网网络管理技术规范 OMC北向接口 eNodeB性能测量数据》的公共性能测量数据的4.2节。
产品性能测试报告

产品性能测试报告报告编号:CPM2022-001报告日期:2022年10月10日报告主题:产品性能测试报告1. 背景介绍对于任何产品,性能是其最重要的指标之一。
本报告旨在对XXX公司新产品进行全面的性能测试和分析,以评估其在实际环境中的表现,并为产品改进提供参考。
2. 测试目的本次性能测试的主要目的如下:- 评估产品的各项性能指标,包括但不限于速度、稳定性和资源利用率。
- 针对测试结果进行分析,发现性能瓶颈和优化方向,提供改进建议。
- 验证产品是否满足设计规格和用户需求,确保产品质量和可靠性。
3. 测试环境为了保证测试结果的准确性和可比性,我们在以下环境中进行了测试:- 操作系统:Windows 10 Professional- 处理器:*************************- 内存:16GB- 硬盘:500GB SSD- 软件版本:XXX产品版本1.0.04. 测试方法我们采用了以下测试方法来评估产品的性能:- 压力测试:模拟高负载情况下的产品表现,测试其稳定性和响应时间。
- 并发测试:通过同时模拟多个用户请求,评估产品在多线程场景下的性能表现。
- 资源利用率测试:监测产品在运行过程中的CPU、内存和磁盘利用率,以评估其资源消耗情况。
- 容量测试:测试产品在处理大量数据时的性能表现和容量限制。
5. 测试结果与分析经过一系列测试,我们得出了以下结论和分析结果:5.1 速度和响应时间在压力测试中,产品的平均响应时间表现稳定,均低于1秒。
根据用户需求,这个响应时间已经满足了产品的性能要求。
5.2 稳定性产品在长时间高负载运行的情况下,未出现任何异常崩溃或错误,表现出令人满意的稳定性。
5.3 并发性能在并发测试中,产品在100个同时请求的情况下,每秒能够处理150个请求,响应时间保持在合理的范围内。
然而,在高并发场景下,我们观察到了轻微的性能下降,建议在后续版本中进一步优化处理能力。
5.4 资源利用率产品在正常运行情况下,对CPU和内存的利用率保持在合理范围内,但在某些特定操作下,磁盘利用率较高,建议优化磁盘读写性能,以提升整体性能。
BingoCloud云平台Intel CAS测试报告_v1.0

1.2.3 产品规格和系统要求
本测试中 Linux 版本的 Intel CAS 支持的操作系统及系统要求如表 1-2 所示。
表 1-2 系统要求 操作系统
内存 CPU 资源占用率 固态硬盘
ise Linux(RHEL) 5.6 Built and configured with x86_64,Kernel 2.6.18
Red Hat Enterprise Linux(RHEL) 6.1 Built and configured with x86_64,Kernel 2.6.32
1.2 测试对象
1.2.1 软件简介
本次测试的对象是 iCAS 软件,该软件是由 Intel 研发的部署在服务器端的基于固态硬盘(SSD) 的热点数据缓存加速软件,旨在帮助优化数据中心环境中的固态驱动器硬件的性能。
本次测试选择的软件版本和名称详情如表 1-1 所示。
表 1-1 测试软件版本和名称
软件
3 测试场景和用例 .................................................................. 6 3.1 硬盘读取性能测试 .......................................................... 6 3.1.1 用例一:硬盘随机读取性能测试 ........................................ 6 3.1.2 用例二:硬盘连续读取性能测试 ........................................ 6 3.2 数据库访问性能测试 ........................................................ 6 3.2.1 用例三:不同负载下数据库访问性能测试 ................................ 6 3.2.2 用例四:数据库备份性能测试 .......................................... 7 3.3 Exchange 邮件系统压力测试 ................................................. 7 3.3.1 用例五:Exchange 数据库压力测试 ...................................... 7
性能测试报告

2.0和1.0默认对比百分比
20.62
dubbo序列化相比hessian2序列化百分比
4.82
1k TPS
1k Response
TPS成功平均值
响应时间成功平均值(ms)
dubbo1(hessian2序列化+mina
1962.7
10813.5
dubbo2 (hessian2序列化+netty)
11994
dubbo2 (dubbo序列化+netty)
13620
rmi
2461.79
hessian
2417.7
http(json序列化)
8179.08
JVM 内存运行稳定,无 OOM,堆内存中无不合理的大对象的占用。通过
CPU、内存、网络、磁盘、文件句柄占用平稳。通过
无频繁线程锁,线程数平稳。通过
业务线程负载均衡。通过
性能测试场景(10 并发)
传入 1k String,不做任何处理,原样返回
传入 50k String,不做任何处理,原样返回
本次性能测试考察的是 dubbo 本身的性能,实际使用过程中的性能有待应用来验证。
由于 dubbo 本身的性能占用都在毫秒级,占的基数很小,性能提升可能对应用整体的性能变化不大。
由于邮件篇幅所限没有列出所有的监控图,如需获得可在大力神平台上查询。
ቤተ መጻሕፍቲ ባይዱ
11940
dubbo2 (hessian2序列化+netty)
14402
dubbo2 (dubbo序列化+netty)
15096
rmi
软件压力测试报告

软件压力测试报告压力测试报告1. 测试概述在本次压力测试中,我们对软件进行了一系列压力测试以评估其在高负载情况下的性能表现。
测试的目标是确定软件在正常使用情况下的性能限制和最大负载能力。
2. 测试环境- 操作系统:Windows 10- 处理器:Intel Core i7- 内存:8GB- 软件版本:1.0.03. 测试方法我们使用了压力测试工具来模拟大量用户同时访问软件,并记录软件在不同负载下的响应时间、吞吐量和错误率等指标。
我们根据测试结果绘制了性能曲线图以便于分析软件的性能表现。
4. 测试结果- 响应时间:在轻负载情况下,软件的响应时间平均为500毫秒。
但随着负载的增加,响应时间逐渐增加,最终达到了2秒的峰值。
- 吞吐量:在轻负载情况下,软件的吞吐量平均为100个请求/分钟。
但随着负载的增加,吞吐量逐渐下降,最终达到了50个请求/分钟的峰值。
- 错误率:在轻负载情况下,软件的错误率非常低,仅为0.5%。
但随着负载的增加,错误率逐渐增加,最终达到了5%的峰值。
5. 结论根据测试结果,我们可以得出以下结论:- 软件在轻负载情况下表现良好,响应时间短,吞吐量高,并且错误率低。
- 软件在高负载情况下性能有所下降,响应时间增加,吞吐量下降,并且错误率增加。
- 软件的最大负载能力是50个请求/分钟,在这个负载下软件的性能已达到其极限。
6. 建议鉴于测试结果,我们建议以下改进措施以提升软件的性能: - 优化软件的代码,提高其执行效率,从而减少响应时间。
- 增加软件的服务器容量,提高其吞吐量。
- 定期进行性能测试,并根据测试结果优化软件的设计和架构。
注:以上报告仅是假设的示例,实际报告会根据具体测试情况和要求进行编写。
软件测试报告性能测试评估

软件测试报告性能测试评估一、背景介绍在软件开发过程中,性能是一个非常重要的考量因素。
为了确保软件的稳定性和可靠性,需要进行性能测试评估。
本文将对软件的性能测试结果进行报告,并对性能测试评估进行分析和总结。
二、测试环境1. 软件版本:XXX软件 V1.02. 操作系统:Windows 103. 处理器:Intel Core i7-87004. 内存:16GB DDR45. 硬盘:256GB SSD6. 浏览器:Google Chrome 92.0.4515.159三、测试方法我们采用了以下的测试方法来评估软件的性能:1. 负载测试:通过给软件施加不同负载,观察其在高负载下的表现。
2. 压力测试:通过给软件施加高并发请求,观察其在并发情况下的响应时间和资源利用率。
3. 容量测试:通过逐渐增加数据量,观察软件在不同数据量下的性能表现。
4. 稳定性测试:通过长时间运行软件,观察其在连续运行时的稳定性和资源消耗情况。
四、测试结果经过以上测试方法的评估,我们得到了以下的测试结果:1. 负载测试结果:在负载测试中,软件在正常负载下的表现良好,平均响应时间为X毫秒。
在高负载情况下,平均响应时间略有增加,为X毫秒。
整体来说,软件的性能在负载测试中表现稳定。
2. 压力测试结果:在压力测试中,软件在并发请求数量为X时,平均响应时间为X毫秒,资源利用率为X%。
随着并发请求数量的增加,平均响应时间逐渐增加,资源利用率也有所增加。
我们推测软件在极限并发情况下可能会出现性能瓶颈,建议在实际应用部署时进行进一步优化。
3. 容量测试结果:在容量测试中,我们逐渐增加数据量,观察软件的性能表现。
结果显示,软件在处理小规模数据时表现良好,平均响应时间为X毫秒。
随着数据量的增加,平均响应时间逐渐增加。
对于大规模数据,软件的性能有所下降。
建议在处理大规模数据时优化算法和资源配置,以提高性能。
4. 稳定性测试结果:在连续运行测试中,我们发现软件在长时间运行时表现非常稳定,没有出现明显的崩溃和性能下降情况。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据库性能测试报告
目录
1.前言 (4)
2.测试方法概述 (4)
2.1.测试环境 (4)
2.1.1.硬件环境 (4)
2.1.2.软件环境 (5)
2.2.测试工具 (5)
2.2.1.Tpch介绍 (5)
2.2.2.Jmeter介绍 (7)
2.2.3.Nmon介绍 (7)
2.3.测试方法 (7)
3.测试过程 (8)
3.1.测试数据库搭建 (8)
3.2.测试脚本准备 (8)
3.2.1.DDL脚本 (8)
3.2.2.平面数据文件 (8)
3.2.3.查询sql语句 (8)
3.3.测试数据规模 (26)
3.4.测试工具开发 (26)
3.4.1.插入数据功能 (26)
3.5.测试步骤 (27)
4.测试结果 (28)
4.1.数据量级—1GB (28)
4.1.1.装载时间对比 (29)
4.1.2.串行时间对比 (29)
4.1.3.并行时间对比 (30)
bright资源消耗情况 (30)
4.1.5.PostgreSQL资源消耗情况 (31)
4.2.数据量级—10GB (33)
4.2.1.装载时间对比 (34)
4.2.2.串行时间对比 (35)
4.2.3.并行时间对比 (35)
bright资源消耗情况 (36)
4.2.5.PostgreSQL资源消耗情况 (38)
4.3.数据量级—30GB (41)
4.3.1.装载时间对比 (42)
4.3.2.串行时间对比 (42)
4.3.3.并行时间对比 (43)
bright资源消耗情况 (43)
4.3.5.PostgreSQL资源消耗情况 (46)
4.4.数据量级—100GB (48)
4.4.2.串行时间对比 (50)
4.4.3.并行时间对比 (50)
bright资源消耗情况 (51)
4.4.5.PostgreSQL资源消耗情况 (55)
5. 测试总结 (61)
1.前言
通过测试Oracle、Infobright、PostgreSQL三种数据库在TPC-H中的性能表现,作为数据仓库选型的决策依据之一。
2.测试方法概述
2.1.测试环境
2.1.1.硬件环境
2.1.2.软件环境
2.2.测试工具
2.2.1.TPC-H介绍
是什么
TPC Benchmark H(TPC-H)是一个决策支持的基准,它由一系列面向商务应用的查询
和并行数据修改组成。
●模拟表
●表之间的关系
2.2.2.Jmeter介绍
拥有如下功能:
单步测试
流程测试
并发测试
2.2.
3.Nmon介绍
服务器资源监控工具(监控内容包括:cpu、磁盘IO等)
2.3.测试方法
参照标准TPC-H方案,针对1GB、10GB、30GB、100GB不同级别的数据量进行测试。
3.测试过程
3.1.测试数据库搭建
3.2.测试脚本准备
3.2.1.DDL脚本
●Infobright
建表语句:
●oracle
建表语句:索引语句:●PostgreSQL
建表语句:索引语句:3.2.2.平面数据文件
初始化数据:./dbgen –vf –s 1
更新数据:./dbgen –vf –U 2 –s 1
3.2.3.查询sql语句
3.3.测试数据规模
3.4.测试工具开发
3.4.1.插入数据功能
1)找到需要删除的数据(平面文件中)
2)解析文件内容并找到要删除表的主键值
3)拼接删除的sql语句进行删除
4)先删除lineitem表的数据、最后删除orders表的数据
5)数据大小不超过总大小的0.1%
3.4.2.删除数据功能
1)找到需要删除的数据(平面文件中)
2)解析文件内容并找到要删除表的主键值
3)拼接删除的sql语句进行删除
4)先删除lineitem表的数据、最后删除orders表的数据
5)数据大小不超过总大小的0.1%
3.5.测试步骤
1)选择一种数据库,通过客户端登陆
2)删表。
如果测试表存在,则删除表
3)创建测试表
4)选择一个数据级的测试数据导入至对应的测试表
5)建立相应的主键、外键约束(infobright不需要创建约束,因为它是列式存储的)
6)记录装载数据的开始、结束时间
7)开始单步顺序执行22条查询语句
8)记录第一条查询开始的时间和最后一条查询结束的时间
9)记录每条语句的响应时间
10)开始并发执行组合1(随机组合的查询语句)的查询
11)开始并发执行组合2(随机组合的查询语句)的查询
12)记录并发执行的开始时间、结束时间
13)记录每条查询语句的响应时间
14)提取nmon的数据,整理出服务器资源消耗的情况
15)根据整理的时间、资源消耗情况绘制出折线图4.测试结果
4.1.数据量级—1GB
4.1.2.串行时间对比
说明:此处纵轴的400秒代表sql执行响应时间至少超过了1800秒
说明:此处纵轴的500秒代表sql执行响应时间至少超过了1800秒bright资源消耗情况
CPU+IO
●内存情况(总内存:32GB,单位:MB)
4.1.
5.PostgreSQL资源消耗情况
●CPU+IO消耗情况
内存消耗情况(总内存:32GB,单位:MB)
4.2.数据量级—10GB
4.2.1.装载时间对比
4.2.2.串行时间对比
说明:此处纵轴的400秒代表sql执行响应时间至少超过了1800秒4.2.3.并行时间对比
说明:此处纵轴的3000秒代表sql执行响应时间至少超过了1小时
说明:此处纵轴的400秒代表sql执行响应时间未知bright资源消耗情况 CPU+IO使用情况
内存使用情况(总内存:32GB,单位:MB)
4.2.
5.PostgreSQL资源消耗情况 CPU+IO资源消耗
内存资源消耗(总内存:32GB,单位:MB)
4.3.数据量级—30GB
4.3.2.串行时间对比
说明:此处纵轴的700秒代表sql执行响应时间至少超过了1800秒
说明:此处纵轴的2000秒代表sql执行响应时间未知
说明:此处纵轴的600秒代表sql执行响应时间未知bright资源消耗情况 CPU+IO资源消耗
内存消耗(总内存:64GB,单位:MB)
4.3.
5.PostgreSQL资源消耗情况 CPU+IO资源消耗
内存资源消耗(总内存:32GB,单位:MB)
4.4.数据量级—100GB
4.4.1.装载时间对比
4.4.2.串行时间对比
说明:此处纵轴的1400秒代表sql执行响应时间至少超过了2000秒4.4.3.并行时间对比
说明:此处纵轴的2000秒代表sql执行响应时间未知。