@Eagleyes 不是对标游泳运动员嘛，自由泳能游个几十米那种，游泳池一个来回什么的都可能得 40 个课时以上。
一般人都没有那个课时，反正就是玩呗。为什么自由泳更好呢？显然就是因为课时多。
真的有 100 个课时练习蛙泳，按正规的训练，蛙泳的效果也不会很差对不对？

@hst001 国内课时少啊，真按国外自由泳的那套开始教，打腿就要打好几个课时。又累又没有即时成效，大家都不买单。
但是一旦学会自由泳就知道，自由泳的动作效率很高的，划一下水就游过去了。

一般速成的都是半吊子蛙泳。毕竟半吊子蛙泳课时少。
完全 0 经验，可以尝试报班。
不过我还是建议自己在学会半吊子蛙泳之后多去练习，然后学自由泳。毕竟你学会自由泳才能说真的会游泳了，毕竟真有什么事，你能用得上。
根据自身经验，学会自由泳怕不是要 20 个课时以上。

日志是走网络用 UDP 发到别的机器不就可以解决这些性能问题么?你的网络 IO 是同步非堵塞，性能只取决于你的发送。

你的这些问题只要你去公司实习一下就会知道了。
公司的要求一般为软件升级不能影响现有业务，你自己想想如何处理才能不影响现有业务就可以了

@codehz 但是文本文件可以压缩，这也是为什么要搞 git-lfs 的一个原因。

@zealinux 古有 svn, perforce，现有 Mercurial (Hg)。选一个自己喜欢用的就好。如果是比较熟悉 git 的话，那么用 hg 挺合适的，都是 DVCS 。

实际上这需求我觉得传统的关系型数据库不好搞。你用一个内存数据库作为缓存层，定时将结果全量同步回数据库就可以了。

@ipwx 谈外部代码就过了，什么 VM 都对堆外内存无能为力。只能靠插件自我维护。实际上搞成 Java 那样是挺好的，JIT 性能提上去，C 扩展完全可以不用。不过都是当年遗留下来的产物，要 Python 抛弃 C 扩展，基本上是要它去死了

@ipwx 讨论 VM 是没有意义的，因为 tracing gc 跟 VM 的没有什么关系。tracing GC 只要有运行时提供功能就可以。而且 CPython 是有 tracing gc 兜底的，只不过不是通用的方式罢了。

GIL 的问题是由于当时采用引用计数这样的垃圾回收技术引出的。毕竟要保护好引用数正确，要不就是处处是小锁。要不就是一个大锁(GIL)。当时为了单线程的性能，就用了一个大锁（ GIL ）。
后面技术发展，大家发现其实 tracing-base 的垃圾回收方案速度也不慢，同时各种优点。于是现代化的 VM 都是 tracing gc 了。
要去掉 GIL，那是得大改啊。

@neoblackcap 修正，都是同步非堵塞。至于 epoll，可以尝试直接使用标准库里面的 asyncio

你问什么堵塞？ IO 多路复用都会堵塞主线程

这些也是非常常见的网络错误，这换其他的语言也要处理的

打不赢就加入他们

这需求完全用不到 NLP，不就是配置文件解析。你大可将 nginx 源代码里面解析配置文件的哪部分代码拿出。然后每次解析一次配置文件。然后对比两次的结果，以及进行一些校验。

如果你用的是关系型数据库，那么你这个做法就是反模式。毕竟关系型数据库讲究数据模型正交。