Boost asio 连接池问题

yulihua49

sxcong 发表于 2017-11-16 13:38
同步和异步可能没和你说明白：
客户要求同步，也就是说等你发成功再返回。
但网络层一定是异步的,否则效 ...

可以通过协程，把底层的异步操作包装成上层的同步操作。
可以问问WINDOZE版主。

joepayne

回复 21# yulihua49

协程的概念好像听说过，有人用过asio + coroutine

sxcong

楼主这个需求压力不大，用不到协程的。其实服务器端用个最简单的epoll就够了。windows下可以用IOCP，个人感觉，poco库的那个serversocket最好用。

yulihua49

sxcong 发表于 2017-11-17 09:03
楼主这个需求压力不大，用不到协程的。其实服务器端用个最简单的epoll就够了。windows下可以用IOCP，个人感 ...

不是因为压力大小，而是为了解决IO的异步操作和应用的同步需求的。
就是应用以同步方式调用IO。而IO以异步方式实现。
如果压力不大，可采用单线程协程，实现简单些。多线程协程实现起来比较困难，但是大压力系统必须如此。

如果应用以异步方式调用IO，那程序将比较复杂，凌乱而难于维护。而且应用程序员不仅需要熟悉业务逻辑，还要了解IO过程，机制。要求高了点。所以需要系统程序员提供IO框架.


比如我们提供了：
int RecvNet(sock,buf,size,timeout);
int SendNet(sock,buf,size,MTU);
一个调用就完成了IO，使用了epoll机制，在IO未完成时yield，线程放弃了这个任务干别的去了，等返回时，已经是resume了，有可能返回时是另一个线程。
这一切应用程序员都不用管。

joepayne

回复 24# yulihua49

我也是期望能够做到线性scale强一些，毕竟业务的发展肯定是越来越繁琐，对性能的要求肯定也是越来越高，不可能重复重构这些底层的架构，尽量只是处理一些上层的东西或者硬件配置什么的，不知道华哥关于协程处理这种需求的有没有一些经验可以借鉴一下，或者可供参考学习的资料。

joepayne

回复 16# linux_c_py_php

大哥服务端写得相当健壮啊，客户端是并发异步请求，每个线程一个连接一个请求。不知道如果客户端是并发同步的，每个线程可能有多个请求，应该咋整？如果想复用这些连接呢？

yulihua49

joepayne 发表于 2017-11-17 12:32
回复 16# linux_c_py_php

大哥服务端写得相当健壮啊，客户端是并发异步请求，每个线程一个连接一个请求 ...

每个连接一个线程，低并发的还可以，高并发不可以。而且也不抗DOS攻击，几千个连接下来你就死翘翘了。

yulihua49

joepayne 发表于 2017-11-17 12:32
回复 16# linux_c_py_php

大哥服务端写得相当健壮啊，客户端是并发异步请求，每个线程一个连接一个请求 ...

使用线程池，有限的线程处理大量连接。
每个连接一个CONTEXT，包含这个连接的相关资源描述。这些CONTEXT在epoll里等待。一旦呼入，就由线程池中的一个线程捕获进行处理。线程按照这个context的资源和状态进行处理。
系统由有限个CONTEXT组成，如10000个或65535个。
一般情况，每次accept，从空闲CONTEXT中取出一个，与这个socket绑定，随后把这个CONTEXT丢到epoll等待它发消息。

CONTEXT的具体内容你自己设计，总之是要表达任务的资源、状态。前边说的有关协程操作也是基于这个CONTEXT的，里边会有一个ucontext结构,你可以man一下。

连接断开，任务终止，归还CONTEXT。

Fixend

首先要确定你有多少连接，epoll，asio这些都是IO复用技术，也就是有大量连接才能体现对性能提升的好处。只有两三个socket的情况，这些快不到那去。

一个合理的架构，单个异步连接，就足够将带宽跑满。

所以先考虑清楚你的线程模型、消息处理机制。参考下apache的三种MPM模型。

如果连接数量不多，从原来的同步改成异步的话，个人觉得并没明显好处，复杂度还提升了N倍。

yulihua49

Fixend 发表于 2017-11-17 20:49
首先要确定你有多少连接，epoll，asio这些都是IO复用技术，也就是有大量连接才能体现对性能提升的好处。只 ...

一个合理的架构，单个异步连接，就足够将带宽跑满。

----------------------------------------------------------
你这仅仅是测试。实际不可能发生这样的事。
实际上都是大量客户端接入，不可能共享连接，流量都是大量连接形成的。异步架构就是要解决大量连接处理的无缝转换，及时处理防止阻塞。所以才有了C10K问题，就是10000个客户端并行问题，这是20~30年前的课题，现在这个根本不是问题，就是靠连接池、线程池、异步操作，协程等等技术实现的。


如果单个连接就形成饱和流量，就不需要任何复杂架构，开一个连接通讯就是了，犹如FTP。
这个就是1：1类型，最简单，同步处理。
而后，M:1类型，M个连接1个线程处理，需要异步处理；M:M类型，M个连接有M个进程或线程处理，可以同步处理。M:N，M个连接N个线程（进程）处理（M很大，N比较小），需要异步处理，对于应用来说有点复杂，因此需要引入协程，提供同步调用接口，如23楼那样的函数。
对于楼主的问题，如果并发数小，可采用M:1或M:M方式。M:1也可能需要协程包装。