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个线程去压就不会出现问题了
马上去测试一下

评论

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吗?

6 楼 liuye 2009-09-25  

xly_971223 写道

延迟初始化,我是通过双重检查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吗?

5 楼 xly_971223 2008-11-24  

延迟初始化,我是通过双重检查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); 
                 } 
             } 
         } 
    }
}

4 楼 ahuaxuan 2008-11-24  

这里面实质上就是两个问题
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并发速度变快了那就不是这个问题

3 楼 codeutil 2008-11-23  

是自己用锁来实现限制。
除了恶意用户，在服务器刚重启好的瞬间，也是会出现上百个同样请求的，
处理的不好的话很容易引发雪崩效应，导致服务器始终无法启动。
严重影响系统稳定性和可靠性。

2 楼 xly_971223 2008-11-23  

codeutil 写道

这是一种典型的大并发访问同一个不存在的cache的情形，
因此对于可预先知道的缓存，可以采取在程序启动的时候就生成。
对于这种无法预知key的，以论坛帖子列表为例，可以采取两种策略，
1.第一个发现cache中没有缓存对象时，先放入一个空的临时对象，
比如返回List，可以先生成一个长度为0的ArrayList,同时将生成缓存的操作放到队列中或者由当前线程完成，再将生成的数据替换刚才的临时缓存对象。
这种做法的缺点是，如果生成缓存的时间较长，那么会有一部分请求得到的不是实际数据，影响部分用户体验。且如果当前生成缓存的时候出现异常，需要等刚才的临时缓存失效之后，才会再次触发生成缓存的请求。
优点是编写代码简单，即使该缓存永远无法生成，也不会出发太多的生成缓存的操作。
不怕用户恶意请求来产生过多的无法命中的缓存。
属于牺牲少量用户体验来保障系统的稳定的做法。主要用于重要性较低的业务。

2.用申请锁的方式将生成缓存的操作以同步方式进行，
优点是基本不会出现取到方法1中的那种临时缓存，
缺点是，代码编写稍复杂，生成缓存操作耗时太久或出现问题，或者网络故障等其它原因导致该缓存永远无法生成的时候，
那么每次调用过读取该缓存的请求，都将被拖住，严重的时候整个服务器线程占满被拖垮。
一旦用户恶意请求导致缓存无法名字，服务器很容易被搞挂。

根据实际业务选择吧。

感谢codeutil的回答
刚才gg了一下 memcached是不支持锁的  当初作者为保证memcached的速度 没有使用任何锁机制
这让上面的第二种方法实现起来有些麻烦
codeutil有这方面的经验能否共享一下

这两天考虑了一下这个问题，实际上算是一个伪问题，除了恶意用户之外， 基本上不会出现一上来就200个并发的情况
除非是强奥运门票 

1 楼 codeutil 2008-11-22  

这是一种典型的大并发访问同一个不存在的cache的情形，
因此对于可预先知道的缓存，可以采取在程序启动的时候就生成。
对于这种无法预知key的，以论坛帖子列表为例，可以采取两种策略，
1.第一个发现cache中没有缓存对象时，先放入一个空的临时对象，
比如返回List，可以先生成一个长度为0的ArrayList,同时将生成缓存的操作放到队列中或者由当前线程完成，再将生成的数据替换刚才的临时缓存对象。
这种做法的缺点是，如果生成缓存的时间较长，那么会有一部分请求得到的不是实际数据，影响部分用户体验。且如果当前生成缓存的时候出现异常，需要等刚才的临时缓存失效之后，才会再次触发生成缓存的请求。
优点是编写代码简单，即使该缓存永远无法生成，也不会出发太多的生成缓存的操作。
不怕用户恶意请求来产生过多的无法命中的缓存。
属于牺牲少量用户体验来保障系统的稳定的做法。主要用于重要性较低的业务。

2.用申请锁的方式将生成缓存的操作以同步方式进行，
优点是基本不会出现取到方法1中的那种临时缓存，
缺点是，代码编写稍复杂，生成缓存操作耗时太久或出现问题，或者网络故障等其它原因导致该缓存永远无法生成的时候，
那么每次调用过读取该缓存的请求，都将被拖住，严重的时候整个服务器线程占满被拖垮。
一旦用户恶意请求导致缓存无法名字，服务器很容易被搞挂。

根据实际业务选择吧。