
1 zoharSoul 1 月 21 日 难点在于量化吧 这种优化的场景还是很简单的, 不管是 go 还是什么的都 ok |
2 balckcloud37 1 月 21 日 其实只是受不了 gc 的话,disable gc 再手动 gc 就好了 另外如果项目里没有 circular ref ,直接不 gc 也行 |
3 encro 1 月 21 日 a 股 ctp 接口哪家好用,需要什么开通条件呢。 |
4 shyrock2026 1 月 21 日 这标志性小图标。。。不是 AI 写的? |
5 JimLee0921 1 月 21 日 这不是 AI 写的我把头剁了 |
6 k9982874 1 月 21 日 via Android 没人吐槽 3 秒几千条数据卡 json 解析? 用的共享 cpu ,512m 的玩具机吗? 即使是 python 也说不过去吧,只能说是一坨 |
7 Anonono 1 月 21 日 没必要上来就喷一坨吧,感谢 lz 分享 |
9 bigtan 1 月 21 日 缓存对齐的环形缓冲区,这个基本上都这么干 |
10 Sawyerhou 1 月 21 日 挺有趣的帖子,感谢分享 :) |
11 adgfr32 1 月 21 日 via Android 如果数据模型不复杂,可以先多进程试试,不过如果历史代码不多,直接换 golang 是个明智选择。 |
12 ClericPy 1 月 21 日 曾经也遇到过,CPU 密集型把协程卡死出现过 3 次,两次是 selectolax 、lxml 的解析十几万字符的 HTML ,一次也是类似你的情况解析十几 MB 的大 JSON (特么的有人把一大堆图片做 base64 放 JSON 里了)。最后 hadoop 直接超时杀死还没看到报错 python 在有些场景确实体现了并发上的先天不足: 1. 多线程不能利用多核,所以有些时候要自己开进程池,明明是无副作用的纯函数却要共享个 GIL 。子解释器希望有用但不太期待 2. to_thread 能让协程不至于因为一个 CPU 特别忙的任务一直 hang 在那。 但是现在非常尴尬的一个地方是,我也不知道哪个函数是敏捷的小函数还是 CPU 秘籍的大函数 在协程里的一个困境就是: 1. 同步函数无脑放 to_thread ,对于特别多的小函数开销很浪费。 2. 为了计算密集型的放 ProcessExecutor 里,子进程也很费事。 现在的协程,只能尽最大可能保证全程协程,不耦合太多同步函数进来 PS:当年 hang 死的问题,现在看书知道 asyncio 开 debug 模式就行了,然后在公司里 langchain 的一个项目日志里,几百条阻塞 warning 日志。。。。。。 |
13 aloxaf 1 月 22 日 我觉得继续用 Python 优化解决这个问题,会是个更有趣的分享 |
14 SDYY 1 月 22 日 python 我一般都用 orjson ZMQ 是 ZeroMQ 吧 |
15 lixuda 1 月 22 日 如果策略慢怎么办,用 go 或 rust 来代替吗 |
16 thtznet 1 月 22 日 Python 交易策略有没有可能共享一下?不是不相信楼主,就是想开开眼界。 |
17 xgdgsc 1 月 22 日 via Android 不如 Julia |
18 zhangli2946 1 月 22 日 #go 程序员开年最好的娱乐帖子 |
19 DioBrandoo 1 月 22 日 搞笑,用自己能力问题在这里蹭语言流量 |
20 Huelse 1 月 22 日 想知道用 Python3.14 去掉 GIL 后能否有所改善 |
21 loongkim 1 月 22 日 emm ,对对对... |
22 DefoliationM 1 月 22 日 via Android Python 底层库都是 c ,比 go 性能好。 |
23 fkdtz 1 月 22 日 你是会起标题的 如果机房欠电费停电了,是否可以说,国家电网把我服务器干挂了 |
24 i0error 1 月 22 日 复制可跑、立竿见影,味太冲了 |
25 namonai 1 月 22 日 用 python 接实时行情,不是你在做梦就是我在做梦 |
26 sheeta 1 月 22 日 我也是 python 接的全市场 5000 多家 3s 的行情,我的咋没挂。我是 python -> kafka -> flink |
27 harlen 1 月 22 日 并发高的解决途径是限流吧。 把流量控制在你服务器最大能承受的压力上,你换了 go ,下次来个 go 不能承受的最大并发压力一样要崩。应用没崩溃。基础设施都要崩,比如 一个高并发 打到数据库上。 你数据没用 连接池限流。数据库一样会崩溃 |
28 Howiee OP |
30 julyclyde 1 月 22 日 不懂量化 json 在这里是什么情况?上游给的行情数据是 json 格式吗?? |
32 sanebow 1 月 22 日 via iPhone tickdb 软广? |
33 sanebow 1 月 22 日 via iPhone Tickdb 软广? |
34 freemoon 1 月 22 日 本站有 python 大拿,再等等 |
35 song135711 1 月 22 日 至少两点可以改进的 1. 上线前要测试。 2. 伪高并发的情况,用消息队列做异步处理。现在就算 golang 可以抗住,以后量增加了,还要改 rust 吗 |
37 Howiee OP @julyclyde 是的,接入层这边拿到的是已经归一化后的 JSON 。 上游原始行情并不一定是 JSON ,但为了多市场统一和下游解耦,中间会做一次协议转换。 这里卡住的点也不在 JSON 本身,而在负载形态: A 股这类行情很多是 snapshot 型推送,表面看是 3 秒一批,但实际上会在很短的时间窗口内把一批数据集中推完。 在 asyncio 的单 event loop 场景下,JSON 解码和对象创建是 CPU 密集的,一旦和这种脉冲叠加,就容易放大循环执行中的耗时,表现出来就是队列堆积和端到端延时飙升。 |
38 balckcloud37 1 月 22 日 @k9982874 python gc 在对象特别多的时候确实会卡很久,json 解析本身性能不是问题,但是解析几个 json 就要 gc 一次然后卡几百毫秒就会出问题了 |
39 assassinkyo 1 月 22 日 直接发股票代码吧,你写的这些我不爱看。 @_@ |
40 latifrons 1 月 22 日 A 股开盘 + 非农数据公布,你逗我…… |
41 lxxzml 1 月 22 日 数据源怎么接? |
42 zhaoahui 1 月 22 日 聚合源( TickDB ) 软广 |
48 stark4 1 月 24 日 没学过一天编程,但经过 ai 建议后我是用 orjson 解决的 ws 的风暴的,现在 500k/s 的处理速度,我主要做的是期权量化 |
49 chenfengrugao 1 月 27 日 @stark4 看 AI 程可以快速上手了。有靠的源? |
50 pyKane 1 月 30 日 3 秒几千条 JSON 就搞挂了,听起来就不靠谱。 你真的是用了 Asyncio ? json.loads 是占点 CPU 但也没你说的这么惨。 另外 ujson.loads 你换这个也可以,性能更好。 但你的问题看起来像是你在用 AI 写的坑不少。 我这一个项目每秒也有上万并发,API 也是 JSON 数据,async/await 很丝滑,对于占 CPU 的地方要学会适当 await asyncio.sleep(0) 让出一些 CPU 给其它 await |