先看一个最简单的超高性能 hello world http 服务器：
require "socket"
s = TCPServer.new '127.0.0.1', 3000
s.listen 10000
loop do
io = s.accept
content = 'hello world'
io << "HTTP/1.1 200 OK
Content-Type: text/html; utf-8
Connection: close
Content-Length: #{content.size}
#{content}"
io.close
end
我的机器上占用内存十多兆，ab 测下大约 10000 request/s, 和 C 写的差别不大，完爆各种 goroutine STM async***... c10k 解决了！... 那到底是什么东西拖慢了服务器的响应呢？
问题 1: 请求解析和响应组装
五花八门的应用服务器做的事情，说白了就是用来解析请求 header 的... rack 提供了这么多工具这么多层，说白了就是用来组装响应 header 的...
如果加上 ruby 写的 http 请求解析，直接就掉到 1000 req/s 的层次去了。所以这部分还是倾向于用 C 去做。这里有两个选择，一个是 thin / mongrel 用的基于状态机的 http parser, 另一个是 eventmachine / nodejs 用的基于事件的 http parser, 不管选哪个，都能比较好的改良性能，还能保持 5000 request/s 左右。
一般模板也有 50000/s 以上的渲染速度，对组装 response 的影响不大...
问题 2: 数据库和外部 service 调用
外部调用延迟都比较大，为了不让服务器被单请求阻塞，需要一个 multiplexing 方案，我们这些一辈子都碰不上 c10k 问题的屌丝，多线程甚至一个 fork 就够了...
改良版 hello world 服务器，unicorn 架构 ...
require "socket"
s = TCPServer.new '127.0.0.1', 3000
s.listen 10000
6.times do
fork {
loop do
io = s.accept
content = 'hello world'
io << "HTTP/1.1 200 OK
Content-Type: text/html; utf-8
Connection: close
Content-Length: #{content.size}
#{content}"
io.close
end
}
end
Process.waitall
10 几年前 aio_ 系列的函数一度被推崇，但现在大家都在踩 aio, 推 epoll / kqueue 了... 但是 kqueue 不能 share 给子进程，epoll 每次只取出 1 个事件，都有它们自己的问题，事件框架包装后又都显得比较慢...
另外顺带提下 prefork eventmachine 进程的简单解决方案: https://gist.github.com/rkh/1102809
问题 3: 框架和中间件
rails dispatch 很慢，解决方案就是页面静态化和 etag rails helper 很慢，解决方案就是页面片段缓存 active record 很慢，解决方案就是对象缓存 devise 很慢，解决方案就是不用 devise ...
毕竟加点缓存有 20 req/s 就已经能撑起巨大流量的应用了...
问题 4+: 操作系统，网络，浏览器，协议等等非应用服务器的因素...
igvita 刚整的 slides, 比这个帖子有价值多了... http://www.igvita.com/slides/2013/fluent-perfcourse.pdf
还有这本新书，趁免费赶紧看呀! http://chimera.labs.oreilly.com/books/1230000000545/index.html
- linux 内核 3.2+ 有对付丢包的新算法 PRR (Proportional Rate Reduction)
- linux 内核 3.5+ 用了 CoDel 算法可以降低 TCP 连接的延迟。
- linux 内核 3.7+ 用了 TFO (TCP fast open, 在 SYN 里附带数据) 可以降低 TCP 握手的影响。
- nginx 开了 SPDY / HTTP2.0 可以并发发送 header 和 data 降低延迟。
- congression window
-
sysctl net.ipv4.tcp_window_scaling. - SSR
sysctl net.ipv4.tcp_slow_start_after_idle - BDP (Bandwidth-delay product)
ss --options --extended --memory --processes --inf- 大韩民国光纤到户，带宽世界第一... ...
好文，深入潜出，但是感觉好像有点意犹未尽，貌似没有写完就收尾了？
问题 2 中的代码例子，跟 aio_ 系列函数，以及 epoll / kqueue 的关联？还有 prefork eventmachine 的性能情况如何？
... 随便写了点东西，主要集中在 hello world... 意犹未尽是因为展开就是各种大坑啊...
#3 楼 @goinaction aio 和 epoll 不是一回事，aio 是通过 callback 的方式做 read / write, 要用新开线程的，好处是对应函数在 posix 标准里。epoll 和 kqueue 是不开新线程，就没有 aio 复制栈/同步/切换 CPU 的开销。
我们知道 unix 的一大特色就是什么都是文件，文件描述符 (fd) 可以用一个整数来表示打开的文件，socket, 管道等等东西。进程中的文件描述符 fork 以后还能用，例如 working with unix process 里有用 ruby 启动 python 进程然后在 python 中用 ruby 打开的 fd 的例子。
block 的意思是在等待 read / write / accept 这些 io 操作的时候，进程是 sleep 的。如果用 nonblock 的文件描述符：fcntl(sock, F_SETFL, O_NONBLOCK), 你就可以：A. 写个无限循环去不断的问"是不是好了", 这样就会把 CPU 吃到 100% 还不如用 block 操作，B. 做别的事情，但可以做什么就需要一个调度机制，现在可以选择的有线程调度或者事件队列调度，线程调度就是 aio, 事件队列调度就是 epoll / kqueue.
附带说一下 ruby 的 io 的神奇的地方：ruby 的 io 正常来说是阻塞整个进程的，但一开新线程，它就自动变成非阻塞了...
#4 楼 @krazy 没用过，看它的实现应该是 libev 的包装？现在的事件框架太多了吧 libev, libevent, gevent, libuv ...
#15 楼 @luikore redis 用了几百行就实现了个事件库：https://github.com/antirez/redis/blob/unstable/src/ae.c 这个也值得一看
伟大啊。每次都能耐心地给我们出好文。 没想到 ruby 光跑 http 也那么快 以前我自己光跑 eventmachine 的时候很快 10000req/s 后面发现解析 header 的字符串处理才是关键性能问。还看到有个人写了一个 C 的 header 处理的代码。
epoll 省内存这样说起来也没啥用了
好比让我取舍
进程消耗 1G 内存，但是很快，很容易些。 （容易，但是能解决问题，成本能接受） 进程消耗 100M，很快，但是不是很容易。 （不容易，但是解决问题，成本很低）
C++ 的坑之一是 calling convention.
calling convention 是类似于协议的东西，函数是怎么调用的，被调用方是怎么获取参数的，参数放在哪个寄存器，是顺序还是逆序推到栈上都有约定。编译器往往有扩展，可以用 __cdecl, __fastcall 等方式去指定一个函数的 calling convention.
C 没有函数重载，C++ 有函数重载，所以 C++ 不能用 C 的 calling convention 而是自己另外弄了一套。这就造成两个东西一模一样但是编译出来的东西却不一样... 下面是一个最简单的 ruby ext, 如果保存为 .c 就可以，保存成 .cxx 或者 .cpp 就编译不过去
#include <ruby.h>
VALUE helloworld(VALUE self) {
printf("hello world\n");
return Qnil;
}
void Init_helloworld() {
rb_define_method(rb_cObject, "helloworld", helloworld, 0);
}
如果在 C++ 里，就要声明这个函数是 C call:
...
extern "C" VALUE helloworld(VALUE self) {
...
或者用一个宏转换类型：
rb_define_method(rb_cObject, "helloworld", RUBY_METHOD_FUNC(helloworld), 0);
坑之二是自动生成析构函数调用，例如
{
std::vector<int> vec; // 一个 vector 对象, 会动态分配内存的
...
// 这里会在编译期自动生成 vec 的析构函数调用, 把 vec 动态分配的内存释放掉
}
如果在中间插入了 ruby 方的调用，会出现一个跳出去的 long jump
{
std::vector<int> vec;
rb_eval_string("raise 'hello world'"); // 跳出去了, 下面的代码包括自动析构也不会执行了
...
}
所以要用 rb_protect 之类的包装起来
{
std::vector<int> vec;
int state;
rb_eval_string_protect("raise 'hello world'", &state);
if (state) ...
}
坑之三是异常，ruby 出现严重错误还会列出一个 segfault 的报告，报告中会包含当前的调用栈可以帮助排除问题。但如果在代码中扔一个 C++ 异常但忘记捕获
throw std::runtime_error("hello world");
程序就会报一个 "libc++ abi error" 退出，其它什么都不说了... 除非用 ulimit -c unlimited 再用 gdb / lldb 打开 image, 否则是看不到异常栈的...
坑之四是 std::iterator 等模板对象没法在 gdb / lldb 中查看，因为 C++ template 是编译期的，debugger 在运行时不能知道最终生成的是什么...
for (auto i = vec.begin(); i != vec.end(); i++) {
// 你可以在这里插入一个断点, 但你看不到 i 是什么, 也不能对 i 做运算...
}
但往往这些坑必须去踩... C 并没有标准的数据结构/容器可以用，而 C++ 的标准库有各种实现，经常不得不去用，要么就是自己造一套或者是用一些让你不太放心的 ...
什么语言的语法最复杂变态？不是 C++, 是 Objective-C++ ...
坑之五... 就是 Objective-C++ 各种诱惑你去用...
Objective-C
id a = @"hello world";
id b = 3; // :(
Objective-C++
auto a = @"hello world";
auto b = 3; // (:
