Solr初步测试结果
2011-03-21 15:29
190 查看
测试环境
OS:Debian Lenny5.0JRE: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 |
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 |
吞吐量分别为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引擎完成测试。
相关文章推荐
- MySQL Cluster初步测试结果汇总图示报告 --> 用mysqlslap与sysbench进行测试
- wince6.0 R3 2012年全年更新包WinCEPB60-121231-Product-Update-Rollup-Armv4I.MSI 初步测试结果
- 使用 Hadoop,Nutch ,Hbase,Solr 搭建搜索引擎抓取并测试搜索结果
- 通过psping测试结果,初步判断远端服务器的状态
- perceptivepixel PPI 55"触摸屏初步测试结果
- MySQL Cluster初步测试结果汇总图示报告 --> 用mysqlslap与sysbench进行测试
- 基于Solr的HBase多条件查询测试
- Google测试即输即得:跟随你的输入实时预览搜索结果
- arm端opencv在SBC3730上的测试结果
- 转:LR性能测试结果样例分析 测试结果分析
- solr在使用solrj操作中的各个操作大全(在solrcores中测试)
- solr搜索结果按更新时间与关键字相关度排序
- 【测试体系初步总结】
- BAPI或FM的测试结果提交
- WAYOS一个帐号多次拨号(一号多拨)测试软件,不同地区可能有不同的测试结果
- GROMACS3.2.1在Dual Core的Nocona 2.8G上的测试结果
- 性格色彩测试android程序开发之十--输出结果
- JavaScript中的document.referrer在各种浏览器测试结果
- solr测试项目(上)--基于maven的springmvc环境搭建
- 3月AV-Comparatives杀毒软件测试结果出炉