使用memcached作为orm缓存实现已经有一段时间了,
今天写了一段测试代码,想看看缓存对系统性能到底有多大提升,结果出乎意料。
测试方法 getById(String id),根据记录id从数据库中查出对象。
1. jdbc版本实现:直接用jdbc执行select方法,代码大致如下
2.memcached实现,使用whalin客户端实现
具体测试就是循环调用 getById方法 取出指定id,测试结果如下:
执行10次:
jdbc耗时:haoshi 31毫秒
memcached耗时:haoshi 109毫秒
执行100次:
jdbc耗时:haoshi 188毫秒
memcached耗时:haoshi 406毫秒
执行1000次:
jdbc耗时:haoshi 1579毫秒
memcached耗时:haoshi 2435毫秒,
memcache和oracle11g都安装在同一IBMx3650服务器上,
测试结果是在另外一台客户机上运行得到的。
改用jcs本地缓存后,测试1000次循环只需要94毫秒。
oracle和memcached在同一台服务器上(生产机),网络状况应该都一样,排除这个差别,
memcached性能表现竟然比直接jdbc访问要差,
由此可见,由于memcached的网络访问方式所限,无法达到很高的响应速度,
使用memcached只能分担数据库压力,对系统性能的改善主要体现在提高系统可伸缩性,而不是提高绝对速度。
而是用本地jvm缓存能极大提高响应速度,但是由于集群支持问题,扩展性有限。
综述,在系统规模不是很大,没有用到集群,memcached占用内存几十兆的情况下,也就是普通的企业应用环境,
memcached并不能很好的发挥其优势,可以考虑用普通的jvm缓存,如jcs等,在系统性能,部署复杂性等方面都较理想。
今天写了一段测试代码,想看看缓存对系统性能到底有多大提升,结果出乎意料。
测试方法 getById(String id),根据记录id从数据库中查出对象。
1. jdbc版本实现:直接用jdbc执行select方法,代码大致如下
PreparedStatement pst = null;
ResultSet set = null;
sql = "select " + TABLECOLUMN + " from " + TABLENAME + " where "
+ IDCOLUMN + " = '"+id+"'";
pst = con.prepareStatement(sql);
set = pst.executeQuery();
BizObject b = helpSetValue(set); //从set到orm业务对象数据拷贝
return b;
2.memcached实现,使用whalin客户端实现
mcc.setCompressEnable( true );
mcc.setCompressThreshold( 64 * 1024 );
BizObject o = (BizObject)mcc.get(mccid);
if (o==null){
o = loadObject(id); //调用jdbc查询,并set到memcached server
}
return o;
具体测试就是循环调用 getById方法 取出指定id,测试结果如下:
执行10次:
jdbc耗时:haoshi 31毫秒
memcached耗时:haoshi 109毫秒
执行100次:
jdbc耗时:haoshi 188毫秒
memcached耗时:haoshi 406毫秒
执行1000次:
jdbc耗时:haoshi 1579毫秒
memcached耗时:haoshi 2435毫秒,
memcache和oracle11g都安装在同一IBMx3650服务器上,
测试结果是在另外一台客户机上运行得到的。
改用jcs本地缓存后,测试1000次循环只需要94毫秒。
oracle和memcached在同一台服务器上(生产机),网络状况应该都一样,排除这个差别,
memcached性能表现竟然比直接jdbc访问要差,
由此可见,由于memcached的网络访问方式所限,无法达到很高的响应速度,
使用memcached只能分担数据库压力,对系统性能的改善主要体现在提高系统可伸缩性,而不是提高绝对速度。
而是用本地jvm缓存能极大提高响应速度,但是由于集群支持问题,扩展性有限。
综述,在系统规模不是很大,没有用到集群,memcached占用内存几十兆的情况下,也就是普通的企业应用环境,
memcached并不能很好的发挥其优势,可以考虑用普通的jvm缓存,如jcs等,在系统性能,部署复杂性等方面都较理想。