免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 71550 | 回复: 122

[C] 单进程多线程服务器存在这样的弊端 [复制链接]

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2009-11-13 14:33 |显示全部楼层
本帖最后由 BetonArmEE 于 2013-03-14 20:49 编辑

最近搞高性能服务器设计,在unix平台上用c写
设计了在单进程中使用线程池模型的通讯架构,后端装载动态链接库处理业务逻辑,这样避免了进程间通讯相对昂贵的效率
今天突然想到,万一写业务逻辑的程序员的程序coredump了,会导致整个服务进程崩溃,所有业务处理动态链接库程序跟着倒霉
但是又不甘心转而使用多进程,客户要求服务进程要很高效,IPC要比进程内多线程访问临界区的全局资源要慢很多
大家有什么好的想法?

[ 本帖最后由 BetonArmEE 于 2010-1-20 22:21 编辑 ]

论坛徽章:
0
发表于 2009-11-13 14:46 |显示全部楼层
core了一个进程,别的进程还不是没法干活了
结果都一样

论坛徽章:
0
发表于 2009-11-13 15:19 |显示全部楼层
一套系统是个整体,就算你的底层仍然坚挺,上层逻辑coredump了,这个系统还有意义吗?

coredump和高性能是两码事,coredump也就是说程序还是有严重的错误的,修正错误先~

一个服务器框架是否高效,也就是你说的高性能,不光是系统底层还要看上层逻辑,两者加起来才能说这套系统高效。

当然做底层的人,很多时候为了测试自己的服务器性能,都采用行回显服务器echoserver的业务逻辑来测试,因为这样的业务逻辑很简单,不会影响底层的性能。

[ 本帖最后由 zsniper 于 2009-11-13 15:23 编辑 ]

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2009-11-13 15:33 |显示全部楼层
前端通讯收下来递给后端业务逻辑处理程序处理,一组业务逻辑程序竞争获取报文,业务逻辑程序写的人能力参差不齐,如果是单进程多线程的话一个业务逻辑coredump了整个进程也完蛋了,如果是多进程,一个进程coredump了只是一个业务处理进程处理完蛋了,不会影响到其它业务处理程序,我是这个意思

[ 本帖最后由 BetonArmEE 于 2009-11-13 15:43 编辑 ]

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2009-11-13 15:43 |显示全部楼层
原帖由 zsniper 于 2009-11-13 15:19 发表
一套系统是个整体,就算你的底层仍然坚挺,上层逻辑coredump了,这个系统还有意义吗?

coredump和高性能是两码事,coredump也就是说程序还是有严重的错误的,修正错误先~

一个服务器框架是否高效,也就是 ...


系统平台设计的人只能做到系统平台的高效,业务逻辑处理程序是由一组人写的,写的人能力不等
首先要保证系统稳定,业务处理程序隔离运行,这样的一组设计中选择最高效的服务器框架

我在考虑业务逻辑处理程序尽量对系统平台没有影响,如果前端通讯和业务处理程序放在一个进程里太危险,那么只有分开;多进程会涉及到进程间通讯,一定程度上会影响系统平台效率;业务逻辑处理作为线程也不能放在一个进程里,否则也会互相影响(一个coredump了整个进程也完蛋了),分开么显得进程太多了。不知道一个处理上万个柜员的银行后台能容忍多少个服务进程并发。

[ 本帖最后由 BetonArmEE 于 2009-11-13 15:44 编辑 ]

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2009-11-13 16:40 |显示全部楼层
高性能服务器设计也要考虑后端业务处理逻辑代码结构,比如如果使用多线程,那么要考虑线程安全的数据库操作以及线程异常对全局的影响等,不能一味的比拼谁的服务器框架效率,设计是总体的设计。
就如我最上面提出,用epoll+异步IO+业务处理逻辑加载等以多线程组成一个进程,避免了相对低效的IPC,能实现最大效率的服务器框架性能,但是由于业务逻辑处理往往是一组人写的,万一业务逻辑处理崩溃了导致整个进程崩溃,这样的设计肯定不能采用,高端应用中稳定是关键,效率和功能只能排第二。

[ 本帖最后由 BetonArmEE 于 2009-11-13 16:46 编辑 ]

论坛徽章:
0
发表于 2009-11-13 20:39 |显示全部楼层
这是管理问题
能力不够的人就别让他写高性能服务器代码,这不是连累人么

多线程是做不出多高性能的服务器的,更何况多进程。

论坛徽章:
0
发表于 2009-11-14 10:04 |显示全部楼层
原帖由 wishel 于 2009-11-13 20:39 发表
这是管理问题
能力不够的人就别让他写高性能服务器代码,这不是连累人么

多线程是做不出多高性能的服务器的,更何况多进程。


我觉得这个说得在理,垃圾人你还敢他写服务器程序?

论坛徽章:
15
射手座
日期:2014-11-29 19:22:4915-16赛季CBA联赛之青岛
日期:2017-11-17 13:20:09黑曼巴
日期:2017-07-13 19:13:4715-16赛季CBA联赛之四川
日期:2017-02-07 21:08:572015年亚冠纪念徽章
日期:2015-11-06 12:31:58每日论坛发贴之星
日期:2015-08-04 06:20:00程序设计版块每日发帖之星
日期:2015-08-04 06:20:00程序设计版块每日发帖之星
日期:2015-07-12 22:20:002015亚冠之浦和红钻
日期:2015-07-08 10:10:132015亚冠之大阪钢巴
日期:2015-06-29 11:21:122015亚冠之广州恒大
日期:2015-05-22 21:55:412015年亚洲杯之伊朗
日期:2015-04-10 16:28:25
发表于 2009-11-14 12:57 |显示全部楼层
原帖由 BetonArmEE 于 2009-11-13 14:33 发表
最近搞高性能服务器设计,在unix平台上用c写
设计了在单进程中使用线程池模型的通讯架构,后端装载动态链接库处理业务逻辑,这样避免了进程间通讯相对昂贵的效率
今天突然想到,万一写业务逻辑的程序员的程序 ...

大多数应用服务器不需要进程间通信。或避免进程间通信,利用数据库交换信息。

在这个条件下,如果是UNIX/linux环境,采用多线程没必要。

多线程比多进程性能高?误导!
应该说,多线程比多进程成本低,但性能更低。
在UNIX环境,多进程调度开销比多线程调度开销,没有显著区别,就是说,UNIX进程调度效率是很高的。内存消耗方面,二者只差全局数据区,现在内存都很便宜,服务器内存动辄若干G,根本不是问题。

多进程是立体交通系统,虽然造价高,上坡下坡多耗点油,但是不堵车。
多进程是平面交通系统,造价低,但红绿灯太多,老堵车。
我们现在都开跑车,油(主频)有的是,不怕上坡下坡,就怕堵车。

高性能交易服务器中间件,如TUXEDO,都是主张多进程的。实际测试表明,TUXEDO性能和并发效率是非常高的。
TUXEDO是贝尔实验室的,与UNIX同宗,应该是对UNIX理解最为深刻的,他们的意见应该具有很大的参考意义。

[ 本帖最后由 yulihua49 于 2009-11-14 13:21 编辑 ]

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2009-11-14 22:58 |显示全部楼层
原帖由 wishel 于 2009-11-13 20:39 发表
这是管理问题
能力不够的人就别让他写高性能服务器代码,这不是连累人么

多线程是做不出多高性能的服务器的,更何况多进程。


银行后台系统,几个能力强的人写平台程序,大多数业务强的写交易程序

莫非偌大的银行后台你想一个人写?
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,8.5折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时8.5折扣期:2019年9月30日前


----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP