Solr初步测试结果

测试环境

OS：Debian Lenny5.0

JRE：1.6.0_24

Tomcat：6.0.29

Solr：1.3.0

 

待测试的Solr服务器部署在测试机192.168.4.160上，目前支持64个core。

core0-core49中index内容相同，大小均为140MB左右，是由280个随机生成的最大为800KB的文本生成索引；

core50-core63中的index内容相同，大小均为220MB左右，是由1000个随机生成的最大为200KB的文本生成索引。

再往后增加core时，生成索引时会生成write.lock文件而出现错误，网上分析原因可能是频繁的提交文档做索引出现找不到段文件。

 

测试工具

使用jmeter进行测试，基本原理是一定数量的线程在一定时间内向solr服务器发送一定数量的随机请求，

查询请求采用Http GET方式，

url基本格式为http://192.168.4.160:8080/solr-cores/core(i)/select/?q=user:user(i)&(xxx)...

有三部分为随机生成，core(i)、user(i)和随机生成的三位字符串。core(i)和user(i)均由jmeter自带的random函数生成，而随机生成的三位字符串则从随机生成的由500行三位字符串组成的csv文件中随机读入。

测试参数主要有线程数量、线程建立的总时间(ramp-up period)、运行测试的次数。

 

测试内容

初步测试内容包括三方面：

1.线程数、总请求数、线程建立时间相同条件下不同core数量下的查询。

线程数为100，总请求数为100*5=500次，线程建立时间为30s和10s。

分别在core数量为8、16、32、50、64时进行查询。

测试结果：

cores	samples	avg	mid	90%_line	min	max	error%	rate	bandwidth
8	500	84	82	154	3	290	0	16.4885899	6089.456365
16	500	89	83	161	2	298	0	16.52182533	6345.876152
32	500	92	94	161	2	267	0	16.56397005	6359.915367
50	500	90	86	165	3	327	0	16.55300271	6245.725866
64	500	78	62	148	3	934	0	16.56945917	4935.588299

注：图表含义说明如下，

Samples：图形报表中的样本数目，总共发送到服务器的请求数目。

Avg：图形报表中的平均值，是总运行时间除以发送到服务器的请求数，单位ms。

Mid：图形报表中的中间值，有一半的响应时间低于该值而另一半高于该值，单位ms。

90%line：90%请求的响应时间比所得数值还要小，单位ms。

Min：服务器响应的最短时间，单位ms。

Max：服务器响应的最长时间单位ms。

Error%：请求的错误百分比。

Rate：图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，单位req/s。

Bandwidth：每秒钟请求的字节数，单位KB/s。

 

平均响应时间在80-100ms左右，core数量不同时平均响应时间变化不明显。

吞吐量在16.5req/s左右，由于总请求数和线程建立时间相同，吞吐量应该基本相同。

 

2.core数、总请求数、线程建立时间相同条件下不同线程数的查询。

core数量为64，总请求数为500次，线程建立时间分别为30s和10s。

分别在线程数为1、10、50、100时进行查询。

测试结果：

threads	samples	avg	mid	90%_line	min	max	error%	rate	bandwidth
1	500	70	58	135	2	221	0	13.49965	4253.99
10	500	78	66	150	2	260	0	16.10306	5242.797
50	500	76	62	148	4	268	0	16.59145	5244.784
100	500	75	62	145	2	264	0	16.49784	5068.4

 

1个线程时平均响应时间为70ms，吞吐量为13.5req/s。

10-100个线程时，平均响应时间为75-80ms，吞吐量在16-16.5req/s左右，变化不明显。

 

3.core数、线程数、线程建立时间相同条件下，不同查询请求数下的查询。

core数量为64，线程数为100，线程建立时间为30s。

分别在总查询请求数为100，500和1000时进行查询。

测试结果：

reqs	samples	avg	mid	90%_line	min	max	error%	rate	bandwidth
100	100	68	59	129	6	182	0	3.346384	989.7179
500	500	72	60	147	2	214	0	16.67445	4875.852
1000	1000	149	121	297	3	1127	0	32.70539	10502.41

 

平均响应时间分别为68ms、72ms、149ms，总查询请求增加，平均响应时间的增大趋势很明显。

吞吐量分别为3.3、16.7、32.7req/s。

 

测试存在的问题

现在存在的几个问题：

1.一台solr服务器支持core的数量和每个core可支持index的大小如何确定。

一台solr服务器支持core的数量是否与生成索引的文本大小有关（生成索引的文本大部分为800KB以内随机大小的文档）；是否与solr服务器上的总索引大小有关（现在当增加core数量并生成索引时会生成write.lock文件而出现错误）。

对于每个core可支持index的大小，需增加index大小进行测试。

还需进一步改进测试方案。

 

2.线程建立时间ramp-up period的设置问题。

参数ramp-up period用于告知jmeter要在多长时间内建立全部的线程。如果未指定ramp-up period，ramp-up period为零，jmeter将立即建立所有线程。假设ramp-up period设置成T秒，全部线程数设置成N个，jmeter将每隔T/N秒建立一个线程。

       因此，如果要使用大量线程的话而ramp-up period较短时，jmeter将会在测试的开始就建立全部线程并立即发送访问请求，服务器将可能过载，jmeter的聚合报告结果中会出现因为多个线程的多次请求访问时间较长而导致错误率Error%急剧上升。

同样，过大的ramp-up period则可能会降低访问峰值的负载，这导致测试结果在不同测试条件下可能变化不明显，比如上述测试结果中不同core数和不同线程数下测试结果变化不是很明显，很可能是由于30s的ramp-up period过长。

 

3.jmeter测试结果和本机内存使用率有很大关系，有时会出现相同测试条件(线程数、总请求数、线程建立时间、core数)下测试结果差别很大的情况。

网上有关资料说如果客户机没有足够的能力来模拟较重的负载，可以使用jmeter的分布式测试功能来通过一个jmeter控制台来远程控制多个jmeter引擎完成测试。