@superbai
最近处理 asyncio 做流量转发调度相关，还有 TCP 日志啥的，两个都几千 qps 处理一大堆 TCP ，以前折腾 hadoop steaming 跟爬虫，那时候才真是天天被逼着砍配置...

Windows 上主要还是靠上网习惯, 其次是杀软, 不知道现在主防进步到什么程度了, 唉, 如果有个那种性能损失不严重的虚拟机, 我真想 linux 为主, 打游戏走虚拟机

@janxin

以前直接上 pypy3, 确实明显提速, 不过跟不上官方大版本, 暂时没继续用, 当绿色版解释器挺好. pyston 之类的就没继续试

后来试了 nuitka 感觉函数有些提速, 但是协程啥的反而性能损失了一小半

后来又试了 3.11, 比 3.8 快的确实明显, 程序启动和几个缓存的设计都挺有意思的

后来看到 taichi, 试了下, 至少我的代码没啥明显变化, 貌似还有些限制... 今天机器之心推送看到 codon, 去官网看又是 gpu 加速又是一些前提条件的, 暂时只敢观望, 也没见到有人聊聊到底咋样

后来周报里看到 socketify, 还在观望, TCP 上对 Python 来说性能一直不是问题, 协程+reuse_port 足够用了, 不知道这库有什么前景没有, 毕竟被好几个 "考试大师" 类的 web 库坑过好几次了

hpy 很早以前见到了, 一直没尝试, 有啥意思啊?

确实, 代码写到一定阶段发现, 性能真从来都不是事, 软件架构和技术选型反而是杀伤更大的坑... 早年写的代码不管维护重构多少次, 第二年看全都像屎山

前几天不是有帖子说了么, 趁着人多放假, 一块回家养病去, 不耽误来年干活

@vinckdu997 呃还不是, 后面提到云原生是用别人镜像自己部署新镜像. 我说的那个是比如阿里云上自定义镜像那种. 过期什么的用户考虑的不多, 直接用云厂商提供的就好了, 除了包管理有些区别, 大部分区别在普通用户面前都感觉不到, 命令都一样的

现在有的 "稳定的企业" 甚至都开始玩 KPI 了, 不知道哪招的社招员工带的, 反正连数据治理都没做直接就说要达到 XXX 提高 100%, 但是指标数据也是自己收集自己提供证据, 真就裁判下场参赛


且行且珍惜吧

大部分厂商都是自己定制的, 有偏 debian 的, 有偏 RHEL 的, 自己创建镜像的话随便吧, 反正现在有点能力的真就走云原生了, 太省心了

公司里套了两三层堡垒机各路 VPN 各种安全宣贯... 啥远程开发都不让用唉

这几天在苏州想买个 modely , 听说要出新电池, 又怕新电池的价格不是最低配的不吃国家补贴... 纠结要不要今年买了

话说这续航, 我跑 800 km 是不是没戏

腿毛长出来痛苦毛啊? 我今年开始刮了, 貌似之前搓澡巾用太狠, 有一大块斑秃了... 然后冬天搓澡师傅使劲很大, 有时候拔毛太疼了, 不如直接剃了, 反正留着也没啥用, 掉的床单上到处是, 基本上一两个星期看不顺眼刮一次, 不然穿压缩裤打球有时候拔到毛也真的疼

从 lastpass 过来确实两个地方不如

1. 输入框旁边没有按钮, 要去右上角找, 右上角花花绿绿有点多...
2. lastpass 可以填充密码以外的, 比如密保问题那一大堆带下拉菜单都帮你选好

去买膏药, 发现有个货架空了一大片, 一问: 连花清瘟全家福

赞成站长, 如无必要勿增实体.

加个毛的标记, AI 滥用后期根本不可控, AI 语料如果不更新一直停留在特别老的时期, 那就是另一个 CSDN: 别人问个问题, 结果回答一个淘汰的方案. 论坛是论坛, 问答社区是问答社区, 可以自己写个插件看 AI 结果, 但请不要出现在到处都是, 维护成本莫名增加, 失控了也不好治理

Ubuntu ，mint ，manjaro 各用 2 年，大部分软件没啥问题，微信不好使，所以我把微信办公的工作全辞了

偶然搜到这个问题, 楼主提到的

疑问 1：网上看到的 recv(4)好像都是直接写的，请问这个 recv(4)有必要向下面一样 while 吗？



不是故意挖坟, 最近在搞 asyncio 处理 logger 的 SocketHandler, 官网给的文档和楼主 append 里面差不多, if len(header_bytes) < 4 就跳出

但是又偶然读到官网这段 https://docs.python.org/zh-cn/3/howto/sockets.html#using-a-socket

"以其长度（例如，作为 5 个数字字符）作为消息前缀时会变得更复杂，因为（信不信由你）你可能无法在一个 recv 中获得所有 5 个字符。在一般使用时，你会侥幸避免该状况；但是在高网络负载中，除非你使用两个 recv 循环，否则你的代码将很快中断 —— 第一个用于确定长度，第二个用于获取消息的数据部分。这很讨厌。当你发现 send 并不总是设法在支持搞定一切时，你也会有这种感觉。 尽管已经阅读过这篇文章，但最终还是会有所了解！"

如果不想弄丢日志, 这套方案还可行吗, 因为协程里的 read() 确实是读到不超过那个长度的结果. 虽然精确 read 可以读到完整

考研时候被数据定义语言洗脑过... 想知道 deadline 这么缩写是老外用法还是中式创新