|
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-07-05
taolei0628 写道 昨天下载了使用一下，不过这种客户端很多，我不确定是不是你的。
是这个吗？com.danga.MemCached.MemCachedClient 里面使用了socket连接池，对吗？每次交互都单独使用一个连接，我做了一下16个线程的并发压力测试，结果建立了16个服务器连接。 在小数据读写的时候，这样做效率不高。 每个服务器使用连接多了也没有用，毕竟网络带宽就那么多，如果你只使用一个，或者更少量连接，可以合并发送和接收数据。性能会有提高。 我是这个客户端的作者。 连接池默认起32个连接，你也可以通过SockIOPool类的public void setMaxConn(int maxConn)方法设置连接池的大小呀。 |
| 返回顶楼 | |
|
发表时间：2011-07-05
我的意思是说你的机制是每次访问使用单独的连接，在小数据的时候，网络数据包碎片很多，要把请求合并才能更有效利用网络。
使用连接池的机制就算把它调小一样也不会合并数据，只是被阻塞等待可用连接而已，反而会更慢。 我刚测试了一下，16个线程的小数据压力并发，16个连接时每秒13000次，限制到4个连接后就只有每秒7400次了。 |
| 返回顶楼 | |
|
发表时间：2011-07-06
taolei0628 写道 我的意思是说你的机制是每次访问使用单独的连接，在小数据的时候，网络数据包碎片很多，要把请求合并才能更有效利用网络。
使用连接池的机制就算把它调小一样也不会合并数据，只是被阻塞等待可用连接而已，反而会更慢。 我刚测试了一下，16个线程的小数据压力并发，16个连接时每秒13000次，限制到4个连接后就只有每秒7400次了。 memcached协议不支持的话，合并请求无法实现吧。 你有什么实现方法的建议吗？ |
| 返回顶楼 | |
|
发表时间：2011-07-06
taolei0628 写道 我的意思是说你的机制是每次访问使用单独的连接，在小数据的时候，网络数据包碎片很多，要把请求合并才能更有效利用网络。
使用连接池的机制就算把它调小一样也不会合并数据，只是被阻塞等待可用连接而已，反而会更慢。 我刚测试了一下，16个线程的小数据压力并发，16个连接时每秒13000次，限制到4个连接后就只有每秒7400次了。 刚想了一下，其实memcached协议支持multi-get，我们的客户端也实现这个操作的，这相当于也实现了get操作的合并。只是现在协议还没有multi-set |
| 返回顶楼 | |
|
发表时间：2011-07-06
像HTTP pipeline一样，可以连续发set
multi-get可以做成自动合并，如果有进程内并发的get，可以合并到一起。 java这边可以做到这些，memcached那边不知道，如果每个"STORED","NOT_STORED"都单独占一个包的话，java这边无能为力。 |
| 返回顶楼 | |
|
发表时间：2011-07-14
恩，关注pipeline中get的自动合并，能做到这一点应该也会快些。不过这个里面不同key在不同的服务器，做起来可能有点麻烦吧。redis的pipeline挺好用的，不知道为什么memcached本身不支持这个。
|
| 返回顶楼 | |
|
发表时间：2011-07-14
akandfxs 写道 恩，关注pipeline中get的自动合并，能做到这一点应该也会快些。不过这个里面不同key在不同的服务器，做起来可能有点麻烦吧。redis的pipeline挺好用的，不知道为什么memcached本身不支持这个。
memcached支持pipeline的，set的合并spymemcached有做。 |
| 返回顶楼 | |
