感谢人生苦短，Pythonic！的投递
今天agentzh在微博上公布了一些OpenResty 与 php-fpm、Nodejs操作MySQL的性能评测数据。
agentzh：我刚才在对比测试大结果集查询时，发现NodeJS在使用
node-mysql库访问MySQL时，上下文切换次数居高不下，都快赶上 php-fpm +
php-mysql了。但Node只起了一个进程，而且 strace 确认了确实是非阻塞的（不像
node-mysql-libmysqlclient 和 node-db-mysql 那样滥用 OS 线程池玩阻塞通信），很是奇怪

agentzh：貌似 node-mysql 的作者真不在乎性能？对于 100KB 的大结果集查询，并且命中 MySQL 查询缓存时，node-mysql + node-generic-pool 的性能是最差的，甚至不如 php-fpm + php-mysql. 我的 nodejs 脚本在这里：http://t.cn/zO9bEgl 哪位 NodeJS 专家帮我把把脉？使用的各组件都是当前的最新版本。

agentzh：对于单行的小结果集查询，node-mysql + node-generic-pool 相比 php-fpm + php-mysql 还是有性能优势的，rps 高了一倍的样子，绝对值也有差不多 1000 rps，但和 ngx_openresty 的组件相比，貌似还有些差距 下图中的测试数据仍然来自 Amazon EC2 Small 实例组成的测试集群。

agentzh：ngx_srcache + ngx_memc 这种缓存的效率看来还确实不错，比如 100KB mysql 大结果集查询在缓存命中时的情况添加进了下面这张图中（黄色曲线）。图中列出的其他所有东西，比如 lua, php, nodejs 都可以很方便地享受到 ngx_srcache 的缓存服务

agentzh：既然刚才给出了 100KB 大结果集的结果，那么不妨再 show 一下 ngx_srcache + ngx_memc 对于单行小结果集 mysql 查询在 4 台 memcached 节点组成的分布式缓存命中时的 rps 随并发度的变化。我们看到，只比 ngx_drizzle 略有提升，确实已经快到天花板了。

agentzh：测试代码都公开了：https://github.com/agentzh/mysql-driver-benchmark
测试数据使用的是 MySQL 官方提供的 World 样例数据库，同时测试环境是 Amazon EC2 Small 实例（1 台 web 机，4 台 mysql 机，1 台运行 weighttp 测试工具）。欢迎指出任何不公平的地方 :)

5