性能测试知多少---并发用户

 在做性能测试的时候,我们常常听到并发用户、响应时间、吞吐量专业术语,也许大家都理解,这里有一个理解的层次与深度概
念。最近有看断念《软件性能详解与案例分析》一书,看了他的讲解,原来我对这些术语的理解还是比较肤浅,其实,这里也主要受制于自己的知识面。所以,再拿
出来与大家重温一下。

 ps:按照惯例先上个图,因为看纯文字的文章比较累!^_^

 

 

并发用户数

  大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作,对系统造成压力,来验证系统的性能(不太标准的解释)。
好多人也简单的把性能测试当成并发测试。那么这个“多用户”和“同时”两个因素缺一不可。只多用户不同时,很难对系统构成压力;没有多个用户,同时的概念
也就自然不存在了

 

并发的两种情况

  一种是严格意义上的并发,即所有的用户在同一时刻做同一件事或操作,这种操作一般指做同一类型的业务。比如,所有用户同一时刻做并发登陆,同一时刻做表单提交。

  另外一种并发是广义范围的并发,这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操作,但是这些请求或都操作可以是相同的,也可以是不同的。比如,在同一时刻有用户在登录,有用户在提交表单。

 

从服务器的角度来看并发

  前面的两种解释都是从用户业务的角度来解释并发的,因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

  如果考虑整个系统运行过程中服务器所承受的压力是这样的:在该系统的运行过程中,把整个运行过程划分为离散的时间点,在每个点上,都有一个“同时向服务端发送请求的客户数”,这个就是所谓的服务器所承受的最大并发访问数。

 

真正意义上的并发不存在

  上面试谈了这么多并发,现在又说真正意义上的并发不存在。何解?学操作系统原理的同学都知道,CPU在一个时间点上只能干一件事儿。为什么我们可以边看电影,边打字,边语音。因为CPU很快很快,他可以处理一下电影,再处理一下打字,再处理一下语音。因为它很快,所以,它可以在多个程序之间快速瞬间的切换,给你造成的假象就是它在同时做这些事情。(现在的双核、四核的CPU另说)

  那么我们的系统在接到用户的请求后也要调用CPU来
完成某些处理,然后返回给用户。那么我们对系统有做并发测试是测什么呢?举个简单的例子。假如有一位神医,他的看病速度非常快,假设他的看病速度是不变
的;然后有一群接待人员来接待看病的客人,有成千上万的病人来看病,接待人员要想各种办法来做好接待工作,使病人更快的看到病。比如,可以事先咨询病人得
的什么病,然后将病人进行分类,比如可以扩大接待室,让更多的病人可以进到医院来看病等。

  神医就是我们的CPU,
接待人员就是我们的系统,病人就用户,我们做性能测试的目的就是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人,医院的看病速度与服务很好。一
下子来十万个病人各种问题就出来了。接待人员的服务态度下降,多余的人员跟本进不到医院去,医院的洗手间不够用,造成病人无法上则所而离开,这些都属于系
统问题。所以,我们一般测试的目的是看医院的接待能力。

 

系统用户数与同时在线人数

  在实际的性能测试中,经常接触到与并发用户相关的概念还有“系统用户数”与“同时在线人数”下面通过一个实例来描述他们之间的差别。

  假设有一个网站,注册用户才能登录使用各种功能,如上传头像,阅读专家文章等。该系统有20万注册用户,这就是说有20万用户可以使用这个网站的所有功能,20万就是这个网站的“系统用户数”,网站有一个在线统计功能,从统计数据中可以看到,同时登录网站的人数的最高记录是2万,就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”

  那么系统的并发用户数是多少呢?2万么?NO!这2万只表示在系统最高峰时有这么多用户登录了网站,并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关,在这2万用户中考察某一个时间点对用户发出请求数,可以会大大缩水。那么,该系统的服务端承受的最大并发访问数是多少呢?这个取决于业务并发用户数和业务场景,一般可以通过服务器日志的分析得到。

 

求并发用户数公式

在实际的性能测试工作中,测试人员一般比较关心的是业务并发用户数,也就是从业务的角度关注应该设置多少个并发数比较合理。

下面找一个典型的上班签到系统,早上8点上班,7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人,平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。

    C=1000/30*5=166.7

C表示平均并发用户数,那么对这个签到系统每分钟的平均在线用户数为166

当然,在性能测试上,任何公式都不是严谨的,最重要的是对系统做出有效正确的分析。 --------------------------

      根据 Teaey 的提醒已经做了改正,计算结果是每分钟,而且是在线用户数,而非并发用户数。

时间: 2024-12-31 02:51:26

性能测试知多少---并发用户的相关文章

性能测试知多少---性能测试流程

性能测试知多少---性能测试流程 看到好多新手,在性能需求模糊的情况下,随便找一个性能测试工具,然后就开始进行性能测试了,在这种情况下得到的性能测试结果很难体现系统真实的能力,或者可能与系统真实的性能相距甚远. 与功能测试相比,性能测试在技术层面具有更大的复杂性.在以往的测试流程中,性能测试只是测试流程的一部分,是系统或验收测试的一个可选项.但随着测试技术的发展.许多公司也单独把性能测试独立出来,建立专门的性能测试小组或团队.那么性能测试在实施的过程中也需要建立独立的流程与规范. 虫师提出了自己

性能测试知多少---系统架构分析

有些事儿一旦放一放就难再拾起来,突然发现<性能测试知多少>这个系列两月没更新,关键时我都不知道啥时候放下的,总容易被各种技术所吸引走,如饥似渴的想学更多的东西,这几天一直有朋友问我为啥不写了,我才意识,事情要一样一样做,我现在要把这个系列完成.   之前有对性能需求进行过分析,那篇主要从项目业务.背景等角度如何抽丝剥茧的将项目的需求抽离出来.在我们进行需求的时候也需要对被测项目的架构有一定的认识,如果不了解被测系统的架构,那么在后期的性能分析与调优阶段将无从下手.   简单系统架构介绍    

性能测试知多少---测试工具介绍

继续这个系列的学习,这一节重点介绍目前流行的性能测试工具以及如何选择适合项目的工具.在此之前,我已经对性能测试工具的原理与架构做了分析. http://www.cnblogs.com/fnng/archive/2012/07/31/2617546.html      性能测试工具的选择与评估                                                 在性能工具原理与架构一章中,我们了解到性能测试工具的原理通常是:通过录制.回放脚本,模拟多用户同时访问被测试系

性能测试知多少---性能分析与调优的原理

最近一直纠结性能分析与调优如何下手,先从硬件开始,还是先从代码或数据库.从操作系统(CPU调度,内存管理,进程调度,磁盘I/O).网络.协议(HTTP, TCP/IP ),还是从应用程序代码,数据库调优,中间件配置等方面入手. 单一个中间件又分web中间件(apache .IIS),应用中间件(tomcat .weblogic .webSphere )等,虽然都是中间件,每一样拎出来往深了学都不是一朝一夕之功.但调优对于每一项的要求又不仅仅是"知道"或"会使用"这么

性能测试知多少---性能需求分析

需求分析是个繁杂过程,它并非我们想象的那么简单,而性能测试需求除了要对系统的业务非常了解,还需要有深厚性能测试知识.才能够挖掘分析出真正的性能需求.   如何获得有效的需求   1.客户方提出 客户方能提出明确的性能需求,说明对方很重视性能测试,这样的企业一般是金融.电信.银行.医疗器械等:他们一般对系统的性能要求非常高,对性能也非常了解.提出需求也比较明确. 曾经有一个银行项目,已经到最后的性能测试极端,因为数据库设计不合理,导致性能出现很大的问题,最终不得不把整合项目 作废,对于这样的项目,

性能测试知多少---性能测试工具原理与架构

在性能测试的学习过程中,坚持思想与工具(分开)并行,当前面世面上的性能测试书籍大多把理论与loadrunner融为一体讲解,这样做是正确的,因为有一些性能名词概念也源于工具.但是,性能测试不是loadrunner,所有的作者也是这么认为的.但他们在讲性能测试的时候讲的就是loadrunner有,只是讲的多少不同罢啦. 你是否觉得我对loadrunner有仇?我之所以将其分开来学,只是希望自己在学习性能测试的时候不要被loadrunner局限了而已.只是觉得在做性能测试时不要带loadrunner

性能测试知多少---性能测试计划

上一章节中我们对性能的需求进行了分析,知道了测试对象,了解了测试需求,那么下面就需要制定一份详细的计划,来规划和指导性能测试工作的进行.为了使你对性能测试计划更清晰明白,这里以测试计划的格式来描述.   一.简介   简介部分就不用过多描述了,无非项目的背景,进行此次性能测试的原因,以及性能测试覆盖的范围等等,几乎所有项目文档都在开端对项目进行简单的阐述.   二.性能测试需求   寻找的被测试对象和压力点 要测试的对象不是凭空想象出来,而是经过分析与系统数据收集得到.下取几个典型的压力点 登录

性能测试解惑之并发压力

前言:之前一直做的软件质量工作,有过一些经验和一些不太成熟的思路,尽管与现在从事产品运营不同,但无论是内涵还是联系,都是非常紧密的,无论如何,我都会继续关注产品的质量问题. 上周跟一朋友阐述性能中并发的概念,叽里咕噜一大通,完了兴致勃勃地让她总结一下,她说了一句:感觉你研究的东西太初级,并发这种概念,太简单,没什么好说的.我听了差点没晕倒,估计她也晕了,真是失败. 并发真的这么简单?性能真的如我们所理解的那样? 也许并不像我们想象的那么简单,之所以我们去探究这些基本的概念,是因为在实际的工作中,

link环境下使用codefirst技术制作的《网盘软件》,并发用户怎么计算?

问题描述 link环境下使用codefirst技术制作的<网盘软件>,并发用户怎么计算? link环境下使用codefirst技术制作的<网盘软件>,并发用户怎么计算?一个"云服务器"支持几个用户? 解决方案 这个没法计算,不同的用户差异很大,要用压力测试工具去测试才知道了.