玩玩的话…就别收钱了被？

@fantix 是的，差不多是 for each(write(header), sendfile), 然后 sendfile 用 splice 实现。
但是在实际场景中，由于每个文件块比较小，这样造成了大量的 async 调用和 syscall ，然后性能也比 read/join/send 快，可能是这样虽然节约了内存拷贝，但是 syscall 数目变多了，开销也会大。
所以我觉得可能 io_uring 的批量操作可以优化，不过使用底层直接写很费劲，同时使用抽象化的库又失去了批量提交的性能。
对于更深的队列这个事情，我觉得如果真的合理利用，对于 asyncio 可能是杀手级应用，至少对于 http webframework 跑分来说，都是很小的请求，syscall 可以减小一个数量级。

@FariaChen gas 费可以发给我吗？不需要花钱

Email xmpp …一般最难的是用户，没人跟你聊天，再酷也没用

@fantix 感谢回复！现在业务上的需求是随机读取文件，并且附加一个 header 发送出去。
理想的做法是使用
os.sendfile(out_fd, in_fd, offset, count, headers=(), trailers=(), flags=0)
这个实现的 Headers 参数, 但是这个系统调用仅在 bsd 上有实现，所以在使用 io_uring 模拟这个行为的时候，只能 link 读文件， 提交，等待读取完毕，link header/内容，发送出去。这样读取和发送都不需要经过用户态处理，但是实现相对比较冗长。
请问在 Asyncio 框架下，能否有更高效的实现？
我感觉目前的抽象程度，无法合理的利用更深的队列功能，比如批量提交和批量完成。这样就退化到了每次 io 也要至少触发两次系统调用，感觉性能比较低。

之前我也用 io_uring + python 的 binding 自制了一些 tcp server 逻辑，体验上感觉并没有特别提升，反而是编程难度增加了不少。
使用的库是 https://pypi.org/project/liburing/ 基本上覆盖了所有常见的操作，但是直接用 io_uring 实现业务逻辑的确是有点费劲，尤其是如果要是深度利用队列，就需要自己手动维护队列，而且要 link 起来，但是像是从 disk 读写 tcp 这种操作，最高效的是可以完全给内核 link 多个 读 / 写，但是实际的情况是 tcp 会写满被 cancel ，然后又需要 userspace 手动重试。

看了一下基本都是瞎改，或者说性能劣化。

我觉得题主需要说明下预算和预期的时间
不然不好估算
最便宜的话慢慢传就好了
预算出来了
就方便估计技术路线

链路长不是带宽利用率低的直接原因
即使 300ms 延迟也可能跑满全部带宽
核心问题是缺少可以跑满的高质量线路
尤其是国内

解决了线路 QoS 质量，传输这个没有什么问题

什么是软件
什么是存活？

无人值守打印的话
打印点反动传单
人就进去了

@testcaoy7 路由器插 U 盘或者移动硬盘盒

Google docs 路过 而且 edge 现在可以预览,好像没有啥必要在本地装一份

请问这个和 sqoosh 有什么区别

不推荐用这个方式
你这个 Branch 的内容会一直增长
直到 Checkout 要花好久

V2ex 开个考古区吧
PS, 路径里的那个空格是微软故意加的

@daum https://cf-bbb.pages.dev/

全球 270 多个国家和地区

英文版 Windows 也有这个问题