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

flw

一个小城市商业银行，
还真的以为自己需要“高性能”了？

system888net

   flw大拿,对于这样的讨论应该泼热水啊!你怎么泼冷水啊?

system888net

如果需要高性能处理,只要根据实际情况设计合理,多进程和多线程都是可行的,不会存在说非多进程行不行,也不存在说非多线程不行.

gawk

性能，稳定还真要找个平衡点
多进程多线程也要多试，我现在想把我的一个项目由多线程改成多进程的，遇到一个很怪的问题

dpsuffix

多进程，线程主要消耗在调度上。
所以还是用epol吧l

demaple

我觉得这样设计如何。一个进程fork n个子进程，进行acept，并且在acept上共享内存锁；该父进程监视自己的子进程，防止异常退出。令一个进程fork m工作进程，该父进程监视自己的工作子进程，包括资源占用量异常，交易系统级别异常，发现异常，杀之，重新fork；另外工作子进程与监听子进程通过共享内存和条件变量做IPC通讯。其中工作进程池，需要提前把数据库连接打开，效率应该不错。不过如果真要服务上万个柜员做交易，如果不用中间件，最好多几个服务器专门做长连接转发。

[ 本帖最后由 demaple 于 2009-11-17 13:31 编辑 ]

BetonArmEE

原帖由 system888net 于 2009-11-17 12:31 发表
如果需要高性能处理,只要根据实际情况设计合理,多进程和多线程都是可行的,不会存在说非多进程行不行,也不存在说非多线程不行.

同意
我觉得不用设计的太复杂，像多进程＋多线程虽然性能能提高一些，但是带来设计的复杂性和对系统的不稳定性
其实普通的多进程＋accept锁（进程池）做应用服务器前端应该可以实现一般意义上的高性能了 ^_^

zhoubug

原帖由 demaple 于 2009-11-17 13:28 发表
我觉得这样设计如何。一个进程fork n个子进程，进行acept，并且在acept上共享内存锁；该父进程监视自己的子进程，防止异常退出。令一个进程fork m工作进程，该父进程监视自己的工作子进程，包括资源占用量异常， ...

这个应该没有实际例子，这个思路前部分就是apache的prefork方式 不过后面描述的又扯出一层工作进程，这个就搞的比较复杂拉，在这里你的accept进程不但要接收连接，新连接的句柄属于这个子进程
，你的所有数据收发如果要转给后面的工作进程处理都要通过IPC机制通信，并且存在同步，想一下如果处理逻辑并不复杂，前面既然已经是进程池为何不简单的由子进程进行连接处理。后面的再fork多进程的思路又是混入多线程设计的一个特点 如果把后半部分再做改进的话我觉得可以引入的是单个子进程里可以考虑引入线程池。原因有两个一个是句柄直接可以交由池中空闲线程处理，不用频繁进行IPC数据交换第二是到了单个连接后可以认为出现数据共享的情况比较多，对于多进程虽然有很多ipc机制，比如我们常用到的涉及到指针的数据结构，句柄等都不易使用。或者就直接走prefork的方式就可以。

BetonArmEE

原帖由 demaple 于 2009-11-17 13:28 发表
我觉得这样设计如何。一个进程fork n个子进程，进行acept，并且在acept上共享内存锁；该父进程监视自己的子进程，防止异常退出。令一个进程fork m工作进程，该父进程监视自己的工作子进程，包括资源占用量异常， ...

同意
在accept锁上我有了犹豫，是采用文件锁好，还是线程互斥锁好，还是IPC信号量锁，或者其它？^_^

SuperZ

即使是重负载程序，也分很多种：计算密集型、I/O密集型、通信密集度？
如果是前两种，就不应该使用多线程。
即使是后一种，也应该考虑通过内存文件来进行进程间通信。