单进程多线程服务器存在这样的弊端

BetonArmEE

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

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

deadlylight

core了一个进程，别的进程还不是没法干活了
结果都一样

zsniper

一套系统是个整体，就算你的底层仍然坚挺，上层逻辑coredump了，这个系统还有意义吗？

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

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

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

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

BetonArmEE

前端通讯收下来递给后端业务逻辑处理程序处理，一组业务逻辑程序竞争获取报文，业务逻辑程序写的人能力参差不齐，如果是单进程多线程的话一个业务逻辑coredump了整个进程也完蛋了，如果是多进程，一个进程coredump了只是一个业务处理进程处理完蛋了，不会影响到其它业务处理程序，我是这个意思

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

BetonArmEE

原帖由 zsniper 于 2009-11-13 15:19 发表
一套系统是个整体，就算你的底层仍然坚挺，上层逻辑coredump了，这个系统还有意义吗？

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

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

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

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

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

BetonArmEE

高性能服务器设计也要考虑后端业务处理逻辑代码结构，比如如果使用多线程，那么要考虑线程安全的数据库操作以及线程异常对全局的影响等，不能一味的比拼谁的服务器框架效率，设计是总体的设计。
就如我最上面提出，用epoll＋异步IO＋业务处理逻辑加载等以多线程组成一个进程，避免了相对低效的IPC，能实现最大效率的服务器框架性能，但是由于业务逻辑处理往往是一组人写的，万一业务逻辑处理崩溃了导致整个进程崩溃，这样的设计肯定不能采用，高端应用中稳定是关键，效率和功能只能排第二。

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

wishel

这是管理问题
能力不够的人就别让他写高性能服务器代码，这不是连累人么

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

UnixStudier

原帖由 wishel 于 2009-11-13 20:39 发表
这是管理问题
能力不够的人就别让他写高性能服务器代码，这不是连累人么

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

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

yulihua49

原帖由 BetonArmEE 于 2009-11-13 14:33 发表
最近搞高性能服务器设计，在unix平台上用c写
设计了在单进程中使用线程池模型的通讯架构，后端装载动态链接库处理业务逻辑，这样避免了进程间通讯相对昂贵的效率
今天突然想到，万一写业务逻辑的程序员的程序 ...

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

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

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

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

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

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

BetonArmEE

原帖由 wishel 于 2009-11-13 20:39 发表
这是管理问题
能力不够的人就别让他写高性能服务器代码，这不是连累人么

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

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

莫非偌大的银行后台你想一个人写？