- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
严重怀疑是不是什么和OS相关的macro没加，导致boost是在模拟fiber，而不是调用OS api来实现
【 在 mvtec 的大作中提到: 】
: fiber的运行速度跟屎一样
: 还真敢用
: 我们有个feed handler
: ...................
--
FROM 183.128.164.*
其实重点是，在高频交易系统中，在交易管理环节，需要协程技术，而且是多线程的协程。需要高效率的切换，一个服务完成后，尽可能快速切换到另一个用户，尽量减少服务的空等时间。
有点像银行的排队机，一个窗口空了，马上叫下一位。
单线程的协程不行，一个连接空闲了，线程还在别的协程忙活，慢慢悠悠轮到这个协程再处理。
我比较担心fiber框架能否处理多线程协程。线程协程没有绑定关系，任何线程有空就处理任何协程。
【 在 ziqin 的大作中提到: 】
: 听起来更像经纪商的平台构架，而不是交易构架，哪个正儿八经的交易系统，会有几个万个客户端
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
HFT根本不可能在trading过程中
连数据库的
所有的app全是single thread
Affinity 到isolated cpu core
【 在 ylh0315 的大作中提到: 】
: 我设计的高频交易架构是这样：
: 服务器多核多线程，TPC模式，每个链接一个线程。多台服务器。服务器要处理数据库业务，只能使用简单的多线程模式。
: 加一个管理器，对多台服务器设置连接池。对每台服务器有限个链接（服务器有限个线程）。对多个服务器进行负载均衡和容错。
: ...................
--
FROM 50.240.187.*
管理器不连数据库。只负责协调资源，和安全隔离。
多线程协程只在管理器使用。用于在客户端与服务器间传递数据。线程无需与核绑定，协程也无需与线程绑定。谁有空谁处理，不要耽误时间。
架构见48楼。
【 在 mvtec 的大作中提到: 】
: HFT根本不可能在trading过程中
: 连数据库的
: 所有的app全是single thread
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
它关心一个任务的响应速度，交易系统关心的是总体的交易吞吐量。
【 在 mvtec 的大作中提到: 】
: HFT根本不可能在trading过程中
: 连数据库的
: 所有的app全是single thread
: ...................
--
FROM 221.218.61.*
做过一个压力测试，服务器8台各16核，
管理器12核，12线程。模拟了10000个客户端，把8台服务器干到了100%，管理器也干到了85%的CPU利用率。
多线程协程自己写的，用的makecontext那一组函数，stackfull。自己造轮子，没有哪个现成的适用。
有意思的那些服务器登录都登不进去了，Linux，非抢占的。
【 在 mvtec 的大作中提到: 】
: HFT根本不可能在trading过程中
: 连数据库的
: 所有的app全是single thread
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
okok
【 在 ylh0315 的大作中提到: 】
: 其实重点是，在高频交易系统中，在交易管理环节，需要协程技术，而且是多线程的协程。需要高效率的切换，一个服务完成后，尽可能快速切换到另一个用户，尽量减少服务的空等时间。
: 有点像银行的排队机，一个窗口空了，马上叫下一位。
: 单线程的协程不行，一个连接空闲了，线程还在别的协程忙活，慢慢悠悠轮到这个协程再处理。
: ...................
--
FROM 183.128.164.*
这个太简单了。弄个生产者消费者队列就行了。每个线程启动 100 个协程，一共 16 个核心是 1600 个协程。这些协程都在消费者队列里面抢任务。
如果打算节约资源，就在每个线程里面启动一个监管协程，检测空闲协程的数量。空闲协程太多，就杀掉一些协程，少了就再启动预备状态的协程。
由编程语言，比如 go, java, c# 那样子把协程自动地在各种线程之间调来调去一般都是没有必要的。
【 在 ylh0315 的大作中提到: 】
: 其实重点是，在高频交易系统中，在交易管理环节，需要协程技术，而且是多线程的协程。需要高效率的切换，一个服务完成后，尽可能快速切换到另一个用户，尽量减少服务的空等时间。
: 有点像银行的排队机，一个窗口空了，马上叫下一位。
: 单线程的协程不行，一个连接空闲了，线程还在别的协程忙活，慢慢悠悠轮到这个协程再处理。
: ...................
--
FROM 110.81.0.*
本来就是这种队列。协程是每个客户端链接一个协程。一共16000个（可设置1000～65534）。
每核一个线程。用epoll进行调度，激活的是哪个协程就干哪个协程，挺简单的。
哪个协程需要进入IO，就设置好epoll，然后挂起。等待epoll激活。一堆线程在进行epoll_wait。就这么简单。
【 在 hgoldfish 的大作中提到: 】
: 这个太简单了。弄个生产者消费者队列就行了。每个线程启动 100 个协程，一共 16 个核心是 1600 个协程。这些协程都在消费者队列里面抢任务。
: 如果打算节约资源，就在每个线程里面启动一个监管协程，检测空闲协程的数量。空闲协程太多，就杀掉一些协程，少了就再启动预备状态的协程。
: 由编程语言，比如 go, java, c# 那样子把协程自动地在各种线程之间调来调去一般都是没有必要的。
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
预备一定数量的context池（协程），客户端连接一个分配一个，设置好epoll等待呼叫。然后如楼上所说。最后，disconnect时销毁并归还context。
【 在 hgoldfish 的大作中提到: 】
: 这个太简单了。弄个生产者消费者队列就行了。每个线程启动 100 个协程，一共 16 个核心是 1600 个协程。这些协程都在消费者队列里面抢任务。
: 如果打算节约资源，就在每个线程里面启动一个监管协程，检测空闲协程的数量。空闲协程太多，就杀掉一些协程，少了就再启动预备状态的协程。
: 由编程语言，比如 go, java, c# 那样子把协程自动地在各种线程之间调来调去一般都是没有必要的。
: ...................
--
FROM 221.218.61.*