接口代码开发自己测试完毕后,最后的步骤就是和对端厂商进行压力测试,以便考验代码性能情况(这里面包含了代码,硬件,中间件部署等性能的测试)。这个是最烦人的步骤,尤其是你的对端厂商没有测试环境,更是令人闹心,要等到很晚系统本身不用的时候进行环境切换,如果测试顺利通过还行,如果不能通过要每晚都加班才能进行测试。一般处理并发量比较大的程序,都是通过多路硬件方式并发共同调用一个接口,以达到模拟大规模信息量的处理过程。硬件不是随时都具备的,当然也可以用流行的压测框架,但是部署太复杂。无奈之下,自己只好动手写了简单脚本,这里利用主进程里面启动多线程,每个线程里面循环多次的原理,也就是不断向自己接口端发送数据请求。代码如下:
一、主进程代码:
package bss.intf.thread; /** * 压测小脚本 * @author zhangyp * @version 2009-02-28 * */ public class MainControl { private static long sucessNum = 1; private static long shiNum = 1; public static void main(String[] args) { int i = 0; int num = 100; while (i < num) { i++; ThreadClient client = new ThreadClient(); client.setNum(i); System.out.println("^^^^^^^^^线程" + i + "启动^^^^^^^^^^^^"); client.start();//启动线程 } } } |
二、线程脚本:
package bss.intf.thread; import java.rmi.RemoteException; import crmwsi.crm.WSSPortTypeProxy; /** * @author zhangyp * @version 2009-02-28 */ public class ThreadClient extends Thread { int num; public void setNum(int n) { this.num = n; } //在run里面变动业务处理的逻辑 public void run() { int i = 0; String accNbr = "18920020202"; int accNbrType = 4; String password = "111"; int passwordType = 1; int encryptFlag = 1; String areaCode = "022"; String channelId = "-10000"; String staffCode = "-10000"; String outXml = ""; while (i < 40) { System.out.println("==========第"+ num + "线程里面,第"+ i + "次请求START======="); WSSPortTypeProxy proxy = new WSSPortTypeProxy(); proxy.setEndpoint( "http://136.64.44.237:9010/BssCrmWebService/services/CustomerService_B"); try { outXml = proxy.checkPassword( accNbr, accNbrType, password, passwordType, encryptFlag, areaCode, channelId, staffCode); System.out.println(" outXml=" + outXml); i++; System.out.println( "***********第" + num + "线程里面,第" + i + "次请求END*****"); } catch (RemoteException e) { System.out.println("ERROR"); e.printStackTrace(); } } } public static void main(String[] args) { } } |
说明:这个是模拟客户端调用webservice的时候的测试脚本,效果很好的。大家也可以对run部分进行修改,我曾经测试过自己写的脚本,当线程启动是1000个,每个线程是里面循环100次的时候机器(小型机的配置24个CPU,40G的内存,中间件用的是weblogic8.1,数据库 ORACLE9i)就会被压垮(不是机子挂掉,只是很多队列都塞满了,主机进程有死锁的),这时客户端就会报超时。未优化应用前,只要启动50个线程,每个线程里面循环10次,客户端就会报告超时。
相同硬件效果的对比度:一般来说当启动200个线程循环100次,就相当于一秒钟200次业务处理量,也就是基本上可以硬件上一秒并发200次的效果,这个是做过测试的,我的客户需要一秒处理60次业务量,未优化前一秒30次都达不到,可是优化我先用这个脚本测试通过后,和华为(我的对端厂商,他们一般都用硬件进行压力测)测试后不仅达到他们的要求,而且一秒200次的并发量都没有问题
缺点:没有加载时间,没有统计失败和成功次数,这个用的时候可以自己加上。不能够测试业务处理比较复杂的接口,正在改进!大家有好的想法也可以说下哈~!