面向运维的性能测试

每个公司都有自己的基因。做产品起家的,和网络公司不同。对于性能测试,很多的思维还停留在单机时代。于是很多QA就认为,无非就是测试CPU,memory,disk等参数而已。

  但是随着后台的service程序逐渐增多,service的性能测试,和之前测试一个产品,已经有了很多的不同。这里,就谈谈这次性能测试的一些经验。

  其实之前QA已经做过了一些性能测试。但是有一天我们计划购入机器为产品上线做准备,manager问我如何购买机器。我一看module不少,首先就考虑如何分配这些moudule在不同的机器上,以获得最好的性能。于是我要搞清楚每个module的性能瓶颈,到底是cpu bound,还是IO bound,还是memory bound。

  我就建议QA做了这样的测试。测试结果出来了。从结果看来,扫描病毒的模块CPU还是一个瓶颈,毕竟,扫描病毒是一个很耗时的操作。而web service则需要较多的memory。

  我后面关心的就是那么多模块协同工作,谁是最慢的环节。因为我们之前的设计还是考虑的拓展性,所以,对于最慢的环节,通过增加进程数目和增加机器可以改善。

  结果出来了,QA很快就根据他们的性能,给出了一组最小的机器配置列表。哪些module可以放在一起,每个module至少要起几个进程才不至于出现特别慢的module block整个service的效率。这下就简单了。我们可以把它作为一个service组,以后增加机器,就按照这样的配置成倍的增加。

  其实这样的思路,就是现在所谓的SOA运维。别人问你需要多少机器,如何扩容,你给出的不是几台机器,而是以一个最小的service集群组为单位的系统配置。比如说你的service有3个模块,他们的配置可能是

  模块 数目 特征

  A 1 CPU bound
  B 2 IO bound
  C 1 memory bound

  意味这增加一个A和C,需要两个B配合。

  这样,最小的配置就是 1 cpu,2 disk,1 memory,有可能对于到服务器上面,就是

  8core cpu
  15000 PRM SAS disk *2
  32G memory

  有了这样的最小单位,下面才是真正的性能测试环节,我们要知道,这个最小的service单位,能够有多大的吞吐量。

  于是,尽可以多地喂数据,看看输出的效率。这时,我们关心的已经不是cpu、memory、io这些参数了,因为你的最小配置必须是这样的。你可能会浪费CPU,浪费内存,但是没有办法,因为瓶颈在那里,要增加机器提高整体吞吐量,IO是瓶颈。 我们关心的是,整个最小的service集合到底能有多大的吞吐量。如果我要更大的吞吐量,需要多少个这样的service单位。

  这样的性能测试结果,对产品,对运维才是真正有意义的。这就是从整体的角度去考虑一个service产品。而这也为RD后期的开发起了指导意义,哪个模块是重头戏,对整体而言起决定意义。需要重点调优,哪个模块虽然效率很低,但是调优的优先级可以放低。因为他不是关键。

  这里的关键,就在于强调整体测试。而且这个整体是建立在之前模块测试后的模块配比的基础上的。强调最小service集合的测试。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-20 15:15:47

面向运维的性能测试的相关文章

优云,新一代运维PaaS平台

如果需要了解优云全线产品,可登陆官方网站(www.uyun.cn)进行注册,--免费试用SAAS版. 北京广通信达软件股份有限公司创立于2003年,是国内创新型的IT运维软件开发商和运维服务提供商,公司于2015年在全国中小企业股转系统挂牌上市(简称"广通软件",股票代码:833322). 2016年,广通软件率先在业内传播"双态运维"的理念,推出全新一代运维品牌-优云,针对企业级运维市场,创新化的的提出 "软件定义运维"与"运维Paa

优云CMDB专家实践谈:自动化运维的基石CMDB

CMDB是什么? 运维百花齐放繁荣景象的同时,也让碎片化问题产生:每个人都想整合运维平台,但是往往事与愿违. CMDB就像一个人的大脑核心,是一个信息协调库,其存储的资料是协调身体完成各种复杂运动的信息来源.  我心中的CMDB . 碎片整合 面向运维工具的碎片化场景,是盘活整个运维管理的数据核心 . 元数据库 提供运维活动的基础元数据,是唯一可信的运维配置数据服务 . 场景驱动 为运维联动提供数据驱动,可协调工具来完成各类自动化场景    ​自动扩容+自动监控 CMDB如何建设? 痛点现象与对

优云蒋君伟:运维监控大数据的提取与分析

本文内容整理来自[敏捷运维大讲堂]蒋君伟老师的线上直播分享.分别从以下3个维度来分享:1.云时代监控分析的窘境:2.使用标签标记监控数据的维度:3.监控数据应用场景. 云时代监控分析的窘境 在虚拟化与容器技术广泛应用的情况下,运维对象大规模地增长,监控平台每天存储的指标都以亿计,所以监控数据如今已经成了大数据.传统的监控工具在这种场景下,对于数据的提取分析,已经力不从心,反而成为了运维的负担. 我们用一个典型的互联网档案分析应用举例说明: 这个应用支持容灾与负载均衡,它部署在三个数据中心,并同时

如何实现持续交付?听互联网运维杂谈老王怎么说

本文根据12月28日互联网运维杂谈王津银(老王)老师的主题分享整理!小编特别整理出其中精华内容,供大家学习交流. 目录 运维能力是什么 实现交付能力方法 影响持续交付的因素   一个团队和一个公司的价值核心部分就是交付.你交付某种服务/交付产品是运维的价值所在,在你越接近客户的市场里,你的交付输出就越重要. 当然交付delivery和发布release有着很大的不同,在互联网企业里,很强调持续交付的能力,是面向用户的产品和特性交付能力.而发布是面向版本的发布能力,是发布过程一部分.今天不基于持续

运维人要理清运维产品的能力分层体系

一个好的运维产品分层体系,是运维平台理解清晰与否的标志. 建设一个完整的运维平台,绝非一日之功,也非一两个平台所能覆盖,因此我非常喜欢用分层体系来归纳问题.无论是整体运维产品的规划体系,还是自动化体系,还是数据化体系,甚至说CMDB平台的资源体系,都可以用分层归纳总结.以下是我对运维产品整体分层体系的理解: 1.运营能力层 运营能力是体现IT运营价值,把IT的价值和业务场景紧密联系在一起,这些场景和之前谈的运营价值体系是一致的.在运维发展的不同阶段,IT系统的运营价值体现有所不同,IT运营的核心

架构设计 - 自动化运维之架构设计六要点

运维自动化是我们所渴望获得的,但是我们在一味强调自动化能力时,却忽略了影响自动化落地的一个关键因素.那便是跟运维朝夕相处,让人又爱又恨的业务架构. 因为业务架构是决定运维效率和质量的关键因素之一,所以我想跟大家一起聊一下怎么样的架构设计是对运维友好的.结合这些年在腾讯遇到的业务架构和做运维规划时对业务非功能规范的思考,我们可以把面向运维的架构设计分成六大设计要点. 要点一:架构独立 任何架构的产生都是为了满足特定的业务诉求,如果我们在满足业务要求的同时,能够兼顾运维对架构管理的非功能性要求.那么

锐捷网络综合运维中心:面向未来IT治理的“三字经”

在网络服务成为企业发展主要驱动力的今天,日渐庞杂的IT系统使得网络运维工作变得越来越难以驾驭.与此同时,在移动互联.大数据.云计算.虚拟化.区块链等新技术浪潮冲击下,IT运维管理面临着巨大的变革压力.怎样将新技术与IT系统无缝融合,在新业务.新应用上线的同时,保障企业的业务安全与健康运营,是每一位IT运维管理人员面临的巨大挑战. 随着<中华人民共和国网络安全法>的公布,网络的安全运维更成为重中之重的工作.当现代企业面对大量的移动无线设备接入.未授权登录.误操作.高风险漏洞.内外部攻击等一系列风

我们现在在做一个手机游戏,大概一个月之后就能发布,面向国外用户,服务器打算采用aws运维。

问题描述 我们现在在做一个手机游戏,大概一个月之后就能发布,面向国外用户,服务器打算采用aws运维.

面向NFV的运维管理,打造绿色“软”网络

NFV网络功能虚拟化是一场正在发生的网络革命.这场变革借助IT先进技术,将对运营商运营业务产生持久深刻的影响.当前,关于虚拟化和云如何用于电信产业以改善架构与运维TCO有颇多论述.从NFV的应用上看,早期的工作集中在利用虚拟化能力优化硬件,现在则逐渐转向运维. NFV重新定义运维 尽管将某些网络功能虚拟化确实会带来CAPEX方面的节省,然而NFV最大的贡献并不在此,而是它提供了一种实现电信能力的新方式,意义远不止对当前流程的效率优化这样简单. 按照NFV 标准架构,为便于虚拟资源的动态管理,特别