本地使用 docker 来搭建 tracing-benchmark 的测试环境，在测试过程中观察到默认的 bridge 网络下 docker-proxy 进程的 CPU 使用率甚至会高于应用容器本身。
一方面不确定 docker-proxy 的高负载对应用容器的性能测试结果会有多大影响，另一方面则是觉得单纯的 TCP 端口转发功能不应该有这么高的 CPU 使用率。
因此计划模拟并测试 docker-proxy 在高网络负载下的具体表现，以及相关替代方案的实际优化效果。

3.5

使用 chroot 命令可以改变进程的可见根目录，创建出一个 chroot jail，限制对应进程可访问到的文件，降低程序的部分安全风险。
之前编写过一个文件分享 Web 应用 share-Go，在仓库的 README.md 中给出了 run with linux chroot 的简单示例，以避免非预期的文件访问。
偶然发现该 chroot 示例中存在几个隐藏问题，主要涉及到 Golang 程序的外部环境依赖，就顺便整理记录下来。

根据公司相关要求，把自己的主机换成了公司的笔记本。在 Windows 11 上测试了 Hyper-V 虚拟机和 WSL 2，感觉使用 vscode remote 搭建开发环境还是不太方便。
与相关部门进行沟通后，确认公司允许使用 Ubuntu Desktop 作为本地开发环境，于是将笔记本重装为 Kubuntu，期望能接近在 Arch Linux 上的 KDE 使用体验。
测试 Kubuntu 的过程中发现笔记本 CPU 的最大频率明显比 Windows 11 上的低，因此尝试排查具体原因，寻找解决办法。

新功能上线后 Nginx 的日志监控频繁上报某类请求 502 Bad Gateway，但在对应的 Golang 后端服务日志中却没有找到任何异常。
抓取请求参数在测试环境复现后，发现异常请求在 Golang 后端服务日志中会正常打印为 200 OK，与其他正常请求无区别。
根据 Nginx 日志中的请求时间推测，是 Golang 后端服务在请求超过 60 秒后主动关闭了连接，但并没有处理相关超时异常。

2.5

尝试将 struct 序列化为 json 后走 TCP 传输，在 bytes stream 上利用 json 实现 packets stream。
联系 WebSocket 很容易想到可以对 json 文本进行压缩来做传输优化，就选择了广泛使用的流式压缩 gzip 来对 json 进行处理。
写 Golang 测试的时候发现 gzip 压缩结果的 base64 编码中出现了大量重复的 AAAA，长度也比命令行中直接 echo RAW_JSON_TEXT | gzip | base64 得到的编码结果长了许多。
好奇是什么原因导致了 Golang 的 gzip 与命令行里的 gzip 压缩结果出现这种差异，也借这个机会顺便了解一下 gzip 相关的知识。

1.5

服务器上同时运行有多个服务，于是配置了 Nginx 作为统一的入口，根据路由前缀将请求转发到不同的服务上。
HTTP API，WebSocket，TCP forwarding，static content，之前各个服务一直相安无事，但最近出现了问题，服务端 WebSocket 的连接总数偶尔会急剧下降，然后随着客户端的断线重连逐渐恢复。
对多次故障发生时间点附近的服务器日志进行对比分析后，确认 WebSocket 服务本身没有问题，问题出在 Nginx 提供的静态资源服务上。

自己有一台操作系统为Ubuntu 18.04.5 LTS的测试服务器，使用ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';为 MySQL 的root用户设置了空密码。
但一直正常运行的测试应用偶尔会出现连接失败的情况，到服务器上查看后发现数据库root用户的authentication plugin变回了auth_socket，再次手动改成mysql_native_password就好了。
由于问题出现的频率不高，修复也并不麻烦，所以前几次都是手动处理了。最近又遇到了这个问题，决定找到具体原因彻底解决掉。