Performance

http://www.ha999.com/ha/hasolution.htm 双机热备的实现模式　－　基于共享存储与纯软件方式 　双机热备有两种实现模式，一种是基于共享的存储设备的方式，另一种是没有共享的存储设备的方式，一般称为纯软件方式。 　 基于存储共享的双机热备是双机热备的最标准方案。 　对于这种方式，采用两台（或多台，参见：双机与集群的异同）服务器，使用共享的存储设备（磁盘阵列柜或存储区域网SAN）。两台服务器可以采用互备、主从、并行等不同的方式。在工作过程中，两台服务器将以一个虚拟的IP地址对外提供服务，依工作方式的不同，将服务请求发送给其中一台服务器承担。同时，服务器通过心跳线(目前往往采用建立私有网络的方式)侦测另一台服务器的工作状况。当一台服务器出现故障时，另一台服务器根据心跳侦测的情况做出判断，并进行切换，接管服务。对于用户而言，这一过程是全自动的，在很短时间内完成，从而对业务不会造成影响。由于使用共享的存储设备，因此两台服务器使用的实际上是一样的数据，由双机或集群软件对其进行管理。 　(典型的双机热备产品，参见：LanderCluster集群软件) 　对于纯软件的方式，则是通过支持镜像的双机软件，将数据可以实时复制到另一台服务器上，这样同样的数据就在两台服务器上各存在一份，如果一台服务器出现故障，可以及时切换到另一台服务器。 　对于这种方式的深入分析，请参见：纯软件方式的双机热备方案深入分析 　纯软件方式还有另外一种情况，即服务器只是提供应用服务，而并不保存数据（比如只进行某些计算，做为应用服务器使用）。这种情况下同样也不需要使用共享的存储设备，而可以直接使用双机或集群软件即可。但这种情况其实与镜像无关，只不过是标准的双机热备的一种小的变化。

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使用率等    从用户角度来说， 交互式系统的测试主要关心 响应时间和并发数， 非交互式系统的测试主要关心吞吐量

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%)

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

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

在录制需要登陆的系统时，我们把登陆部分放到 vuser_init 中，把登陆后的操作部分放 到 Action 中，把注销关闭登陆部分放到 vuser_end 中

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

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