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

BetonArmEE

原帖由 SuperZ 于 2009-11-17 15:45 发表
即使是重负载程序，也分很多种：计算密集型、I/O密集型、通信密集度？
如果是前两种，就不应该使用多线程。
即使是后一种，也应该考虑通过内存文件来进行进程间通信。

银行后台属于什么类型呢？ ^_^

yulihua49

原帖由 BetonArmEE 于 2009-11-17 12:07 发表


好像没有这类技术需求吧，操作数据库可以不知道表名，操作数据库肯定要预先确定操作的表名，否则有意义吗
表结构都改变了，应用代码肯定要变动的，程序里的数据逻辑集合变动了呀 ^_^

如果这样当然可以PRO*C.
不过由于我们是做TUXEDO服务器，经常的任务是为客户端存取一些数据，只关心这些数据的关联，很多字段是不关心的，取出来交客户端即可。这时增加一些与我无关的字段程序是不用改的。有时增加某些字段的长度，程序也不用改。即使改变的与我有关的字段，改动一点点即可。
有时要向客户端提供通用SQL服务，客户端提交一个语句，有时提交一个关于数据的描述，你临时给他生成一个语句，这时DAU就很有用了，否则这种程序挺难写的。
DAU方便之处，语句基本不用写的，像JAVA的hibenate。
如果数据打包传输，一句话搞定一个结构。可是你要把一个未知的结构映像到数据库，PRO*C干不来。

例如插入一个记录：
事先要准备一个DAU：
DAU_init(&DAU结构，数据库句柄，表名，&结构，模板）；//组合资源。
。。。。处理数据。。。。
ret=DAU_insert(&DAU结构,语句buf）；//一句话，数据就插表里去啦！这样的程序，PRO*C很难写的。

[ 本帖最后由 yulihua49 于 2009-11-17 18:05 编辑 ]

yulihua49

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

可以试试xinetd，为你管理服务进程。

yulihua49

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

任务间通信多，或者要处理连接池什么的，多线程方便些。

BetonArmEE

原帖由 yulihua49 于 2009-11-17 17:43 发表

如果这样当然可以PRO*C.
不过由于我们是做TUXEDO服务器，经常的任务是为客户端存取一些数据，只关心这些数据的关联，很多字段是不关心的，取出来交客户端即可。这时增加一些与我无关的字段程序是不用改的。有 ...

是的是的，像您这样的情况，的确proc做起来很费力，proc最好做一些确定下来的东西，呵呵呵

学习下你的DAU，以后碰到太灵活的场合可以用一下，呵呵呵

BetonArmEE

原帖由 yulihua49 于 2009-11-17 17:54 发表

任务间通信多，或者要处理连接池什么的，多线程方便些。

也就是说任务间通讯量大且复杂，可以考虑多线程，全局变量＋锁用来交换数据比较合适，嗯嗯

system888net

原帖由 BetonArmEE 于 2009-11-17 21:03 发表


也就是说任务间通讯量大且复杂，可以考虑多线程，全局变量＋锁用来交换数据比较合适，嗯嗯

可以采用的方案或方法之一.

system888net

lz可以针对自己的实际情况用多线程或多进程的模型进行初步验证一下,对比出哪个方案更有针对性.

BetonArmEE

听了楼上的各位高手的意见，我觉得还是回归于多进程模型，进程池prefork＋accept锁作为应用服务器通讯接入（前端）
关于锁的选择上，参考了UNP上的测试，既然不用线程就不要链上pthread了，在信号量和文件锁之间选择UNP评价较快的信号量
怎么样？ ^_^

刚刚网上订购了一本《Apache源代码全景分析》，苦读中...

不进一环

多进程更能做出大系统