Performance

tomcat性能测试工具和调优工具

Server load testing tools     Apache Jakarta JMeter     ab – Apache HTTP server benchmark tool     Many other free and commercial testing tools. Production     Apache 1.3/2.0 mod_jk (1.2)    Java Management Extensions (JMX)    Introscope – Application Server Monitoring

系统的常用性能指标

概括自牛书《软件性能测试-段念》 1.响应时间 2.并发数,有两种意义    a.在指定时间内完成指定业务的并发用户数    b.服务器资源可承受的并发用户数 3.吞吐量    如 点击数/秒,页面数/秒,刷卡交易数/天 4.性能计数器    如内存使用率,CPU使用率等    从用户角度来说, 交互式系统的测试主要关心 响应时间和并发数, 非交互式系统的测试主要关心吞吐量

优化基于tomcat的系统时,可以从哪些方面入手?

Hardware. CPU(s), memory, network IO, and file IO Operating System. Symmetric multiprocessing (SMP) and thread support JVM. Version, tuning memory usage, and tuning garbage collection are important. Tomcat. Later releases are more optimized for performance. If you use JavaServer Pages, Jasper 2 available in Tomcat 4.1 significantly boosts performance. Application. Application design can have the …

优化基于tomcat的系统时,可以从哪些方面入手? Read More »

对性能测试来说,出于什么样的测试目的,就采用什么样的测试方法

总结自 《段念-软件性能测试》 如果是为了验证系统性能是否达到用户需求,就用Performance Testing方法,即模拟真实的生产环境、采用典型的业务场景进行测试,以观察是否达到性能目标 如果是为了调优,则应该采用Load Testing,找到系统的能力极限,确定瓶颈 如果是为了发现缺陷(测试环境里好好的,一上线就出了很多问题),则应该采用Concurrency Testing方法,通过大量并发发现潜在的 死锁、泄漏等问题 如果是为了Scalability,即系统能否能过升级设备的方式满足增长的性能需求,则应该采用 Configuration Testing和Stree Testing(使CPU使用率达到100%)

什么情况下才有必要用 httpd 整合 tomcat

以下是官方文档: Need for cooperation As stated in the Tomcat User’s Guide, Tomcat currently supports three modes of execution.  While it is entirely possible to have Tomcat serve both your static and dynamic document provision needs, there are several reasons why you might  not want want to do this.  With respect to the Apache web server, …

什么情况下才有必要用 httpd 整合 tomcat Read More »

谈谈LoadRunner中Pacing的设置[转]

在 LoadRunner 的运行场景中,有一个不大起眼的设置,可能经常会被很多人忽略,它就是 Pacing 。具体设置方式为: Run-Time settings à General à Pacing ,这个设置的功能从字面上就很容易理解,即在场景的两次迭代 (iteration) 之间,加入一个时间间隔(步进)。设置方法也很简单,这里就不赘述了,我在这里想说明的是,这个设置到底有什么作用?为什么要进行这个设置?说实话,虽然我在以前做过的一些性能测试中,偶尔会对这个步进值进行一些设置,但其实对它的真正含义和作用,我还并不十分清楚。   前段时间,我在对X银行招聘信息系统进行性能测试的时候,发现这个值的设置对于测试的结果有着很大的影响,很遗憾当时没有深入研究这个问题,而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章,读完之后,再用之前我的测试经历加以印证,真有种豁然开朗的感觉。以下就将我的一些体会与大家分享:   通常我们在谈到一个软件的“性能”的时候,首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的: “要求系统支持 100 个并发用户”   看到这样的性能需求,我们往往会不假思索地就在测试场景中设置 100 个用户,让它们同时执行某一个测试脚本,然后观察其操作的响应时间,我们都是这样做的,不是吗?我在实际实施性能测试的过程中,也往往都是这样做的。可惜的是,我们中的大多数人很少去更深入地思考一下其中的奥妙,包括我自己。   事实上,评价一个软件系统的性能,可以从两个不同的视角去看待:客户端视角和服务器视角(也有人把它叫做用户视角和系统视角),与此相对应的,又可以引出两个让初学者很容易混淆的两个概念:“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的,而“每秒请求数”则是从服务器视角去定义的。   因此,上面所描述的做法的局限性就是,它反映的仅仅是客户端的视角。   对于这个世界上的很多事情,变换不同的角度去看它,往往可以有助于我们得到更正确的结论。现在,我们就转换一下角度,以服务器的视角来看看性能需求应该怎么样定义: “要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便,假定在测试脚本中的一个事务仅仅包含一次请求 )   面对以这样方式提出的性能需求,在 LoadRunner 中,我们又该如何去设置它的并发用户数呢?千万不要想当然地以为设置了 100 个并发用户数,它就会每秒向服务器提交 100 个请求,这是两个不同的概念,因为 LoadRunner 模拟客户端向服务器发出请求,必须等待服务器对这个请求做出响应,并且客户端收到这个响应之后,才会重新发出新的请求,而服务器对请求的处理是需要一个时间的。我们换个说法,对于每个虚拟用户来说,它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的,如果我们想要在测试过程中维持一个稳定的每秒请求数( RPS ),只有一个方法,那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题,如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道,实际情况并不是这样,我们通常会对场景设置一个持续运行时间(即多次迭代),通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行,如果不设置步进值的话,那么对于每个虚拟用户来说,每一个发到服务器的请求得到响应之后,会马上发送下一次请求。同时,我们知道, LoadRunner 是以客户端的角度来定义“响应时间”的 ,当客户端请求发出去后, LoadRunner 就开始计算响应时间,一直到它收到服务器端的响应。这个时候问题就产生了:如果此时的服务器端的排队队列已满,服务器资源正处于忙碌的状态,那么该请求会驻留在服务器的线程中,换句话说,这个新产生的请求并不会对服务器端产生真正的负载,但很遗憾的是,该请求的计时器已经启动了,因此我们很容易就可以预见到,这个请求的响应时间会变得很长,甚至可能长到使得该请求由于超时而失败。等到测试结束后,我们查看一下结果,就会发现这样一个很不幸的现象:事务平均响应时间很长,最小响应时间与最大响应时间的差距很大,而这个时候的平均响应时间,其实也就失去了它应有的意义。也就是说,由于客户端发送的请求太快而导致影响了实际的测量结果。   因此,为了解决这个问题, 我们可以在每两个请求之间插入一个间隔时间,这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间,从而提供更符合现实的响应时间。这就是我在文章开头所提到的 …

谈谈LoadRunner中Pacing的设置[转] Read More »

Load Testing v.s. Stress Testing

Load Testing: 不断增加压力,直到超出系统负载。此时的压力,即代表了系统处理能力的极限。比如,我们不断增加并发用户数,当用户数达到100个时,发现事务的响应时间刚好超过了我们要求的10秒,那么我们系统可承受的并发数就是100。  性能调优时往往需要这种测试 Stress Testing:使系统处于饱和状态下,然后观察此时系统的表现。这种测试一般用于观察稳定性:系统在满荷时能否稳定地提供服务

多处理器 跟 服务器性能的关系(仅供参考)

下面的结论没有什么普适性,只是针对我做的某个项目中的IBM PC SERVER和JAVA程序来说的:     经验发现: 服务器端采用多处理器,只能提高可承受的最大线程数,并不能提高事务的响应时间。响应时间主要取决于单个CPU的性能,如主频什么的。      

数据库连接池的连接个数 如何影响 系统性能

    按我个人的体会,连接个数太小会导致赤贫和暴富,个数太大会导致共同贫穷。    连接个数太小  =>  只有部分请求能得到满足,而且连接少,应用服务器的CPU线程也少,应用服务器的响应就快,这些请求就能得到很好的满足,因此它们“暴富”;其他的请求都被冷漠的一口拒绝,它们陷入“赤贫”    连接个数太大  => 多数请求都能得到满足,但响应时间普遍较长 => 共同贫穷