免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: zhitenglin
打印 上一主题 下一主题

Unix C 网络多进程框架设计 [复制链接]

论坛徽章:
0
21 [报告]
发表于 2010-02-01 22:30 |只看该作者
这样设计的话,进程上下文切换的耗费就是个大问题.

论坛徽章:
0
22 [报告]
发表于 2010-02-02 18:55 |只看该作者
单服务器1w的并发量肯定可以,单进程epoll就行了,后台工作进程可以是多个,中间用消息队列通信。
服务器架 ...
nanduo 发表于 2010-01-17 21:48



    厄,epoll只有linux才有,其它Unix系统上是没有的。不过你的思路是对的,在其它unix系统上也有类似epoll的解决方案,单进程搞定1W并发量是没有问题的,和后台处理进程打交道,
消息队列是一个方案,UNIX共享内存也可以考虑。

论坛徽章:
0
23 [报告]
发表于 2010-02-02 22:16 |只看该作者
监听/应答进程使用多线程阻塞,写入上行报文共享内存区,并从下行报文共享内存区中读取结果回传给客户端。
...
proge 发表于 2010-02-01 19:27



多线程?基于Unix系统的特性,看了网上大量的讨论,感觉使用进程比使用线程要方便一点,毕竟线程在控制锁方面比较麻烦,本人不太善长,呵呵。
而且进程也是使用了copy-on-write的技术,进程资源不比线程资源耗太多。而且考虑到提供给开发用户的开发模式,进程比较好控制。

工作进程一般是CPU数目的2倍?这个是不是有道理的?有时候会看见这样的一些讨论,是不是这样子会比较调度合理,从CPU角度?

论坛徽章:
0
24 [报告]
发表于 2010-02-02 22:22 |只看该作者
我自己写了一个叫SunLink的通讯中间件,是按照第一种方式实现的,现在是公司产品的核心组件,能支持较大并 ...
sunlan 发表于 2010-02-01 21:30



SunLink大概的应用规模是怎么样的?我现在这个银行系统的中间高度核心部分,我觉得有问题,就算撑得起业务处理,那也是硬件的帮助。。。
而且我也发现了里面一个比较搞笑的bug。。。

sunlan 好像是版主也,有空交流一下经验啊。。。。呵呵。。。最好能提供一下高手的代码,分享一下,呵呵。。。我也打算写完了,就搞到开源项目那里。。。。

论坛徽章:
0
25 [报告]
发表于 2010-02-02 22:29 |只看该作者
这样设计的话,进程上下文切换的耗费就是个大问题.
iamxmz 发表于 2010-02-01 22:30



如果一个请求要处理200ms,一秒来1000个请求,那就是说每秒得产生和消亡1000个进程,这也是相当费系统资源的。。。
预起进程,是一种折中的方法。。。。
但是如果一个请求要处理10s,一秒来100个请求,那么不断fork子进程进行处理,倒是个好办法,处理也简单一些。。。

这得看业务逻辑,现在就是想找一个两种情况都适应的开发模式。。。

论坛徽章:
0
26 [报告]
发表于 2010-02-02 22:37 |只看该作者
厄,epoll只有linux才有,其它Unix系统上是没有的。不过你的思路是对的,在其它unix系统上也有类 ...
tblue7 发表于 2010-02-02 18:55



消息队列,共享内存这些我尽量少用,毕竟系统资源有限,一般是设计成服务器,然后一批相同的进程共享相同的key。。。。

打算使用select算了,虽然都是基于c语言的操作系统,可是各个unix linux系统,各个平台的api都不太标准。。。
就算使用了标准的api,有时候参数也不一样。。。想让那个可怜的cc编译器,编过去,还真不容易。。。
跨平台开发还真不容易啊,想写个程序一下子跑在各个平台下面,得费不少劲,一气一下还真不如使用windows开发。。。唉,杯具啊。。。。

论坛徽章:
0
27 [报告]
发表于 2010-02-03 09:24 |只看该作者
消息队列,共享内存这些我尽量少用,毕竟系统资源有限,一般是设计成服务器,然后一批相同的进程共享 ...
zhitenglin 发表于 2010-02-02 22:37


呵呵,可以理解。
不过我觉得跨平台开发,首先要封装一套平台无关的API,不然以后代码ifdef的地方太多,很难维护的:)

论坛徽章:
4
2015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:56:11IT运维版块每日发帖之星
日期:2016-08-11 06:20:00IT运维版块每日发帖之星
日期:2016-08-15 06:20:00
28 [报告]
发表于 2010-02-03 09:24 |只看该作者
要支持大并发连接,采用传统的select或poll方式很难做到。
一个连接由一个进程或线程来服务,也是有问题的。
要支持大并发连接,应该采用epoll之类的方式。
可以采用异步IO库libevent加线程池的方式。缺点是和传统的sokcket编程模式有较大差别。

论坛徽章:
0
29 [报告]
发表于 2010-02-03 10:11 |只看该作者
回复 24# zhitenglin


SunLink通讯中间件本身的效率非常高,如果空载测试(即服务端仅作通讯响应、不做业务处理)能达到很高的并发度和处理能力,但这个还受到服务器硬件配置的限制。一台机器能同时并发多少个进程其实和是否是由中间件调用并无直接关联,你主要做个小测试,看能同时fork出多少个进程就知道了。关键是当服务程序要进行数据库访问等操作时,你的系统能支持多少笔业务并发,这个值绝对远小于中间件能处理的通讯请求,可以说根本就不是在一个数量级上。举个例子,在HP DL380G6服务器上,通讯中间件的空载处理能力能达到10万次响应/秒,但典型交易可能只能达到6000笔/秒。所以在我做的通讯中间件中带有交易流量管理,可以控制不同类型的业务在同一时间点上的并发数量,并且针对不同的软硬件配置设置不同的参数。

论坛徽章:
0
30 [报告]
发表于 2010-02-03 10:31 |只看该作者
算了,要不还是用Tuxedo吧。如果实在要写,试试用ACE吧。
以前我不是做金融行业的,现在搞金融行业,发现这个行业好落后……也许是我在的公司不好吧。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

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

清除 Cookies - ChinaUnix - Archiver - WAP - TOP