月份：2016年4月

[转]TokuDB的特点验证

原文地址：http://www.tuicool.com/articles/vAbIFjb

随着数据量越来越大，越来越频繁的遇到需要进行结构拆分的情况，每一次拆分都耗时很久，并且需要多方配合，非常的不想搞这个事情。于是在@zolker的提醒下想到了13年开源tokuDB，来解决我们迫在眉睫的容量问题。

坊间流传tokuDB有如下几个看着令人垂涎欲滴的特点，正好符合我们实际环境的需求，故针对每个特点进行了针对性测试：

1、高压缩比，官方宣称可以达到1：12。

2、高insert性能，官方称至少比innodb高9倍。

3、可以在线添加索引和字段，速度快。

（前提：由于是为了解决线上的实际问题，故本次验证并不会按照严格的测试规范进行，所得数据也不是tokuDB的极限数据，只是在实际业务上的表现）

高压缩比：

原有数据库容量1126G，使用tokudb之后，压缩到76G，压缩比达到惊人的 14倍 。

高insert性能：

简单比较追同步的性能，同时在innodb和tokudb上阻塞同步3分钟，然后观察追同步的性能（不代表最大性能，因为会受限于mysql单线程追同步的瓶颈。io不会被充分利用到）

基本环境为SAS服务器，12*300G 15000转SAS盘，BP size相同。

可以明显看到在不改变基本配置，不增加多线程复制的情况下，tokudb的追同步性能高于innodb，大概在 1.9倍 。

在线添加字段和索引：

测试目标表为425MB，所在服务器均为10块盘做RAID5的SSD服务器。

从下图可以看出

  • 添加索引，innodb快，tokudb慢
  • 删除索引，innodb快，tokudb超快
  • 增加字段，innodb慢，tokudb超快
  • 删除字段，innodb慢，tokudb超快

TokuDB在在线DDL操作的时候相对InnoDB有较大的优势。在索引方面，删除索引基本瞬间完成。在字段方案，添加/删除字段基本都是瞬间完成。

具体我们可以看下面的操作记录。

CREATE TABLE `timeline_1009` (
  `uid` bigint(16) unsigned NOT NULL,
  `vflag` tinyint(4) unsigned NOT NULL DEFAULT '0',
  `status_id` bigint(16) unsigned NOT NULL,
  `source` int(6) unsigned NOT NULL DEFAULT '0',
  `fflag` int(6) unsigned NOT NULL DEFAULT '0',
  `mflag` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`uid`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8 ROW_FORMAT=TOKUDB_LZMA;

InnoDB操作记录：

>create index idx_flag on timeline_1009 (mflag);
Query OK, 0 rows affected (36.48 sec)

>drop index idx_flag on timeline_1009;
Query OK, 0 rows affected (0.29 sec)

>alter table timeline_1009 add column test_flag tinyint;
Query OK, 4549087 rows affected (28.64 sec)

>alter table timeline_1009 drop column test_flag;           
Query OK, 4549087 rows affected (27.29 sec)

TokuDB操作记录：

>create index idx_flag on timeline_1009(mflag);
Query OK, 0 rows affected (56.56 sec)

>drop index idx_flag on timeline_1009;
Query OK, 0 rows affected (0.05 sec)

>alter table timeline_1009 add column test_flag tinyint;
Query OK, 0 rows affected (0.01 sec)

>alter table timeline_1009 drop column test_flag;           
Query OK, 0 rows affected (0.00 sec)

innodb添加字段的时候会建立一个temp table，修改表结构后，会删除原表，并将临时表rename回原名字，所以就相当于对表进行了一次optimization，清理各种碎片，这也就是为什么add column的时候会有百万级别的rows affected。但是可以很明显的看到tokudb的rows affected为0，推测是tokudb在添加字段的时候，并不会采用innodb的方法。从官网的文档中获得的信息是，TokuDB会将添加字段的工作放在后台执行，而其快速的原因是将B-tree改为了Fractal-tree，其将随机IO替换为了顺序IO。领用Fractal-tree的特性，将HCAD命令广播到所有行上，而不是想InnoDB那样，需要open table并消耗很多的内存资源。

以上都是TokuDB的特点，接下来我们看看其对CPU、IOPS和RT的影响。以上3点是影响服务器负载和对外提供服务质量的关键数据。

测试背景，相同的slave，只不过引擎不通，在同一个时间点抓取数据，理论上认为承担的服务量相等。

CPU消耗：

理论上经过大压缩比的数据库一定会比较消耗cpu的usr态，果然从下图中我们可以看出，tokudb比innodb对usr态的cpu消耗要多，平均在 2倍 左右。

IOPS消耗：

根据官方文档的说明，相同QPS的情况下，tokudb应该比innodb消耗更少的iops。我们从下面两个图可以看出，读的IOPS并没有太大的差别，但是写的IOPS innodb比tokudb平均多消耗了 5.5倍 。

RT响应时间：

在响应时间上，由于整体数据库的size变小了，测试目标库innodb版本743G，tokudb版本61G。相对于BP=30G来说，明显tokudb更占优势。但是由于tokkudb的数据是经过高压缩的，在响应时间上应该还会多一部分解压的时间消耗，所以最终结果不好确认。

从测试结果看，tokudb的响应时间明显高于innodb的，其平均值大概高 2.2倍 。看来如果上了tokudb，响应时间是需要付出的代价。

总结： 

TokuDB的优点：1、高压缩比 2、高insert性能 3、增删字段秒级。

TokuDB的缺点：1、cpu usr态消耗高 2、响应时间变长。

总体来说，TokuDB的特性非常的吸引人，能解决我们很棘手的问题。但是，看上去很美的东西，一定会有坑存在，排雷将是我们下一步的重点工作，这也是决定TokuDB到底能不能真正在线上使用的关键。

[转]NGINX引入线程池 性能提升9倍

本篇文字还没深入理解，做个标记。

原文地址：https://yq.aliyun.com/articles/26635

摘要1. 引言 正如我们所知，NGINX采用了异步、事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。为此，NGINX工作在非阻塞的socket模式下，并使用了epoll 和 kqueue这样有效的方法…

1. 引言

正如我们所知，NGINX采用了异步、事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。为此，NGINX工作在非阻塞的socket模式下，并使用了epoll 和 kqueue这样有效的方法。

因为满负载进程的数量很少（通常每核CPU只有一个）而且恒定，所以任务切换只消耗很少的内存，而且不会浪费CPU周期。通过NGINX本身的实例，这种方法的优点已经为众人所知。NGINX可以非常好地处理百万级规模的并发请求。

0622000.jpg

每个进程都消耗额外的内存，而且每次进程间的切换都会消耗CPU周期并丢弃CPU高速缓存中的数据。

但是，异步、事件驱动方法仍然存在问题。或者，我喜欢将这一问题称为“敌兵”，这个敌兵的名字叫阻塞（blocking）。不幸的是，很多第三方模块使用了阻塞调用，然而用户（有时甚至是模块的开发者）并不知道阻塞的缺点。阻塞操作可以毁掉NGINX的性能，我们必须不惜一切代价避免使用阻塞。

即使在当前官方的NGINX代码中，依然无法在全部场景中避免使用阻塞，NGINX1.7.11中实现的线程池机制解决了这个问题。我们将在后面讲述这个线程池是什么以及该如何使用。现在，让我们先和我们的“敌兵”进行一次面对面的碰撞。

2. 问题

首先，为了更好地理解这一问题，我们用几句话说明下NGINX是如何工作的。

通常情况下，NGINX是一个事件处理器，即一个接收来自内核的所有连接事件的信息，然后向操作系统发出做什么指令的控制器。实际上，NGINX干了编排操作系统的全部脏活累活，而操作系统做的是读取和发送字节这样的日常工作。所以，对于NGINX来说，快速和及时的响应是非常重要的。

0622001.png

工作进程监听并处理来自内核的事件

事件可以是超时、socket读写就绪的通知，或者发生错误的通知。NGINX接收大量的事件，然后一个接一个地处理它们，并执行必要的操作。因此，所有的处理过程是通过一个线程中的队列，在一个简单循环中完成的。NGINX从队列中取出一个事件并对其做出响应，比如读写socket。在多数情况下，这种方式是非常快的（也许只需要几个CPU周期，将一些数据复制到内存中），NGINX可以在一瞬间处理掉队列中的所有事件。

0622002.jpg

所有处理过程是在一个简单的循环中，由一个线程完成

但是，如果NGINX要处理的操作是一些又长又重的操作，又会发生什么呢？整个事件处理循环将会卡住，等待这个操作执行完毕。

因此，所谓“阻塞操作”是指任何导致事件处理循环显著停止一段时间的操作。操作可以由于各种原因成为阻塞操作。例如，NGINX可能因长时间、CPU密集型处理，或者可能等待访问某个资源（比如硬盘，或者一个互斥体，亦或要从处于同步方式的数据库获得相应的库函数调用等）而繁忙。关键是在处理这样的操作期间，工作进程无法做其他事情或者处理其他事件，即使有更多的可用系统资源可以被队列中的一些事件所利用。

我们来打个比方，一个商店的营业员要接待他面前排起的一长队顾客。队伍中的第一位顾客想要的某件商品不在店里而在仓库中。这位营业员跑去仓库把东西拿来。现在整个队伍必须为这样的配货方式等待数个小时，队伍中的每个人都很不爽。你可以想见人们的反应吧？队伍中每个人的等待时间都要增加这些时间，除非他们要买的东西就在店里。

0622003.jpg

队伍中的每个人不得不等待第一个人的购买

在NGINX中会发生几乎同样的情况，比如当读取一个文件的时候，如果该文件没有缓存在内存中，就要从磁盘上读取。从磁盘（特别是旋转式的磁盘）读取是很慢的,而当队列中等待的其他请求可能不需要访问磁盘时，它们也得被迫等待。导致的结果是，延迟增加并且系统资源没有得到充分利用。

0622004.png

一个阻塞操作足以显著地延缓所有接下来的操作

一些操作系统为读写文件提供了异步接口，NGINX可以使用这样的接口（见AIO指令）。FreeBSD就是个很好的例子。不幸的是，我们不能在Linux上得到相同的福利。虽然Linux为读取文件提供了一种异步接口，但是存在明显的缺点。其中之一是要求文件访问和缓冲要对齐，但NGINX很好地处理了这个问题。但是，另一个缺点更糟糕。异步接口要求文件描述符中要设置O_DIRECT标记，就是说任何对文件的访问都将绕过内存中的缓存，这增加了磁盘的负载。在很多场景中，这都绝对不是最佳选择。

为了有针对性地解决这一问题，在NGINX 1.7.11中引入了线程池。默认情况下，NGINX+还没有包含线程池，但是如果你想试试的话，可以联系销售人员，NGINX+ R6是一个已经启用了线程池的构建版本。

现在，让我们走进线程池，看看它是什么以及如何工作的。

3. 线程池

让我们回到那个可怜的，要从大老远的仓库去配货的售货员那儿。这回，他已经变聪明了（或者也许是在一群愤怒的顾客教训了一番之后，他才变得聪明的？），雇用了一个配货服务团队。现在，当任何人要买的东西在大老远的仓库时，他不再亲自去仓库了，只需要将订单丢给配货服务，他们将处理订单，同时，我们的售货员依然可以继续为其他顾客服务。因此，只有那些要买仓库里东西的顾客需要等待配货，其他顾客可以得到即时服务。

0622005.jpg

传递订单给配货服务不会阻塞队伍

对NGINX而言，线程池执行的就是配货服务的功能。它由一个任务队列和一组处理这个队列的线程组成。
当工作进程需要执行一个潜在的长操作时，工作进程不再自己执行这个操作，而是将任务放到线程池队列中，任何空闲的线程都可以从队列中获取并执行这个任务。

0622006.jpg

工作进程将阻塞操作卸给线程池

那么，这就像我们有了另外一个队列。是这样的，但是在这个场景中，队列受限于特殊的资源。磁盘的读取速度不能比磁盘产生数据的速度快。不管怎么说，至少现在磁盘不再延误其他事件，只有访问文件的请求需要等待。

“从磁盘读取”这个操作通常是阻塞操作最常见的示例，但是实际上，NGINX中实现的线程池可用于处理任何不适合在主循环中执行的任务。

目前，卸载到线程池中执行的两个基本操作是大多数操作系统中的read()系统调用和Linux中的sendfile()。接下来，我们将对线程池进行测试（test）和基准测试（benchmark），在未来的版本中，如果有明显的优势，我们可能会卸载其他操作到线程池中。

4. 基准测试

现在让我们从理论过度到实践。我们将进行一次模拟基准测试（synthetic benchmark），模拟在阻塞操作和非阻塞操作的最差混合条件下，使用线程池的效果。

另外，我们需要一个内存肯定放不下的数据集。在一台48GB内存的机器上，我们已经产生了每文件大小为4MB的随机数据，总共256GB，然后配置NGINX，版本为1.9.0。

配置很简单：

worker_processes 16;

events {
    accept_mutex off;
}

http {
    include mime.types;
    default_type application/octet-stream;

    access_log off;
    sendfile on;
    sendfile_max_chunk 512k;

    server {
        listen 8000;

        location / {
            root /storage;
        }
    }
}

如上所示，为了达到更好的性能，我们调整了几个参数：禁用了logging和accept_mutex，同时，启用了sendfile并设置了sendfile_max_chunk的大小。最后一个指令可以减少阻塞调用sendfile()所花费的最长时间，因为NGINX不会尝试一次将整个文件发送出去，而是每次发送大小为512KB的块数据。

这台测试服务器有2个Intel Xeon E5645处理器（共计：12核、24超线程）和10-Gbps的网络接口。磁盘子系统是由4块西部数据WD1003FBYX 磁盘组成的RAID10阵列。所有这些硬件由Ubuntu服务器14.04.1 LTS供电。

0622007.jpg

为基准测试配置负载生成器和NGINX

客户端有2台服务器，它们的规格相同。在其中一台上，在wrk中使用Lua脚本创建了负载程序。脚本使用200个并行连接向服务器请求文件，每个请求都可能未命中缓存而从磁盘阻塞读取。我们将这种负载称作随机负载。

在另一台客户端机器上，我们将运行wrk的另一个副本，使用50个并行连接多次请求同一个文件。因为这个文件将被频繁地访问，所以它会一直驻留在内存中。在正常情况下，NGINX能够非常快速地服务这些请求，但是如果工作进程被其他请求阻塞的话，性能将会下降。我们将这种负载称作恒定负载。

性能将由服务器上ifstat监测的吞吐率（throughput）和从第二台客户端获取的wrk结果来度量。

现在，没有使用线程池的第一次运行将不会带给我们非常振奋的结果：

% ifstat -bi eth2
eth2
Kbps in  Kbps out
5531.24  1.03e+06
4855.23  812922.7
5994.66  1.07e+06
5476.27  981529.3
6353.62  1.12e+06
5166.17  892770.3
5522.81  978540.8
6208.10  985466.7
6370.79  1.12e+06
6123.33  1.07e+06

如上所示，使用这种配置，服务器产生的总流量约为1Gbps。从下面所示的top输出，我们可以看到，工作进程的大部分时间花在阻塞I/O上（它们处于top的D状态）：

top - 10:40:47 up 11 days,  1:32,  1 user,  load average: 49.61, 45.77 62.89
Tasks: 375 total,  2 running, 373 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 67.7 id, 31.9 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  49453440 total, 49149308 used,   304132 free,    98780 buffers
KiB Swap: 10474236 total,    20124 used, 10454112 free, 46903412 cached Mem

  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
 4639 vbart    20   0   47180  28152     496 D   0.7  0.1  0:00.17 nginx
 4632 vbart    20   0   47180  28196     536 D   0.3  0.1  0:00.11 nginx
 4633 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.11 nginx
 4635 vbart    20   0   47180  28136     480 D   0.3  0.1  0:00.12 nginx
 4636 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.14 nginx
 4637 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.10 nginx
 4638 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
 4640 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
 4641 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
 4642 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.11 nginx
 4643 vbart    20   0   47180  28276     536 D   0.3  0.1  0:00.29 nginx
 4644 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.11 nginx
 4645 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.17 nginx
 4646 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
 4647 vbart    20   0   47180  28208     532 D   0.3  0.1  0:00.17 nginx
 4631 vbart    20   0   47180    756     252 S   0.0  0.1  0:00.00 nginx
 4634 vbart    20   0   47180  28208     536 D   0.0  0.1  0:00.11 nginx
 4648 vbart    20   0   25232   1956    1160 R   0.0  0.0  0:00.08 top
25921 vbart    20   0  121956   2232    1056 S   0.0  0.0  0:01.97 sshd
25923 vbart    20   0   40304   4160    2208 S   0.0  0.0  0:00.53 zsh

在这种情况下，吞吐率受限于磁盘子系统，而CPU在大部分时间里是空闲的。从wrk获得的结果也非常低：

Running 1m test @ http://192.0.2.1:8000/1/1/1
  12 threads and 50 connections
  Thread Stats   Avg    Stdev     Max  +/- Stdev
    Latency     7.42s  5.31s   24.41s   74.73%
    Req/Sec     0.15    0.36     1.00    84.62%
  488 requests in 1.01m, 2.01GB read
Requests/sec:      8.08
Transfer/sec:     34.07MB

请记住，文件是从内存送达的！第一个客户端的200个连接创建的随机负载，使服务器端的全部的工作进程忙于从磁盘读取文件，因此产生了过大的延迟，并且无法在合理的时间内处理我们的请求。

现在，我们的线程池要登场了。为此，我们只需在location块中添加aio threads指令：

location / {
    root /storage;
    aio threads;
}

接着，执行NGINX reload重新加载配置。

然后，我们重复上述的测试：

% ifstat -bi eth2
eth2
Kbps in  Kbps out
60915.19  9.51e+06
59978.89  9.51e+06
60122.38  9.51e+06
61179.06  9.51e+06
61798.40  9.51e+06
57072.97  9.50e+06
56072.61  9.51e+06
61279.63  9.51e+06
61243.54  9.51e+06
59632.50  9.50e+06

现在，我们的服务器产生的流量是9.5Gbps，相比之下，没有使用线程池时只有约1Gbps！

理论上还可以产生更多的流量，但是这已经达到了机器的最大网络吞吐能力，所以在这次NGINX的测试中，NGINX受限于网络接口。工作进程的大部分时间只是休眠和等待新的事件（它们处于top的S状态）：

top - 10:43:17 up 11 days,  1:35,  1 user,  load average: 172.71, 93.84, 77.90
Tasks: 376 total,  1 running, 375 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.2 us,  1.2 sy,  0.0 ni, 34.8 id, 61.5 wa,  0.0 hi,  2.3 si,  0.0 st
KiB Mem:  49453440 total, 49096836 used,   356604 free,    97236 buffers
KiB Swap: 10474236 total,    22860 used, 10451376 free, 46836580 cached Mem

  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
 4654 vbart    20   0  309708  28844     596 S   9.0  0.1  0:08.65 nginx
 4660 vbart    20   0  309748  28920     596 S   6.6  0.1  0:14.82 nginx
 4658 vbart    20   0  309452  28424     520 S   4.3  0.1  0:01.40 nginx
 4663 vbart    20   0  309452  28476     572 S   4.3  0.1  0:01.32 nginx
 4667 vbart    20   0  309584  28712     588 S   3.7  0.1  0:05.19 nginx
 4656 vbart    20   0  309452  28476     572 S   3.3  0.1  0:01.84 nginx
 4664 vbart    20   0  309452  28428     524 S   3.3  0.1  0:01.29 nginx
 4652 vbart    20   0  309452  28476     572 S   3.0  0.1  0:01.46 nginx
 4662 vbart    20   0  309552  28700     596 S   2.7  0.1  0:05.92 nginx
 4661 vbart    20   0  309464  28636     596 S   2.3  0.1  0:01.59 nginx
 4653 vbart    20   0  309452  28476     572 S   1.7  0.1  0:01.70 nginx
 4666 vbart    20   0  309452  28428     524 S   1.3  0.1  0:01.63 nginx
 4657 vbart    20   0  309584  28696     592 S   1.0  0.1  0:00.64 nginx
 4655 vbart    20   0  30958   28476     572 S   0.7  0.1  0:02.81 nginx
 4659 vbart    20   0  309452  28468     564 S   0.3  0.1  0:01.20 nginx
 4665 vbart    20   0  309452  28476     572 S   0.3  0.1  0:00.71 nginx
 5180 vbart    20   0   25232   1952    1156 R   0.0  0.0  0:00.45 top
 4651 vbart    20   0   20032    752     252 S   0.0  0.0  0:00.00 nginx
25921 vbart    20   0  121956   2176    1000 S   0.0  0.0  0:01.98 sshd
25923 vbart    20   0   40304   3840    2208 S   0.0  0.0  0:00.54 zsh

如上所示，基准测试中还有大量的CPU资源剩余。

wrk的结果如下：

Running 1m test @ http://192.0.2.1:8000/1/1/1
  12 threads and 50 connections
  Thread Stats   Avg      Stdev     Max  +/- Stdev
    Latency   226.32ms  392.76ms   1.72s   93.48%
    Req/Sec    20.02     10.84    59.00    65.91%
  15045 requests in 1.00m, 58.86GB read
Requests/sec:    250.57
Transfer/sec:      0.98GB

服务器处理4MB文件的平均时间从7.42秒降到226.32毫秒（减少了33倍），每秒请求处理数提升了31倍（250 vs 8）！

对此，我们的解释是请求不再因为工作进程被阻塞在读文件，而滞留在事件队列中，等待处理，它们可以被空闲的进程处理掉。只要磁盘子系统能做到最好，就能服务好第一个客户端上的随机负载，NGINX可以使用剩余的CPU资源和网络容量，从内存中读取，以服务于上述的第二个客户端的请求。

5. 依然没有银弹

在抛出我们对阻塞操作的担忧并给出一些令人振奋的结果后，可能大部分人已经打算在你的服务器上配置线程池了。先别着急。

实际上，最幸运的情况是，读取和发送文件操作不去处理缓慢的硬盘驱动器。如果我们有足够多的内存来存储数据集，那么操作系统将会足够聪明地在被称作“页面缓存”的地方，缓存频繁使用的文件。

“页面缓存”的效果很好，可以让NGINX在几乎所有常见的用例中展示优异的性能。从页面缓存中读取比较快，没有人会说这种操作是“阻塞”。而另一方面，卸载任务到一个线程池是有一定开销的。

因此，如果内存有合理的大小并且待处理的数据集不是很大的话，那么无需使用线程池，NGINX已经工作在最优化的方式下。

卸载读操作到线程池是一种适用于非常特殊任务的技术。只有当经常请求的内容的大小，不适合操作系统的虚拟机缓存时，这种技术才是最有用的。至于可能适用的场景，比如，基于NGINX的高负载流媒体服务器。这正是我们已经模拟的基准测试的场景。

我们如果可以改进卸载读操作到线程池，将会非常有意义。我们只需要知道所需的文件数据是否在内存中，只有不在内存中时，读操作才应该卸载到一个单独的线程中。

再回到售货员那个比喻的场景中，这回，售货员不知道要买的商品是否在店里，他必须要么总是将所有的订单提交给配货服务，要么总是亲自处理它们。

人艰不拆，操作系统缺少这样的功能。第一次尝试是在2010年，人们试图将这一功能添加到Linux作为fincore()系统调用，但是没有成功。后来还有一些尝试，是使用RWF_NONBLOCK标记作为preadv2()系统调用来实现这一功能（详情见LWN.net上的非阻塞缓冲文件读取操作和异步缓冲读操作）。但所有这些补丁的命运目前还不明朗。悲催的是，这些补丁尚没有被内核接受的主要原因，貌似是因为旷日持久的撕逼大战（bikeshedding）。

另一方面，FreeBSD的用户完全不必担心。FreeBSD已经具备足够好的异步读取文件接口，我们应该用这个接口而不是线程池。

6. 配置线程池

所以，如果你确信在你的场景中使用线程池可以带来好处，那么现在是时候深入了解线程池的配置了。

线程池的配置非常简单、灵活。首先，获取NGINX 1.7.11或更高版本的源代码，使用--with-threads配置参数编译。在最简单的场景中，配置看起来很朴实。我们只需要在http、 server，或者location上下文中包含aio threads指令即可：

aio threads;

这是线程池的最简配置。实际上的精简版本示例如下：

thread_pool default threads=32 max_queue=65536;
aio threads=default;

这里定义了一个名为“default”，包含32个线程，任务队列最多支持65536个请求的线程池。如果任务队列过载，NGINX将输出如下错误日志并拒绝请求：

thread pool "NAME" queue overflow: N tasks waiting

错误输出意味着线程处理作业的速度有可能低于任务入队的速度了。你可以尝试增加队列的最大值，但是如果这无济于事，那么这说明你的系统没有能力处理如此多的请求了。

正如你已经注意到的，你可以使用thread_pool指令，配置线程的数量、队列的最大值，以及线程池的名称。最后要说明的是，可以配置多个独立的线程池，将它们置于不同的配置文件中，用做不同的目的：

http {
    thread_pool one threads=128 max_queue=0;
    thread_pool two threads=32;

    server {
        location /one {
            aio threads=one;
        }

        location /two {
            aio threads=two;
        }
    }
…
}

如果没有指定max_queue参数的值，默认使用的值是65536。如上所示，可以设置max_queue为0。在这种情况下，线程池将使用配置中全部数量的线程，尽可能地同时处理多个任务；队列中不会有等待的任务。

现在，假设我们有一台服务器，挂了3块硬盘，我们希望把该服务器用作“缓存代理”，缓存后端服务器的全部响应信息。预期的缓存数据量远大于可用的内存。它实际上是我们个人CDN的一个缓存节点。毫无疑问，在这种情况下，最重要的事情是发挥硬盘的最大性能。

我们的选择之一是配置一个RAID阵列。这种方法毁誉参半，现在，有了NGINX，我们可以有其他的选择：

# 我们假设每块硬盘挂载在相应的目录中：/mnt/disk1、/mnt/disk2、/mnt/disk3

proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:256m max_size=1024G
                 use_temp_path=off;
proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:256m max_size=1024G
                 use_temp_path=off;
proxy_cache_path /mnt/disk3 levels=1:2 keys_zone=cache_3:256m max_size=1024G
                 use_temp_path=off;

thread_pool pool_1 threads=16;
thread_pool pool_2 threads=16;
thread_pool pool_3 threads=16;

split_clients $request_uri $disk {
    33.3%     1;
    33.3%     2;
    *         3;
}

location / {
    proxy_pass http://backend;
    proxy_cache_key $request_uri;
    proxy_cache cache_$disk;
    aio threads=pool_$disk;
    sendfile on;
}

在这份配置中，使用了3个独立的缓存，每个缓存专用一块硬盘，另外，3个独立的线程池也各自专用一块硬盘。

缓存之间（其结果就是磁盘之间）的负载均衡使用split_clients模块，split_clients非常适用于这个任务。

在 proxy_cache_path指令中设置use_temp_path=off，表示NGINX会将临时文件保存在缓存数据的同一目录中。这是为了避免在更新缓存时，磁盘之间互相复制响应数据。

这些调优将带给我们磁盘子系统的最大性能，因为NGINX通过单独的线程池并行且独立地与每块磁盘交互。每块磁盘由16个独立线程和读取和发送文件专用任务队列提供服务。

我敢打赌，你的客户喜欢这种量身定制的方法。请确保你的磁盘也持有同样的观点。

这个示例很好地证明了NGINX可以为硬件专门调优的灵活性。这就像你给NGINX下了一道命令，让机器和数据用最佳姿势来搞基。而且，通过NGINX在用户空间中细粒度的调优，我们可以确保软件、操作系统和硬件工作在最优模式下，尽可能有效地利用系统资源。

7. 总结

综上所述，线程池是一个伟大的功能，将NGINX推向了新的性能水平，除掉了一个众所周知的长期危害——阻塞——尤其是当我们真正面对大量内容的时候。

甚至，还有更多的惊喜。正如前面提到的，这个全新的接口，有可能没有任何性能损失地卸载任何长期阻塞操作。NGINX在拥有大量的新模块和新功能方面，开辟了一方新天地。许多流行的库仍然没有提供异步非阻塞接口，此前，这使得它们无法与NGINX兼容。我们可以花大量的时间和资源，去开发我们自己的无阻塞原型库，但这么做始终都是值得的吗？现在，有了线程池，我们可以相对容易地使用这些库，而不会影响这些模块的性能。

[转]HTTP/2 对 Web 性能的影响

【上】

一.前言

HTTP/2 于 2015 年 5 月正式推出。自诞生以来，它就一直在影响着网络性能最佳实践。在本篇文章中，我们将讨论 HTTP/2 的二进制帧、延迟削减、潜在利弊以及相应的应对措施。
超文本传输协议（简称 HTTP）正是万维网与网络空间的基石。现在，HTTP 听起来已经有些过时，毕竟该协议中使用最广泛的版本——HTTP 1.1，已快迎来它的第二十个年头。时光回溯到1997年，HTTP1.1刚刚出现的年代，当时，软驱与调制解调器还是 PC 设备的必备周边产品，Java 也仅仅是一个刚刚崭露头角的、前途一片光明的编程语言。
而今，2015 年 5 月，HTTP/2 正式亮相，致力于解决 HTTP 1.1 在现代网络时代下无法应对的某些重大性能难题。过去一年以来，越来越多的浏览器、Web 服务器、商用代理以及主要内容交付网络开始支持 HTTP/2。
遗憾的是，对于负责编写 Web 代码的开发人员而言，HTTP/2 的过渡工作并不简单，所谓的速度提升也不会自行出现，必要的 Web APM 工具和厂商仍然是当今时代不可或缺的，例如 OneAPM Browser Insight、Newrelic、APPdynamic 等等。
如何才能采用这个新协议打造高性能 Web 应用，该怎样处理那些尚不支持该协议的现有工具——例如 debug 代理工具，这些问题对所有人来说仍是一个挑战。今天的文章将向您介绍 HTTP/2，以及其如何改变 Web 性能的最佳实践。

二.二进制帧：HTTP/2的「基本单位」

HTTP 1.1 的一大优势（至少相较于非安全连接而言）在于其支持在端口 80 的telnet 会话中利用文本与 Web 服务器进行交互：在大多数 Web 服务器上输入 GET/HTTP/1.1，都能返回一个 HTML 文档。由于这是一项文本协议，因此其调试工作相对简单。
相对于 HTTP1.1 这个文本协议，HTTP/2 中的请求与响应则通过二进制帧流的形式来表现，我们将其称为 HTTP/2 RFC 中的「基本协议单位」。每一帧都拥有自己的类型，用于实现不同的作用。考虑到 HTTP 1.1 将会「永远」存在（毕竟 Gopher 协议都还在用呢！），因此 HTTP/2 的作者们要求，HTTP/2 请求的二进制帧都必须被映射到 HTTP 1.1 请求上去，从而确保其向下兼容的能力。
当然，HTTP/2 当中也有一些其他新特性，无法映射至 HTTP 1.1。例如，服务器推送（也叫“缓存推送”）和流重置都是利用二进制帧类型实现的新特性。帧也可以支持优先级排序，允许客户端向服务器发送排序，从而优先处理一部分资产类别。
除了使用 Wireshark 2.0 之外，对个别二进制帧进行查看的最简便方法就是利用谷歌 Chrome 浏览器的 net-internals 标签（在浏览器地址栏中输入chrome://net-internals/#http2）。由于理解大型网页的数据通常比较困难，Rebecca Murphey 特意编写了一款极为实用的可视化工具，从而将其显示在命令行中。
除此之外，这个用于获取资产的协议还可以显示在 Chrome Web 的开发者工具当中–只需右键点击列标题，接着选择「协议」即可：

在谷歌Chrome开发者工具中查看协议类型。
这里列出的所有 HTTP/2 请求都使用通过传输层安全（TLS）建立的安全连接。各主流浏览器都要求 HTTP/2 连接是安全的。这样做是有切实理由的：TLS 的一套称为应用层协议协商（ALPN）的扩展，让服务器知道浏览器支持 HTTP2（除了其他协议以外），从而避免了额外的数据往来。这也能保住那些无法解读 HTTP/2 的服务，例如代理——只看得见传输线路上的加密数据。

三.多路复用减少延迟

HTTP 1.1 的一大问题是延迟，换而言之就是它花在提出请求和接受响应上的时间。随着典型网页中图片数量、JavaScript 和 CSS 的使用量不断增加，这个问题日益严重。每获取一项资产，通常都得新建一个 TCP 连接。
这种需求因为两个理由很重要：每台主机能同时打开的 TCP 连接数受浏览器的限制；新建连接都会引发性能损失。如果物理服务器离用户很远（如：一位新加坡用户向美国东海岸数据中心请求一个页面），延迟会变多。这不是罕见的情况——近期一份报告表示全球 70% 以上的互联网流通都会通过北佛吉尼亚一些不知名的数据中心。
其实对于 Web 页面的优化从前端页面方面反而可能见效比较大，我们都知道页面资源对响应速度的影响是非常巨大的，常见的图片压缩、css 聚合都可以帮助我们优化 Web 性能，问题就是如何找到相应的页面慢加载元素。
这也是国内外 APM 行业兴起的最初原因之一。
拿国内的一个页面优化工具 Browser Insight 举例，这种通过页面插码来获取真实用户体验的 APM 工具，虽然部署起来有些麻烦，但是这类的工具也没有更好的部署方法，手动的反而更稳定。

HTTP 1.1 提供了多种方案以解决延迟问题，包括通道传输与 Keep-Alive header。然而，通道传输从未被广泛采纳过，而 Keep-Alive header 则饱受 head line 阻塞的困扰：只有在当前请求必须彻底完成后，下一请求才能被发送出去。
在 HTTP/2 当中，多条资产请求可以重复利用单一 TCP 连接。与使用 Keep-Alive header 的 HTTP 1.1 请求不同，HTTP/2 的请求与响应二进制帧以交错方式进行，线头阻塞问题也不复存在。建立连接的成本（即著名的的‘三方握手’）在每台主机上只进行一次。多路复用对于安全连接来说尤为重要，因为多次 TLS 协商方案的性能成本将会得到显著提高。
在 HTTP/2 中，单一主机内的多资产请求只使用单一 TCP 连接。

四.总结

其实 Web 性能优化已经不是一个新的话题了，从 21 世纪初期直到现在，很多成熟的互联网公司已经开始关注除了产品、研发之外的工作，例如用户体验、性能优化等与产品使用者息息相关的事情，伴随着的就是 APM 行业的全面兴起。
本文主要和大家聊了一些关于 http1 和 http2 有关的基础内容，之后还会有一篇，预计与大家分享一些 http2 使用利弊、以及正在进行的相关工作等等。
Browser Insight 是一个基于真实用户的 Web 前端性能监控平台，能够帮大家定位网站性能瓶颈，网站加速效果可视化；支持浏览器、微信、App 浏览 HTML 和 HTML5 页面。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
【下】

一.前言

我们在 HTTP/2 对 Web 性能的影响（上）已经和大家分享了一些关于 Http2 的二项制帧、多用复路以及 APM 工具等，本文作为姊妹篇，主要从 http2 对 Web 性能的影响、http2 使用的利弊以及一些正在进行中的相关工作等方面与大家进行分享。

二.Web 性能影响：与内联、级联及图像精灵说再见？

HTTP/2 多路复用对前端 Web 开发人员造成了深远的影响。长久以来，人们用尽方法，试图通过捆绑相关资产来削减连接的数量，而现在这一切都不需要了。人们曾经尝试过的方法包括：

  • JavaScript 与 CSS 文件级联：将多个小文件合成一个大文件，从而降低总体请求数量。
  • 图像精灵：将多个小图像合成一张大图像。
  • 域名分片：在多个域之间发送静态资产请求，从而增加浏览器所能允许的总体开放 TCP 连接数量。
  • 内联资产：将资产同 HTML 文档源绑定，包括 base-64 编码图片，以及直接写入 script 标签的 JavaScript 代码。

因为不需要再绑定资产，我们就有了更多机会将 Web 应用程序中的小片段加以缓存。举个例子可以帮我们更好的理解这一点：
一个级联且指纹验证型 CSS 文件被解绑为四个较小的指纹验证文件。
常见的级联模式是将一个应用程序内不同页面的样式表文件进行绑定，形成单一的 CSS 文件，以减少资产请求的数量。这个大文件随后会通过文件名内的 MD5 哈希值进行指纹校验，确保其能够被浏览器主动缓存。遗憾的是，这样的解决方案意味着，当站点的可视化布局中出现了任何一点小的改变，如标题字体的改变，都需要重新下载整个级联文件。
当对小型资产文件进行指纹校验时，相当一部分的 JavaScript 与 CSS 组件都不会频繁产生变动，因此可以被浏览器缓存 –也就是说，任何一个单一功能的小型重构，不会再导致大量的 JavaScript 应用程序代码或者 CSS 失效。
最后，级联机制的消失能够降低前端构建基础的复杂性。与以往通过一系列预置步骤来级联资产不同，现在它们作为小型文件，可以直接被放入 HTML 文档中。

三.实际使用 HTTP/2 的潜在弊端

仅仅针对支持 HTTP/2 客户端而做出的各类优化，意味着那些不支持 HTTP/2 的浏览器可能因此陷入不利境地。那些“有年头”的浏览器们仍然倾向于绑定资产，以此降低连接数量。截至 2016 年 2 月，caniuse.com 网站报道称，全球浏览器中能够支持 HTTP/2 的占比 71%。与之前浏览器们决定放弃支持 IE 8.0 时一样，支持 HTTP/2 或采取某种混合作业的方式——这样的决定只能根据各个网站自身的相关数据来做出。
但是我们相信大规模支持肯定是不可避免的，就像一开始只有 Chrome 浏览器支持 window.performance 接口，方便一些 Web 工具进行数据的采集，像上面说过的Browser Insight ，我曾经和他们的技术支持聊过，就是靠这种方式来实时的采集用户对网站的访问信息等。之后，大势所趋，各个浏览器厂商都纷纷开放了相关接口
正如可汗学院的博文所述，他们曾分析其网站上的 HTTP/2 流量，事实上，拆分大量资产会增加所传输字节的总量。而使用zlib压缩单一大型文件，比压缩多个小型文件要更有效率。对于拥有成百上千解绑资产的 HTTP/2 站点来说，这种效应更为显著。
在浏览器中使用 HTTP/2 还要求我们通过 TLS 进行资产传递。对于菜鸟们来说，设置 TLS 证书就是个烦人的活儿。幸运的是，诸如 Let’s Encrypt 的开源项目正努力让证书注册工作变得更加便捷。

四.仍在进行中的工作

大部分用户并不在意你的站点用了啥协议——他们只想要它速度快，运行如人预期。虽然 HTTP/2 已经获得正式批准快一年了，开发人员还在学习如何利用它来建立更快速网站的最优实践。换用 HTTP/2 的好处更多取决于具体站点的架构情况以及使用现代浏览器的用户比率。再有就是，调试新协议很有挑战性，更易用的开发工具还在研制中。
虽然有这些挑战，HTTP/2 的采纳度仍在增加。根据研究人员扫描流行网站属性的结果，排名前列的站点中使用 HTTP/2 的一直在增加，特别是 CloudFlare 和WordPress 在 2015 年宣布提供支持之后。在考虑转换到新协议时，很重要的一点是利用 Browser insight 和 NewRelic 之类的 APM 工具，仔细测量资源和页面在不同环境下的加载时间。
如下图所示，可以看到每一次慢加载的详细情况，非常方便。

供应商和专业网站人员都熟悉这一转换背后的含义，从真实用户数据中做出判断才是关键的。在网站臃肿危机的当下，无论何种协议，都应该以削减资源数量为目标。
在此 HTTP/2 系列的第二部分中，我们会聚焦于如何在服务器上实现 HTTP/2 和调试真实网络通信的具体实现细节。
本文作者为 Clay Smith，由 OneAPM 产品运营进行翻译编辑
原文地址：https://dzone.com/articles/how-http2-is-changing-web-performance-best-practic
Browser Insight 是一个基于真实用户的 Web 前端性能监控平台，能够帮大家定位网站性能瓶颈，网站加速效果可视化；支持浏览器、微信、App 浏览 HTML 和 HTML5 页面。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客

[php]利用curl_multi_exec和yield实现异步

Yield参照鸟哥的博客：http://www.laruence.com/2015/05/28/3038.html
这里的异步是将curl的请求发送，然后控制权交还给php，直到最后期中获取curl后的结果。程序如下：

    public function async() {
        
        $start = microtime(true);
        $url = "http://waimai.baidu.com/waimai?qt=poisug";  //随意的一个接口
        $i = 50; //假设请求N次
        do {
            $gen[$i] = $this->_request($url);
            //实际应用中可能在多次请求之间有其他事情要处理，否则我们可以直接使用curl_multi
            //suppose i can do something here
            $i --; 
        }while($i);
        
        $ret = $this->_dealGen($gen);
        var_dump($ret);
        $end = microtime(true);
        echo $end - $start;
        
    }
      
    protected function _request($url) {
        
        $mh = curl_multi_init();       
        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $url);      
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)');
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
        curl_setopt($ch, CURLOPT_MAXREDIRS, 7);
        curl_multi_add_handle($mh, $ch);
        do {
            $mrc = curl_multi_exec($mh, $active);
			//可以看到很多参考代码这里是sleep(),其实浪费了程序执行的时间
            yield null;  //先去请求，不用等待结果
        } while ($active > 0); 
        
        $raw = curl_multi_getcontent($ch);
        curl_multi_remove_handle($mh, $ch);
        curl_multi_close($mh);
        yield $raw;       
    }
    
    protected function _dealGen($gens) {
             
        $ret = array();
        do {
            $running = false;
            foreach ($gens as $id => $gen) {              
                if ($gen->valid()) {
                    //有任意没处理完的yield就继续进行处理
                    $running = true;
                    $gen->next();
                    $tmp = $gen->current();
                    if ($tmp !== null) {
                        $ret[$id] = $tmp;
                    }
                }
            }
        } while ($running);       
        return $ret;          
    }

当然主要是接口比较给力，这里只用了0.15260910987854毫秒。可见是进行异步处理的结果。

博客从SAE迁移到阿里云

最近SAE的mysql开始收费，导致原博客服务负担不起这么大的消耗。所以将博客都签到了阿里云。在原域名下只做了301跳转，链接继续保留，丢失的其他文字SEO就丢吧。导mysql时候丢了10篇文章！！应该是source时候主键重复了。另外标签分类也丢了…

阿里云服务器是一台centos服务器，安装和部署比较灵活。

在nginx上做了二级域名判断。分别建了两个博客。Wordpress会记住主页url，如果之前目录下有wordpress，跳到这个目录下还会跳转到原来设置的主页url。很坑，一度怀疑nginx配置失误….

下面是nginx的部分配置：


server {

listen 80;

 

set $linuxidc_name www/xxxx/xxxx;

 

if ($host ~ "da.dadaaierer")

{

set $linuxidc_name xxxx1;

}

 

if ($host ~ "er.dadaaierer")

{

set $linuxidc_name xxx2;

}

 

root /home/work/$linuxidc_name;

…..

PS:使用wordpress4.4.2之后默认的设置明显加载速度变慢了。发现是加载了gravatar的头像。通过设置-讨论-关闭头像后，加载速度明显快了一截。之后使用disable-google-fonts插件，禁用谷歌字体，访问速度得到了明显改善。墙内可怜！

优化一个简单的生产消费队列

背景：队列的生产者有N台机器，产生N个重复的多个消息ids到队列。有ids，则对应的用户这个条件置为1；
开始简单的producter(*N)->queue->workers(*3) 赶不上生产速度，堆积百万个msg
优化点
1 读队列消息，因为有大量重复消息，收集到1K个unique消息进行处理
2 处理过的key放在redis里，过期时间10分钟。10分钟之内的出现的消息不再处理
Producter(*N)->queue->unique->get_no_redis->workers(*1)
妥妥的

u=51521456,1161130478&fm=21&gp=0