开源高峰论坛门票免费拿:
http://huiyi.csdn.net/tech/view/349
摘录:
Rango-韩*峰(3507499**) 上午 10:44:50
方越:RedHat首席软件工程师,WebService/SOA/ESB/OSGi领域专家,目前活跃在多个有影响力的国际开源项目中
这几个感觉挺牛的,其他人都比较一般
惠新宸:Yaf项目发起人,新浪微博架构师兼首席PHP技术顾问,PHP开发组核心成员, Zend公司顾问
半桶水<shenzhe1**@gmail.com> 上午 10:45:13
鸟哥也去了
Rango-韩*峰(3507499**) 上午 10:45:16
竟然还有鸟哥
。PHP的cli httpserver就是鸟哥搞的
半桶水<shenzhe1**@gmail.com> 上午 10:46:06
嗯,小工具性质的。
回忆未来-向东-Jàck(3726476**) 上午 10:46:44
呵呵,能不能免费听、
Rango-韩*峰(3507499**) 上午 10:46:45
最近看了下他写的代码,swoole也打算做一下http server。要比他做的更专业一些
半桶水<shenzhe1**@gmail.com> 上午 10:50:05
半桶水<shenzhe1**@gmail.com> 上午 10:50:39
会nginx+fpm 要快多少呢?
半桶水<shenzhe1**@gmail.com> 上午 10:51:47
swoole我框架的默认socket引擎。
大力推广swoole中。
Rango-韩*峰(3507499**) 上午 10:51:51
目标是5-10倍。PHP之上来做WebServer的好处非常多
这个可以称之为应用服务器了
Rango-韩*峰(3507499**) 上午 10:53:07
可以做链接池、中间缓存
Rango-韩*峰(3507499**) 上午 10:54:08
淘宝的第一版架构就是 Apache+mod_php+Oracle这样的架构,最后就是应为PHP没办法做连接池,不得不放弃PHP了
半桶水<shenzhe1**@gmail.com> 上午 10:55:03
现在淘宝又在大量应用php了。
Rango-韩*峰(3507499**) 上午 10:55:13
主要在前端
半桶水<shenzhe1**@gmail.com> 上午 10:55:21
嗯
Rango-韩*峰(3507499**) 上午 10:55:24
用PHP的好处很明显,可以节约开发成本
大部分公司都是产品业务驱动技术的。用C++太浪费了,PHP足够用了
非常灵活,开发效率极高
回忆未来-向东-Jàck(3726476**) 上午 10:56:52
一般企业,没几个人访问,性能还成,所以,不错,加上fastcgi。
半桶水<shenzhe1**@gmail.com> 上午 10:57:04
是的。
Rango-韩*峰(3507499**) 上午 10:57:40
PHP的性能从来都不是问题。只有在计算密集的情况下才有问题
半桶水<shenzhe1**@gmail.com> 上午 11:01:44
计算密集会是什么场景呢?
Rango-韩*峰(3507499**) 上午 11:03:03
原来在朋友网的时候遇到有一个场景
腾讯内的一个通用协议解包打包
回忆未来-向东-Jàck(3726476**) 上午 11:04:43
rango,我觉得你有必要做一个c下的长链接Mysql的扩展,
并整成PHP扩展,供PHP做数据源,这样DB性能上可提升,我们就用下,提下意见。
Rango-韩*峰(3507499**) 上午 11:06:05
这个没办法的
受php-fpm或mod_php运行机制的影响
回忆未来-向东-Jàck(3726476**) 上午 11:07:00
也就是扩展是不行了,得独立出来是吧?
令狐雨辰(1020758382) 上午 11:07:11
可以考虑重新实现他的fastcgi协议
在fpm上
做长连接
Rango-韩*峰(3507499**) 上午 11:07:26
对 要启动200个php-fpm进程,就需要创建200个MySQL连接
回忆未来-向东-Jàck(3726476**) 上午 11:08:25
目前腾讯广平也是独立出来的,呵呵。
FastCGI上做,一个fastcgi做20个长连接,10个就200个了,有戏
Rango-韩*峰(3507499**) 上午 11:08:26
做成长连接性能比短连接还要差
短连接请求完是可以释放的,长连接一直保持
回忆未来-向东-Jàck(3726476**) 上午 11:09:03
但这样处理更快,省了连接的耗费。
半桶水<shenzhe1**@gmail.com> 上午 11:09:10
我一直都是用长链接
Rango-韩*峰(3507499**) 上午 11:09:10
如果1台机器到还好了。假如是100台机器,100*200,也就是MySQL需要维持2万个连接
哈哈,MySQL是可耻的per connect per thread
半桶水<shenzhe1**@gmail.com> 上午 11:09:51
mysql也要分布,一台机器不能够
肿么个说法
回忆未来-向东-Jàck(3726476**) 上午 11:10:08
那样整就成了一个sqlrelay了,又回去了。
Rango-韩*峰(3507499**) 上午 11:10:39
淘宝网最早的时候用过sqlrelay,
据说淘宝的创始人就是用了这个玩意
到最后也没搞定它
半桶水<shenzhe1**@gmail.com> 上午 11:11:46
per connect pre thread肿么个说法
Rango-韩*峰(3507499**) 上午 11:12:17
一个连接对应一个线程
半桶水<shenzhe1**@gmail.com> 上午 11:12:50
我觉得蛮好的。
有很弊端?
什么
Rango-韩*峰(3507499**) 上午 11:13:15
当然有问题了
连接多的时候,线程上下文切换非常多
半桶水<shenzhe1**@gmail.com> 上午 11:13:41
我正在搞框架的多线程模块,就想一个连接一个线程呢。
Rango-韩*峰(3507499**) 上午 11:13:42
会占用大部分的CPU时间
半桶水<shenzhe1**@gmail.com> 上午 11:13:49
线程切换不是很轻量级么?
Rango-韩*峰(3507499**) 上午 11:14:22
1000 - 10000 之间问题不大
半桶水<shenzhe1**@gmail.com> 上午 11:14:36
那应该怎么用比较好?
固定一定量的线程,随机分配?
Rango-韩*峰(3507499**) 上午 11:15:11
异步啊
半桶水<shenzhe1**@gmail.com> 上午 11:15:51
噢。
---------------------------------------------------------------------------------
回忆未来-向东-Jàck(3726476**) 上午 11:17:02
我刚问了下腾讯前兄弟,他们是这么做的长连接:
江*海 上午 11:14:15
我们每台机器对一个DB实例来说建立10个长链接(10个进程,每个进程维持一个链接)
如果链接两个Mysql DB实例,则10*2 个链接
回忆未来-向东-Jàck(3726476**) 上午 11:21:38
“假如是100台机器,100*200,也就是MySQL需要维持2万个连接”
100台对一个mysql,那么mysql必然成了瓶颈了。多个几个mysql吧,分散存储。
---------------------------------------------------------------------------------
Rango-韩*峰(3507499**) 上午 11:25:06
业务代码不确定会访问哪个MySQL
有可能需要访问所有MYSQL来取数据
腾讯有TTC的,所以不用担心
Rango-韩*峰(3507499**) 上午 11:26:45
真正的连接池是实现,200个worker进程共用n个连接
---------------------------------------------------------------------------------
半桶水<shenzhe***@gmail.com> 上午 11:27:31
期待swoole的连接池
Rango-韩*峰(3507499**) 上午 11:27:50
这样100台机器就只需要 100*n就可以了
呵呵,这个不是啥新鲜东西了。
回忆未来-向东-Jàck(3726476**) 上午 11:28:12
TTC那是重武器了,呵呵,一般业务其实上不了这个量级的。
Rango-韩*峰(3507499**) 上午 11:28:15
腾讯朋友网的PWS已经搞过的
回忆未来-向东-Jàck(3726476**) 上午 11:30:19
Mysql的长连接这块我觉得有两点注意的,如果长连接及其解决的问题:
1.看请求量了,请求量大才有效果,小请求量区别不大,少了链接的时间。大请求量情况下,长链接主要是解决链接数过多的问题,解决性能问题是其次的,如果有慢查询,长链接也没有用啊。
2.需要注意:要维护长链接的话,必须一直有请求;或者定时mysqlping一下,如果不通,需要再连一下。如果建立了链接,长时间没有请求也会被mysql主动断掉。
Rango-韩*峰(3507499**) 上午 11:33:37
这就是连接池的作用嘛,为啥要提供n个连接,而不是1个呢
1个的话,就会被慢查询搞死。
作者:jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美,在于尽态极妍 | 应用之美,在于药到病除
地址:http://jackxiang.com/post/6483/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明!
最后编辑: jackxiang 编辑于2013-6-25 11:35
评论列表