Node.js需要按顺序执行异步逻辑时一般采用后续传递风格，也就是将后续逻辑封装在回调函数中作为起始函数的参数，逐层嵌套。这种风格虽然可以提高CPU利用率，降低等待时间，但当后续逻辑步骤较多时会影响代码的可读性，结果代码的修改维护变得很困难。根据这种代码的样子，一般称其为"callback hell"或"pyramid of doom"，本文称之为回调大坑，嵌套越多，大坑越深。

monkey patch指的是在运行时动态替换,一般是在startup的时候. （感觉大多数是Python程序的一种技巧）

用过gevent就会知道,会在最开头的地方gevent.monkey.patch_all();把标准库中的thread/socket等给替换掉.这样我们在后面使用socket的时候可以跟平常一样使用,无需修改任何代码,但是它变成非阻塞的了.

之前做的一个游戏服务器,很多地方用的import json,后来发现ujson比自带json快了N倍,于是问题来了,难道几十个文件要一个个把import json改成import ujson as json吗?

其实只需要在进程startup的地方monkey patch就行了.是影响整个进程空间的.

同一进程空间中一个module只会被运行一次.

下面是代码.

main.py

import json
import ujson
def monkey_patch_json():
    json.__name__ = ‘ujson‘
    json.dumps = ujson.dumps
    json.loads = ujson.loads

monkey_patch_json()
print ‘main.py‘,json.__name__
import sub
sub.py
import json
print ‘sub.py‘,json.__name__
运行main.py,可以看到都是输出‘ujson‘,说明后面import的json是被patch了的.

最后,注意不能单纯的json = ujson来替换.

$ ulimit -s    
10240

也就是10M；修改的方法如下：

linux查看修改线程默认栈空间大小 ulimit -s

1、通过命令 ulimit -s 查看linux的默认栈空间大小，默认情况下 为10240 即10M

2、通过命令 ulimit -s 设置大小值 临时改变栈空间大小：ulimit -s 102400， 即修改为100M

3、可以在/etc/rc.local 内 加入 ulimit -s 102400 则可以开机就设置栈空间大小

4、在/etc/security/limits.conf 中也可以改变栈空间大小：

#<domain> <type> <item> <value>

* soft stack 102400

重新登录，执行ulimit -s 即可看到改为102400 即100M

最后尝试总结一下个人的想法：

• 高性能计算，牺牲公平性换取吞吐；
• 面向 IO Bound 任务，减少 IO 等待上的闲置，这其实和高性能计算领域内的优势是一致的；
• Generator 式的流式计算；
• 消除 Callback Hell，使用同步模型降低开发成本的同时保留更灵活控制流的好处，比如同时发三个请求；这时节约地使用栈，可以充分地发挥 "轻量" 的优势；

• 如果栈使用得不节制，消耗的内存量和系统线程无异，甚至内存管理还不如系统线程（系统线程可以动态地调整虚拟内存，用户线程的 Segmented Stack 方案存在严重的抖动问题，Continous Stack 方案管理不当也会抖动，为了避免抖动则成了空间换时间，而内核在这方面做了多少 heuristic 呢）；
• IO Bound 任务可以通过调线程池大小在一定程度上缓解，目标是把 CPU 跑满即可，这点线程池的表现可能不完美，但在业务逻辑这个领域是及格的；
• 此外，一般的 python/ruby 任务并不是严格的 IO Bound，比如 ORM 的对象创建、模版渲染、GC 甚至解释器本身，都是 CPU 大户；单个请求扣去 redis 请求和数据库请求的时间，其它时间是否仍不少呢？
• CPU 上长时间的计算，导致用户线程的调度变差，不能更快地响应，单个请求的平均时间反而可能更长（诚然并发可能更高）；然而这在 python 这类 GIL 语言来看并不算劣势，甚至比 GIL 的调度更好，至少 gevent 可以知道各 IO 任务的优先级，而 GIL 的调度是事实上的 FIFO；