接口代码开发自己测试完毕后，最后的步骤就是和对端厂商进行压力测试，以便考验代码性能情况（这里面包含了代码，硬件，
中间件部署等性能的测试）。这个是最烦人的步骤，尤其是你的对端厂商没有测试环境，更是令人闹心，要等到很晚系统本身不
用的时候进行环境切换，如果测试顺利通过还行，如果不能通过要每晚都加班才能进行测试。一般处理并发量比较大的程序，都
是通过多路硬件方式并发共同调用一个接口，以达到模拟大规模信息量的处理过程。硬件不是随时都具备的，当然也可以用流行
的压测框架，但是部署太复杂。无奈之下，自己只好动手写了简单脚本，这里利用主进程里面启动多线程，每个线程里面循环多
次的原理，也就是不断向自己接口端发送数据请求。代码如下：
一、主进程代码：
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 utXml = "";
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 {
utXml =
proxy.checkPassword(
accNbr,
accNbrType,
password,
passwordType,
encryptFlag,
areaCode,
channelId,
staffCode);
System.out.println(" utXml=" + 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次的
并发量都没有问题
缺点：没有加载时间，没有统计失败和成功次数，这个用的时候可以自己加上。不能够测试业务处理比较复杂的接口，正在
改进！大家有好的想法也可以说下哈~！
