这百万级的内存申请和释放是fiber内部产生的还是你们代码自己产生，但是因为使用了fiber后产生的？


【 在 mvtec 的大作中提到: 】
: fiber的运行速度跟屎一样
: 还真敢用
: 我们有个feed handler
: ...................
--
FROM 163.116.140.*

上tcmalloc之类的玩意，一秒钟多线程并发100M的alloc没问题
【 在 mvtec 的大作中提到: 】
: fiber的运行速度跟屎一样
: 还真敢用
: 我们有个feed handler
: ...................
--来自微微水木3.5.14
--
FROM 223.104.44.13

说得对。就是这样的。
【 在 hgoldfish 的大作中提到: 】
: stackful 协程一般是在创建协程的时候申请内存的啊。如果优化得好的话，前一个协程释放的内存可以给下一个协程使用，应该是反而减少了内存操作，而且因为协程里面运行的函数都可以方便地从栈里面申请内存，应该能够有效地提高内存数据的局部性。
: 我感觉应该是你们怎么用错了。
:
--
FROM 221.218.61.*

在trading这个领域
基本都是单线程
不是国内那种web开发为主体，天天就是喊并发。
【 在 jjfz 的大作中提到: 】
: 上tcmalloc之类的玩意，一秒钟多线程并发100M的alloc没问题
: --来自微微水木3.5.14
--
FROM 24.0.210.*

我设计的高频交易架构是这样：
服务器多核多线程，TPC模式，每个链接一个线程。多台服务器。服务器要处理数据库业务，只能使用简单的多线程模式。
加一个管理器，对多台服务器设置连接池。对每台服务器有限个链接（服务器有限个线程）。对多个服务器进行负载均衡和容错。
管理器采用线程池模式，M：N，M个客户端，N个线程。
一般M上万，N等于核数。
由于N要处理两边的IO（客户端的请求转到服务器，服务器的应答返回客户端），所以要用到异步。
于是有M个协程，N个线程。多线程协程，不知道ASIO框架能解决这个问题否。
这个架构，对单个任务而言，延迟比较大，在百微秒级别。
但是并行度比较好，总的系统吞吐量很大，适合交易事务处理。
总的交易吞吐量，取决于服务器数，总核数，后台数据库引擎的处理能力。



海量客户端-----交易管理器---多个服务器---数据库（RAC）
交易压力由管理器承担，超过服务器处理能力的请求在此排队。

客户端不接触数据库，只发出业务请求，并得到结果。即，数据库不对外，安全。

外部攻击的话，只能攻击管理器，那里没有数据，是保证系统数据安全的。它的抗攻击能力极强。即使被攻塌，重新启动也很快。

如果数据库被攻塌，要想恢复，你试试。


这是一个交易中间件。
客户端和服务器的交易软件，你自己写。
有服务接口。
中间的什么线程协程，你不要管，全透明，就当他不存在。

【 在 gfkid 的大作中提到: 】
: 好奇高频交易都是怎样的软件架构
: 似乎都是单体软件，不能搞网络间的分布式了，走网络就慢了
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*