spy memcached在压力测试中问题
用URLConnection模拟压力测试 启动250个线程 压我的首页
首页的大多数数据都缓存了 只有两句sql没缓存
参见 http://xuliangyong.iteye.com/blog/274063
一开始测试线程用10 50 100 150一直往上升 后来重启了一次tomcat后
用200个线程来压
开始之后客户端延时突然别的好长,假如150时延时1秒 200时要延时20秒的样子 客户端想死了一样
同时tomcat后台却疯狂的打印sql 靠 疯狂的有点吓人 并且打印一些应该缓存了的sql
这说明memcached没起作用啊 查询全压到mysql上了 难怪延时这么长呢
是什么原因导致memcached失效呢 ?
突然灵光一现 脑子里出现了 spy, 肯定这丫的问题
理了理逻辑 应该是这样
tomcat刚启动 memcached没有缓存任何数据
突然并发的250个请求过来
250个请求同时检查memcached, 问题就出在这儿了。spy memcached是异步的 就是说对它进行读写的时候,它不会检查数据上有没有读写锁,相当与数据库读取的时候不加事务,所以250个请求几乎同时检查时 都是空的 然后转到mysql了
这时这个原因 导致了hibernate疯狂的发起查询
如果上述逻辑是对的 那么tomcat启动完之后 下进行一次查询 在250个线程去压就不会出现问题了
马上去测试一下
刚才gg了一下 memcached是不支持锁的 当初作者为保证memcached的速度 没有使用任何锁机制
这让上面的第二种方法实现起来有些麻烦
codeutil有这方面的经验能否共享一下
这两天考虑了一下这个问题,实际上算是一个伪问题,除了恶意用户之外, 基本上不会出现一上来就200个并发的情况
除非是强奥运门票
延迟初始化,我是通过双重检查mc的数据来得判断是否需要再次查询数据库的,比如:element = methodCache.get(cacheKey);# if (element == null) { # synchronized (this) { # element = methodCache.get(cacheKey); # if (element == null) { # # # # methodCache.put(element); # } # } # } 我觉得使用这种方法即使在tomcat 作sna lb的情况下也只有很少的数据库并发
确实双重检查可以解决这个问题 (双重检查好耳熟,貌似在但例模式里提过,据说是有问题)
只需一次数据库查询 只是开始的249个线程会阻塞一会
在hibernate中这样实现即可
MemcachedCache extends org.hibernate.Cache{ public Object get(String cacheKey){ element = methodCache.get(cacheKey); if (element == null) { synchronized (this) { element = methodCache.get(cacheKey); if (element == null) { methodCache.put(element); } } } }}延迟初始化,我是通过双重检查mc的数据来得判断是否需要再次查询数据库的,比如:element = methodCache.get(cacheKey);# if (element == null) { # synchronized (this) { # element = methodCache.get(cacheKey); # if (element == null) { # # # # methodCache.put(element); # } # } # } 我觉得使用这种方法即使在tomcat 作sna lb的情况下也只有很少的数据库并发
确实双重检查可以解决这个问题 (双重检查好耳熟,貌似在但例模式里提过,据说是有问题)
只需一次数据库查询 只是开始的249个线程会阻塞一会
在hibernate中这样实现即可
MemcachedCache extends org.hibernate.Cache{ public Object get(String cacheKey){ element = methodCache.get(cacheKey); if (element == null) { synchronized (this) { element = methodCache.get(cacheKey); if (element == null) { methodCache.put(element); } } } }}能put一个null到memcached吗?
7 楼 liuye 2009-09-25 ahuaxuan 写道这里面实质上就是两个问题
1预先初始化
2延迟初始化
延迟初始化,我是通过双重检查mc的数据来得判断是否需要再次查询数据库的,比如:
element = methodCache.get(cacheKey);
# if (element == null) {
# synchronized (this) {
# element = methodCache.get(cacheKey);
# if (element == null) {
#
#
#
# methodCache.put(element);
# }
# }
# }
我觉得使用这种方法即使在tomcat 作sna lb的情况下也只有很少的数据库并发
那么当并发突然升高的时候,有250个请求进了第一个if判断,一个线程走过之后,那么第251个线程就不会进第一个if段,也就是说以后就没有锁的问题了,而250个线程进了第一个if之后,他们也只能依次执行,不过如果第一个线程已经返回了结果,那么第2-250个线程不需要进第二个if去查数据库了
而codeutil关于"用户恶意请求导致缓存无法名字"我觉得是没有问题的,不能缓存的名字总能转成能够缓存的名字
而如果用户恶意攻击,这个话题就大了,我想应用可以抗攻击的技术还很少见,我见识浅薄,还没有见过,这种恶意攻击的且在防火墙等其他设施都通过的情况下,基本上就是拼资源,dos攻击一般的路由器都解决了,而ddos攻击能够完全解决的还没有吧,所以恶意攻击可以不放在这里考虑
当然还有一种可能性导致你得响应非常得慢,那就是你最外层得方法上加了事务,详细情况见http://www.iteye.com/topic/231670,当然,如果你测出来,第二组以后得250并发速度变快了那就不是这个问题
能put一个null到memcached吗?