最近做的一个对外提供接口服务的项目,需要保证请求接口在100ms内返回结果。用apacheBench工作做压力测试时,总是报错,网上也一直找不到错误的原因。最后发现是接口中调用了公司的一个框架服务引起的,其他不调该服务的接口都正常。于是写了一个测试接口的工具类。实现的功能,参照apacheBench。可以指定线程数,以及请求数,模拟多个客户端对单一接口服务进行并发的访问。
实现的逻辑比较简单:根据用户输入的线程数,创建多个线程,每个线程串行的发送n/c个请求(其中n为请求数,m为线程数)。并且实时的反馈,完成的请求数,以及成功接收返回结果的请求数量。
主要代码如下:
HttpExecutor.java
package com.bmlcz.test.helper;
import com.bmlcz.support.http.HttpUtils;
/**
* @ClassName: HttpExecutor
* @Description: TODO(这里用一句话描述这个类的作用)
*/
public class HttpExecutor implements Runnable {
public static interface HttpRequestListener {
public void report(int index, int count, String result);
// public void finish();
}
private HttpRequestListener httpListener;
private int reqCount;
private String requestURL;
public HttpExecutor(String url, int num, HttpRequestListener listener) {
super();
this.reqCount = num;
this.requestURL = url;
this.httpListener = listener;
}
@Override
public void run() {
for (int i = 0; i < reqCount; i++) {
String result = HttpUtils.get(requestURL);
httpListener.report(i, reqCount, result);
}
// httpListener.finish();
}
}
HttpScheduler.java
package com.bmlcz.test.helper;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import com.bmlcz.support.util.StringUtils;
import com.bmlcz.test.helper.HttpExecutor.HttpRequestListener;
/**
* @ClassName: HttpScheduler
* @Description: TODO(这里用一句话描述这个类的作用)
*/
public class HttpScheduler {
private static HttpScheduler INSTANCE;
private static List<Thread> executors = new ArrayList<Thread>();
/*
* 完成请求数
*/
private AtomicInteger finishRequestCount = new AtomicInteger();
/**
* 成功请求数
*/
private AtomicInteger successRequestCount = new AtomicInteger();
/**
* 完成所有请求的线程数
*/
private AtomicInteger finishRequestThreadCount = new AtomicInteger();
/**
* 标记scheduler是否被锁定
*/
private volatile boolean lock = false;
private int threadCount;
private int requestCount;
private String requestUrl;
private HttpScheduler() {
}
private void init(String url, int thrdCnt, int reqCnt) {
this.threadCount = thrdCnt > reqCnt ? reqCnt : thrdCnt;
this.requestCount = reqCnt;
this.requestUrl = url;
finishRequestCount.set(0);
successRequestCount.set(0);
finishRequestThreadCount.set(0);
executors.clear();
int avaCount = requestCount / threadCount;
int num;
for (int i = 0; i < threadCount; i++) {
if (threadCount - 1 == i) {
num = avaCount + requestCount % threadCount;
} else {
num = avaCount;
}
HttpExecutor executor = new HttpExecutor(requestUrl, num, new HttpRequestListener() {
@Override
public void report(int index, int count, String result) {
finishRequestCount.incrementAndGet();
if (StringUtils.notEmpty(result)) {
successRequestCount.incrementAndGet();
}
if (index == count - 1) {// 该线程完成所有请求
int cnt = finishRequestThreadCount.incrementAndGet();
if (cnt == threadCount) {
lock = false;
}
}
}
});
executors.add(new Thread(executor));
}
}
public static HttpScheduler getInstance(String url, int thrdCnt, int reqCnt) throws IllegalStateException {
if (null == INSTANCE) {
synchronized (HttpScheduler.class) {
if (null == INSTANCE) {
INSTANCE = new HttpScheduler();
}
}
}
if (!INSTANCE.lock) {
throw new IllegalStateException("scheduler is lock.");
}
synchronized (INSTANCE) {
INSTANCE.init(url, thrdCnt, reqCnt);
}
return INSTANCE;
}
public void start() throws IllegalStateException {
if (!lock) {
throw new IllegalStateException("scheduler is lock.");
}
synchronized (this) {
if (!lock) {
throw new IllegalStateException("scheduler is lock.");
}
lock = true;
}
for (Thread thread : executors) {
thread.start();
}
}
public static class HttpScheduleStatistics {
private int finishCount;
private int successCount;
private int finishThreadCount;
public HttpScheduleStatistics(int finishCount, int successCount, int finishThreadCount) {
this.finishCount = finishCount;
this.successCount = successCount;
this.finishThreadCount = finishThreadCount;
}
public int getFinishCount() {
return finishCount;
}
public void setFinishCount(int finishCount) {
this.finishCount = finishCount;
}
public int getSuccessCount() {
return successCount;
}
public void setSuccessCount(int successCount) {
this.successCount = successCount;
}
public int getFinishThreadCount() {
return finishThreadCount;
}
public void setFinishThreadCount(int finishThreadCount) {
this.finishThreadCount = finishThreadCount;
}
}
public HttpScheduleStatistics getStatistics() {
return new HttpScheduleStatistics(finishRequestCount.get(), successRequestCount.get(),
finishRequestThreadCount.get());
}
public static class IllegalStateException extends Exception {
private static final long serialVersionUID = -9131005022129607733L;
public IllegalStateException(String msg) {
super(msg);
}
}
}
测试时,发现,当线程数接近数据库测试的maxActivie(线程池最大连接数)时,已经请求成功数已经少于完成的请求数。当线程数是maxActive的10倍时,请求成功数基本在完成请求数的0.68倍左右。最后,适当的调大了context.xml中maxActive与maxIdle(最大空闲的线程数)的值。
maxIdle值与maxActive值应配置的接近。因为,当连接数超过maxIdle值后,刚刚使用完的连接(刚刚空闲下来)会立即被销毁。而不是我想要的空闲M秒后再销毁起一个缓冲作用。这一点DBCP做的可能与你想像的不一样。若maxIdle应与maxActive相差较大,在高负载的系统中会导致频繁的创建、销毁连接,连接数在maxIdle与maxActive间快速频繁波动,这不是我想要的。高负载的系统的maxIdle值可以设置为与maxActive相同或设置为-1(-1表示不限制),让连接数量在minIdle与maxIdle间缓冲慢速波动。