当前位置: 技术问答>linux和unix
哪个方案更好?
来源: 互联网 发布时间:2017-03-11
本文导语: 我想知道pthread_create的使用场景。 我需要写一个服务,特耗cpu,每个请求和回复都是几十字节,但是需要单核运算0.2s左右。 方案1:主线程负责io,每来一个任务,调用pthread_create创建新线程执行。 方案2: 主线程...
我想知道pthread_create的使用场景。
我需要写一个服务,特耗cpu,每个请求和回复都是几十字节,但是需要单核运算0.2s左右。
方案1:主线程负责io,每来一个任务,调用pthread_create创建新线程执行。
方案2:
主线程负责io,每来一个任务,放入一个任务队列,通知等待线程。
其它线程负责wait队列,一旦有任务来,立刻争抢,好处是只需要初始化时调用几次pthread_create。
我不太清除pthread_create的效率,相比于任务0.2秒是否可以忽略?
哪个方案更好呢?谢谢大家!
我需要写一个服务,特耗cpu,每个请求和回复都是几十字节,但是需要单核运算0.2s左右。
方案1:主线程负责io,每来一个任务,调用pthread_create创建新线程执行。
方案2:
主线程负责io,每来一个任务,放入一个任务队列,通知等待线程。
其它线程负责wait队列,一旦有任务来,立刻争抢,好处是只需要初始化时调用几次pthread_create。
我不太清除pthread_create的效率,相比于任务0.2秒是否可以忽略?
哪个方案更好呢?谢谢大家!
|
线程池/进程池是必然的设计.
---------------------------------------------
线程池(稳定性差, 不一定能发挥多核优势(主动控制除外:pthread_setaffinity_np), 锁多):
实现方法:
1, 主线程EPOLL负责I/O与状态机维护, 将任务通过(管道1字节事件与任务队列,PS:一个线程一份)推向压力最小线程. 同时监听(一个管道与应答队列), 该管道用于接受线程池的应答通知.
2, 线程池负责任务处理, 将处理结果放入主线程自己的应答队列,写主线程的管道1字节通知. 主线程便可根据应答所属Client变更该Client状态运行状态机以便将应答送回Client,继续处理下一次顺序到来的请求.
----------------------------------------------
进程池(稳定性强,多进程+多线程, 充分发挥多核优势):
实现方法:
1, 父子进程socketpair长连接.
2, 父进程EPOLL负责I/O与状态机维护, 将请求推向堆积请求最少的进程, 直接sockpair(unix domain socket)推过去即可, 更改该Client状态为等待应答处理的实现细节不必多说, 没这方面的思想也可以写, 架构难看点.
3, 子进程作为一个稳定的个体, 增强其并发能力采取主线程从sockpair读取任务, 并将任务分发到线程池的架构, 其实现方式和上面线程池架构完全相同, 只不过此时相当于客户端只有一个, 就是父进程。
------------------------------------------------
架构1保证单一Client不会因为线程池并发处理请求乱序, 这是状态机停等的机制保证的。
架构2由父进程保证单一Clinet的状态机保证包不乱序,子进程采取线程池并发, 大大提升整体性能。
---------------------------------------------
线程池(稳定性差, 不一定能发挥多核优势(主动控制除外:pthread_setaffinity_np), 锁多):
实现方法:
1, 主线程EPOLL负责I/O与状态机维护, 将任务通过(管道1字节事件与任务队列,PS:一个线程一份)推向压力最小线程. 同时监听(一个管道与应答队列), 该管道用于接受线程池的应答通知.
2, 线程池负责任务处理, 将处理结果放入主线程自己的应答队列,写主线程的管道1字节通知. 主线程便可根据应答所属Client变更该Client状态运行状态机以便将应答送回Client,继续处理下一次顺序到来的请求.
----------------------------------------------
进程池(稳定性强,多进程+多线程, 充分发挥多核优势):
实现方法:
1, 父子进程socketpair长连接.
2, 父进程EPOLL负责I/O与状态机维护, 将请求推向堆积请求最少的进程, 直接sockpair(unix domain socket)推过去即可, 更改该Client状态为等待应答处理的实现细节不必多说, 没这方面的思想也可以写, 架构难看点.
3, 子进程作为一个稳定的个体, 增强其并发能力采取主线程从sockpair读取任务, 并将任务分发到线程池的架构, 其实现方式和上面线程池架构完全相同, 只不过此时相当于客户端只有一个, 就是父进程。
------------------------------------------------
架构1保证单一Client不会因为线程池并发处理请求乱序, 这是状态机停等的机制保证的。
架构2由父进程保证单一Clinet的状态机保证包不乱序,子进程采取线程池并发, 大大提升整体性能。
|
1,EPOLLIN和EPOLLOUT必须可以同时设置.
2,0.2秒还好, 不算长了.
3,EPOLLIN是为了监听可读, EPOLLOUT是为了监听可写, 初学者对EPOLLOUT怎么用很疑惑, 其发生条件为: 只要网卡的写缓冲不满就会触发, 其设置的前提有两种:
1, 希望通过OUT事件维护状态机, 也就是在IN事件没注册的情况下, 始终保持FD事件触发做一些异步化的处理机制. 在这方面, 看一下Lighttpd/Nginx/Jabberd源码都会有所收获,不过相信还是会经历艰难困苦的。
2,最单纯的,因为某次write的时候返回值小于请求值,甚至直接返回-1且errno==EAGAIN。在真正的服务器开发中,这种情况将会把未发出的数据缓存到BUFFER里并注册OUT事件,以便在下次OUT事件触发时将BUFFER数据写出。 (如果BUFFER非空时希望write新数据,请直接将数据追加到BUFFER末尾待OUT事件触发继续写出,直到BUFFER完全写出即可取消OUT事件)
------------------------------
我上面一直提状态机和异步化,还提到怎么做到包不乱序,这都是服务端开发高级的程序微架构思维,必须自己去阅读开源代码积累一下,直接给你描述也不好理解,简单的说就是:
每个客户端维护一个状态,比如可以设计为:
1,等待请求
2,处理请求
3,准备应答
3,开始应答
其中1和4可能只牵扯到红色字体的2,而2和3一般会牵扯到红色字体的1,其目的即借助OUT事件延续事件的触发以便实现完全异步的插件回调机制。
而客户端的每个状态将会要求注册IN/OUT事件,并且每个状态下对IN/OUT事件有各自的处理方法,并在自己状态处理完成后设置进入下一个状态并由下一个状态处理机注册自己所需的IN/OUT事件。
2,0.2秒还好, 不算长了.
3,EPOLLIN是为了监听可读, EPOLLOUT是为了监听可写, 初学者对EPOLLOUT怎么用很疑惑, 其发生条件为: 只要网卡的写缓冲不满就会触发, 其设置的前提有两种:
1, 希望通过OUT事件维护状态机, 也就是在IN事件没注册的情况下, 始终保持FD事件触发做一些异步化的处理机制. 在这方面, 看一下Lighttpd/Nginx/Jabberd源码都会有所收获,不过相信还是会经历艰难困苦的。
2,最单纯的,因为某次write的时候返回值小于请求值,甚至直接返回-1且errno==EAGAIN。在真正的服务器开发中,这种情况将会把未发出的数据缓存到BUFFER里并注册OUT事件,以便在下次OUT事件触发时将BUFFER数据写出。 (如果BUFFER非空时希望write新数据,请直接将数据追加到BUFFER末尾待OUT事件触发继续写出,直到BUFFER完全写出即可取消OUT事件)
------------------------------
我上面一直提状态机和异步化,还提到怎么做到包不乱序,这都是服务端开发高级的程序微架构思维,必须自己去阅读开源代码积累一下,直接给你描述也不好理解,简单的说就是:
每个客户端维护一个状态,比如可以设计为:
1,等待请求
2,处理请求
3,准备应答
3,开始应答
其中1和4可能只牵扯到红色字体的2,而2和3一般会牵扯到红色字体的1,其目的即借助OUT事件延续事件的触发以便实现完全异步的插件回调机制。
而客户端的每个状态将会要求注册IN/OUT事件,并且每个状态下对IN/OUT事件有各自的处理方法,并在自己状态处理完成后设置进入下一个状态并由下一个状态处理机注册自己所需的IN/OUT事件。
|
方案2
|
方案2是消费者与生产者模型?这样看来,方案1也不过是方案2在缓冲为1时的抽象,性能应该很好比较!
|
这个就用线程池喽,,应该会比临时创建线程性能好.
|
方案1也不过是方案2在缓冲为1时的抽象,性能应该很好比较
|
不就每秒处理 5 个么,貌似随便那种写法也不会提高多少
|
好像是哈,,cpu达到瓶颈的情况下,多线程是解决不了问题的。
不过如果cpu是多核的,多线程数就等会cpu核心数,还是有提升的,说不定每秒处理10个了。
不过如果cpu是多核的,多线程数就等会cpu核心数,还是有提升的,说不定每秒处理10个了。
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术,将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。