mayli 最近的时间轴更新 mayli 最近的时间轴更新 |
mayliV2EX 第 30364 号会员，加入于 2012-12-06 17:51:28 +08:00 |
| 活在未来的国际友人 25Gbps 对称家宽 宽带症候群 • mayli • 36 天前 • 最后回复来自 kanari | 67 |
| 请问 Android App 的爬虫有什么好的工具吗？ 程序员 • mayli • 226 天前 • 最后回复来自 locoz | 9 |
mayli 最近回复了
3 天前 回复了 djy0716 创建的主题 › 宽带症候群 › N5105 软路由环境下，电脑使用 IDM 同时下载超过 100 个文件，会随机触发软路由重启 |
为啥不用官方版本
4 天前 回复了 jackiejkl 创建的主题 › MySQL › 请问如果一棵树存在数据表中，有没有办法将其一次查出？ |
正规做法是 CTE 。
13 天前 回复了 dcsuibian 创建的主题 › 宽带症候群 › 这个 All In Two 方案怎么样？ |
竟然有 all in two
17 天前 回复了 lizhiqing 创建的主题 › 宽带症候群 › AWS S3+Cloudfront 无限流量？ |
17 天前 回复了 yanest 创建的主题 › 宽带症候群 › 有个大带宽服务器，建了 zerotier moon 节点来出租试试 |
玩玩的话…就别收钱了被？
18 天前 回复了 fantix 创建的主题 › Python › 新项目再轮 asyncio 实现： kLoop |
@fantix 是的，差不多是 for each(write(header), sendfile), 然后 sendfile 用 splice 实现。
但是在实际场景中，由于每个文件块比较小，这样造成了大量的 async 调用和 syscall ，然后性能也比 read/join/send 快，可能是这样虽然节约了内存拷贝，但是 syscall 数目变多了，开销也会大。
所以我觉得可能 io_uring 的批量操作可以优化，不过使用底层直接写很费劲，同时使用抽象化的库又失去了批量提交的性能。
对于更深的队列这个事情，我觉得如果真的合理利用，对于 asyncio 可能是杀手级应用，至少对于 http webframework 跑分来说，都是很小的请求，syscall 可以减小一个数量级。
但是在实际场景中，由于每个文件块比较小，这样造成了大量的 async 调用和 syscall ，然后性能也比 read/join/send 快，可能是这样虽然节约了内存拷贝，但是 syscall 数目变多了，开销也会大。
所以我觉得可能 io_uring 的批量操作可以优化，不过使用底层直接写很费劲，同时使用抽象化的库又失去了批量提交的性能。
对于更深的队列这个事情，我觉得如果真的合理利用，对于 asyncio 可能是杀手级应用，至少对于 http webframework 跑分来说，都是很小的请求，syscall 可以减小一个数量级。
18 天前 回复了 FariaChen 创建的主题 › 分享创造 › [人人都是艺术家] 发起一个活动 Artists100x，免费 mint 100 张 NFT 送给大家 |
@FariaChen gas 费可以发给我吗？不需要花钱
18 天前 回复了 gitandgit 创建的主题 › 分享创造 › 一个构建在区块链上的聊天 app 应该是什么样子？这样的去中心化 app 可以杀死中心化的 whatsapp 吗？ |
Email xmpp …一般最难的是用户，没人跟你聊天，再酷也没用
19 天前 回复了 fantix 创建的主题 › Python › 新项目再轮 asyncio 实现： kLoop |
@fantix 感谢回复！现在业务上的需求是随机读取文件，并且附加一个 header 发送出去。
理想的做法是使用
os.sendfile(out_fd, in_fd, offset, count, headers=(), trailers=(), flags=0)
这个实现的 Headers 参数, 但是这个系统调用仅在 bsd 上有实现，所以在使用 io_uring 模拟这个行为的时候，只能 link 读文件， 提交，等待读取完毕，link header/内容，发送出去。这样读取和发送都不需要经过用户态处理，但是实现相对比较冗长。
请问在 Asyncio 框架下，能否有更高效的实现？
我感觉目前的抽象程度，无法合理的利用更深的队列功能，比如批量提交和批量完成。这样就退化到了每次 io 也要至少触发两次系统调用，感觉性能比较低。
理想的做法是使用
os.sendfile(out_fd, in_fd, offset, count, headers=(), trailers=(), flags=0)
这个实现的 Headers 参数, 但是这个系统调用仅在 bsd 上有实现，所以在使用 io_uring 模拟这个行为的时候，只能 link 读文件， 提交，等待读取完毕，link header/内容，发送出去。这样读取和发送都不需要经过用户态处理，但是实现相对比较冗长。
请问在 Asyncio 框架下，能否有更高效的实现？
我感觉目前的抽象程度，无法合理的利用更深的队列功能，比如批量提交和批量完成。这样就退化到了每次 io 也要至少触发两次系统调用，感觉性能比较低。
21 天前 回复了 fantix 创建的主题 › Python › 新项目再轮 asyncio 实现： kLoop |
之前我也用 io_uring + python 的 binding 自制了一些 tcp server 逻辑，体验上感觉并没有特别提升，反而是编程难度增加了不少。
使用的库是 https://pypi.org/project/liburing/ 基本上覆盖了所有常见的操作，但是直接用 io_uring 实现业务逻辑的确是有点费劲，尤其是如果要是深度利用队列，就需要自己手动维护队列，而且要 link 起来，但是像是从 disk 读写 tcp 这种操作，最高效的是可以完全给内核 link 多个 读 / 写，但是实际的情况是 tcp 会写满被 cancel ，然后又需要 userspace 手动重试。
使用的库是 https://pypi.org/project/liburing/ 基本上覆盖了所有常见的操作，但是直接用 io_uring 实现业务逻辑的确是有点费劲，尤其是如果要是深度利用队列，就需要自己手动维护队列，而且要 link 起来，但是像是从 disk 读写 tcp 这种操作，最高效的是可以完全给内核 link 多个 读 / 写，但是实际的情况是 tcp 会写满被 cancel ，然后又需要 userspace 手动重试。
Select Language