LCP 1.1 发布,Linux 连接池

zzgang
 zzgang
发布于 2015年11月30日
收藏 38

LCP 1.1 发布, 在1.0版本基础上进行升级,在客户端结束服务调用后,客户端发送关闭原语通知服务端主动关闭连接的情况下,连接状态无法保持,因此增加/etc/primitives.deny配置文件,用于配置对应每种服务的关闭通信原语并和iports.allow配置中的服务对应,配置成功后,客户端将此服务发送的通知关闭原语禁止发送,继续保持连接状态。

LCPLinux Connection Pool的简写,是基于Linux模块开发的线程安全连接池,减少由频繁建立和释放连接带来的系统开销,提升服务响应速度,支持跨语言、多服务的连接池,应用层代码不需要做任何改动,对于某些有状态的连接服务(需要连接认证,例如Mysql连接服务等),需要配置使用具体的IP和端口号来预先派生连接。

别名:(kconnp, Kernel-based Connection Pool)

特性

    1、支持跨语言(PHP,JAVA,Python,C,Perl, ... )之间共享连接

    2、支持多服务(Memcache,Redis,MySQL,Oracle,... )建立连接池

    3、线程安全

工作原理图

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:LCP 1.1 发布,Linux 连接池
加载中

最新评论(24

l
linbojue999
http://kcdfp.tripod.com/
http://kxnfp.tripod.com/
http://kkmfp.tripod.com/
http://kcdfp.tripod.com/home.html
http://kxnfp.tripod.com/home.html
http://kkmfp.tripod.com/home.html
zzgang
zzgang

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。

引用来自“zzgang”的评论

我们环境的统计数据:Service: memcache:*:11211, Mode: POSITIVE, Hits: 5994(92.0%), Misses: 579(8.0%)
Service: mysql:10.51.98.226:3310, Mode: PASSIVE, Hits: 2831(100.0%), Misses: 7(0.0%)
Service: apache:10.51.96.94:80, Mode: PASSIVE, Hits: 8202(100.0%), Misses: 16(0.0%)

引用来自“purple_grape”的评论

我测试用于连接mysql的场合,稍微调整了连接的个数,命中率的确有所提升,但是然并卵。
我感觉还是不太满意,LCP做的仅仅是动态维护对后端的长连接给本地客户端复用,更多是减少客户端的开销,一旦连接数超过连接池,命中率直线下降。
我希望将多个连接合并成一个连接的多个请求,从根本上减轻后端的压力。LCP对于redis、memcache这类并发能力很好的软件,没有实际意义。跟常见的TCP四层反向代理相差太远。

引用来自“zzgang”的评论

连接池最大连接数可以调整的大一些,我不是很赞同你的说法, 我认为基于memcache和redis的连接池的意义会更大,因为连接池从本质上讲是减少了3次握手和系统生成连接的开销,nosql正因为传输数据量小,才使连接时间占的比重更大,这样使用连接池提升效果会更加明显,响应时间会减少,减少响应时间也是很重要的。基于Mysql的连接因为是有状态认证的,所以采用的预派生,从本质上讲不是连接服用,是连接预派生,减少响应等待时间,我认为关系型数据库传输数据量往往比较大的,三次握手时间相在整个通讯时间占的比重更少了。

引用来自“purple_grape”的评论

另外我调整最大连接数,重启LCP后,发现本地tcp closed状态的连接非常之多,少则10k,多达66k,造成应用卡顿,感觉是端口耗尽。平常tcp closed都是个位数,请教一下这是怎么回事?
这个得具体分析一下,QQ: 737781325
purple_grape
purple_grape

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。

引用来自“zzgang”的评论

我们环境的统计数据:Service: memcache:*:11211, Mode: POSITIVE, Hits: 5994(92.0%), Misses: 579(8.0%)
Service: mysql:10.51.98.226:3310, Mode: PASSIVE, Hits: 2831(100.0%), Misses: 7(0.0%)
Service: apache:10.51.96.94:80, Mode: PASSIVE, Hits: 8202(100.0%), Misses: 16(0.0%)

引用来自“purple_grape”的评论

我测试用于连接mysql的场合,稍微调整了连接的个数,命中率的确有所提升,但是然并卵。
我感觉还是不太满意,LCP做的仅仅是动态维护对后端的长连接给本地客户端复用,更多是减少客户端的开销,一旦连接数超过连接池,命中率直线下降。
我希望将多个连接合并成一个连接的多个请求,从根本上减轻后端的压力。LCP对于redis、memcache这类并发能力很好的软件,没有实际意义。跟常见的TCP四层反向代理相差太远。

引用来自“zzgang”的评论

连接池最大连接数可以调整的大一些,我不是很赞同你的说法, 我认为基于memcache和redis的连接池的意义会更大,因为连接池从本质上讲是减少了3次握手和系统生成连接的开销,nosql正因为传输数据量小,才使连接时间占的比重更大,这样使用连接池提升效果会更加明显,响应时间会减少,减少响应时间也是很重要的。基于Mysql的连接因为是有状态认证的,所以采用的预派生,从本质上讲不是连接服用,是连接预派生,减少响应等待时间,我认为关系型数据库传输数据量往往比较大的,三次握手时间相在整个通讯时间占的比重更少了。
另外我调整最大连接数,重启LCP后,发现本地tcp closed状态的连接非常之多,少则10k,多达66k,造成应用卡顿,感觉是端口耗尽。平常tcp closed都是个位数,请教一下这是怎么回事?
zzgang
zzgang

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。

引用来自“zzgang”的评论

我们环境的统计数据:Service: memcache:*:11211, Mode: POSITIVE, Hits: 5994(92.0%), Misses: 579(8.0%)
Service: mysql:10.51.98.226:3310, Mode: PASSIVE, Hits: 2831(100.0%), Misses: 7(0.0%)
Service: apache:10.51.96.94:80, Mode: PASSIVE, Hits: 8202(100.0%), Misses: 16(0.0%)

引用来自“purple_grape”的评论

我测试用于连接mysql的场合,稍微调整了连接的个数,命中率的确有所提升,但是然并卵。
我感觉还是不太满意,LCP做的仅仅是动态维护对后端的长连接给本地客户端复用,更多是减少客户端的开销,一旦连接数超过连接池,命中率直线下降。
我希望将多个连接合并成一个连接的多个请求,从根本上减轻后端的压力。LCP对于redis、memcache这类并发能力很好的软件,没有实际意义。跟常见的TCP四层反向代理相差太远。
连接池最大连接数可以调整的大一些,我不是很赞同你的说法, 我认为基于memcache和redis的连接池的意义会更大,因为连接池从本质上讲是减少了3次握手和系统生成连接的开销,nosql正因为传输数据量小,才使连接时间占的比重更大,这样使用连接池提升效果会更加明显,响应时间会减少,减少响应时间也是很重要的。基于Mysql的连接因为是有状态认证的,所以采用的预派生,从本质上讲不是连接服用,是连接预派生,减少响应等待时间,我认为关系型数据库传输数据量往往比较大的,三次握手时间相在整个通讯时间占的比重更少了。
zzgang
zzgang

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。

引用来自“zzgang”的评论

我们环境的统计数据:Service: memcache:*:11211, Mode: POSITIVE, Hits: 5994(92.0%), Misses: 579(8.0%)
Service: mysql:10.51.98.226:3310, Mode: PASSIVE, Hits: 2831(100.0%), Misses: 7(0.0%)
Service: apache:10.51.96.94:80, Mode: PASSIVE, Hits: 8202(100.0%), Misses: 16(0.0%)

引用来自“purple_grape”的评论

我测试用于连接mysql的场合,稍微调整了连接的个数,命中率的确有所提升,但是然并卵。
我感觉还是不太满意,LCP做的仅仅是动态维护对后端的长连接给本地客户端复用,更多是减少客户端的开销,一旦连接数超过连接池,命中率直线下降。
我希望将多个连接合并成一个连接的多个请求,从根本上减轻后端的压力。LCP对于redis、memcache这类并发能力很好的软件,没有实际意义。跟常见的TCP四层反向代理相差太远。
连接池最大连接数可以调整的大一些,我不是很赞同你的说法, 我认为基于memcache和redis的连接池的意义会更大,因为连接池从本质上讲是减少了3次握手和系统生成连接的开销,nosql正因为传输数据量小,才使连接时间占的比重更大,这样使用连接池提升效果会更加明显,响应时间会减少,减少响应时间也是很重要的。基于Mysql的连接因为是有状态认证的,所以采用的预派生,从本质上讲不是连接服用,是连接预派生,减少响应等待时间,我认为关系型数据库传输数据量往往比较大的,三次握手时间相在整个通讯时间占的比重更少了。
purple_grape
purple_grape

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。

引用来自“zzgang”的评论

我们环境的统计数据:Service: memcache:*:11211, Mode: POSITIVE, Hits: 5994(92.0%), Misses: 579(8.0%)
Service: mysql:10.51.98.226:3310, Mode: PASSIVE, Hits: 2831(100.0%), Misses: 7(0.0%)
Service: apache:10.51.96.94:80, Mode: PASSIVE, Hits: 8202(100.0%), Misses: 16(0.0%)
我测试用于连接mysql的场合,稍微调整了连接的个数,命中率的确有所提升,但是然并卵。
我感觉还是不太满意,LCP做的仅仅是动态维护对后端的长连接给本地客户端复用,更多是减少客户端的开销,一旦连接数超过连接池,命中率直线下降。
我希望将多个连接合并成一个连接的多个请求,从根本上减轻后端的压力。LCP对于redis、memcache这类并发能力很好的软件,没有实际意义。跟常见的TCP四层反向代理相差太远。
zzgang
zzgang

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。
我们环境的统计数据:Service: memcache:*:11211, Mode: POSITIVE, Hits: 5994(92.0%), Misses: 579(8.0%)
Service: mysql:10.51.98.226:3310, Mode: PASSIVE, Hits: 2831(100.0%), Misses: 7(0.0%)
Service: apache:10.51.96.94:80, Mode: PASSIVE, Hits: 8202(100.0%), Misses: 16(0.0%)
zzgang
zzgang
一起试一下memcache的,效果会更好。
zzgang
zzgang
在/etc/iport.allow中配置上mysql的具体的ip地址,这样预派生连接请求
zzgang
zzgang

引用来自“javawiki”的评论

不明觉厉,不知道能不能放生产环境用用

引用来自“zzgang”的评论

可以的,我们已经在生产环境中使用,可以先与生产环境一致的linux内核版本一致的测试环境中测试一下。

引用来自“purple_grape”的评论

简单测试了下,php-fpm连接mysql,命中率在20%-30%左右,不甚理想。如果有更详细的说明文档,针对性的进行优化,那就好了。
memcache:*:11211
mysql:10.51.98.226:3310(S) #mysql 要配置为预派生模式
返回顶部
顶部