Month: July 2008

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

摘自《withou ejb》 1.不必要的数据库访问 2.在JAVA对象和XML文档之间进行过度的转换 3.过多地进行远程调用

Runtime lRuntime = Runtime.getRuntime(); out.println("Free  Memory: "+lRuntime.freeMemory()/1024/1024+"M");  //已分配的空间中未被使用的部分 out.println("Max   Memory: "+lRuntime.maxMemory()/1024/1024+"M"); //最大可分配的空间 out.println("Total Memory: "+lRuntime.totalMemory()/1024/1024+"M"); //已分配的空间

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

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

在 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 »

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

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