最新消息:欢迎光临!

【转】由memcached使用不当而引发性能问题的两个经验总结

服务器架构 findever 1761浏览 0评论

1、key-value的限制

缓存的key有长度限制,key的组成有特定字符的限制。

缓存的value必须可以序列化,且缓存的单一value容量有大小限制,对于可序列化的value,应该想方设法尽量规避某些特定数据结构,比如Hashtable,DataTable这些内部其实非常非常之复杂的数据结构。对于读频繁的操作来说,每次序列化和反序列化复杂数据结构的开销可想而知。

如果连分布式缓存的key和value(尤其是value)的一般限制都搞错了,那么使用缓存的后果很可能只是白白增加了网络IO及序列化、反序列化的开销,对系统性能提升当然是巨大的反作用。

2、小心Memcached的.net客户端的误用

这一点隐藏的也比较深,下面以应用广泛的EnyimMemcached为例来简单说明。

通常我们使用的客户端每次实例化MemcachedClient对象内部都会初始化一个客户端对象池(TCP连接池,客户端命名为ServerPool)。所谓TCP连接池就是将创建好的TCP连接(连接数通常按照配置来,生产环境的配置不会小于两位数)初始化放在容器内,客户端调用的时候可以直接拿出已经存在的TCP连接来用,这样可以省去实时打开TCP连接的开销。

因为有人喜欢using一下(当然包括楼主自己了),一看到MemcachedClient是继承自IDisposable的,必须用using啊,然后就要new一个MemcachedClient对象,这样客户端内部也就不得不再初始化一个TCP连接池。如果某个使用缓存的服务方法调用频繁,很快你就会发现系统CPU飙升,页面打开速度奇慢,直至不能正常访问。

我们知道,分布式缓存系统都有一个TCP连接上限的设置,无论如何,超过这个上限都有可能引发连环反应,这种反应毫无疑问是不良副作用。

所以如果我们误用MemcachedClient,每次都new一个对象,那么高并发情况下效果就非常惨了,一方面web服务器因为TCP连接过多无法正常访问,另一方面Memcached服务器也因为连接太多负载过重而性能变得极差,依赖Memcached的服务很可能短时间内只接收到超时响应。

解决方案无比简单,配置合适的TCP连接数,MemcachedClient对象单例即可。

最后还要重申选择使用缓存的业务场景的重要性。这一点真的无法说透,但是根据一些已有经验,可以提炼出两条比较通用的缓存准则:

1、写频繁的数据不适合缓存;

2、读频繁而写不频繁的数据适合缓存。

果然正确的话都是废话,上面两条等于没说。

怕你们说无聊,还是要奉献两条自己使用缓存的主要准则,当然只是自己一家之言经验之谈,不可全信,切记,否则被总监劝退老子概不负责:

1、适合缓存的数据通常应该对外公开供(所有)人调用,私有的数据缓存多数情况下是没有意义的;

2、对准确性、实时性、安全性等要求极高的业务数据,你的数据可能不适合缓存。

顺带再提一下web开发中的性能问题。据说如果一个网站有性能问题,那么它一定会出现性能问题。数据库、缓存、消息队列、各种框架、com组件等等等等,这些web开发中的标配,有哪个使用不当不会引发系统的性能问题呢?甚至大家习以为常的拼接字符串在特定条件下都会造成系统崩溃。我们也知道生产环境就像国际政治一样错综复杂波谲云诡,测试环境、UAT环境通过并不能保证系统诸事无虞,应该时刻认识到coding无小事,否则一个疏忽就有可能造成生产环境发生悲剧乃至惨剧。

转自:http://www.cnblogs.com/jeffwongishandsome/p/3331733.html

转载请注明:Findever » 【转】由memcached使用不当而引发性能问题的两个经验总结

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址