前

上一篇已经很OK的部署了一个 wordpress 的stack跑在Swarm 的集群上面，现在还挺稳定的，比较开心。
不过为了追求更快更好的体验，和对页面体验的提升，这里就要进行大优化了。
因为描述一下现状，现在的中间的隧道节点是很可怜的 1M 带宽的机器，怎么把这个 1M 的带宽用好就是关键了。

这里先给个数据：站点的加载内容为 205k

1M 带宽其理论上下行总和速度 ： 125k/s
理论传输时间：205/125=1.64s
实际上传输时间: 2.6s +- 0.5

Not Special ，It’s unique

Gzip 压缩

GZIP 压缩，用于压缩HTTP的请求文件的大小，得到其可以在有限带宽下面的传输能力。配置方法如下，直接在Nginx的虚拟主机的 块里面进行配置，来启用Nginx 的Gzip功能。

gzip on;
gzip_disable "msie6"; # IE6 不使用GZIP

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;  # 压缩等级
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;    # 256K以下文件不压缩
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;

在进行配置之后直接 reload Nginx 的配置即可生效：查看服务的响应头内容如下：

可以得到，已经开启 Gzip 的压缩功能。这里的压缩级别为 6，实际上这里是消耗CPU的运算，如果太高，有可能反而导致变慢的情况。

参考链接：

• [加速nginx: 开启gzip和缓存]( "https://www.darrenfang.com/2015/01/setting-up-http-cache-and-gzip-with-nginx/")

Cache 缓存

使用 Nginx 加cache 这个之前在前面的帖子已经有提到过，这里换汤不换药。下面也po出配置文件：

proxy_cache_path /tmp/ramdisk levels=1:2 keys_zone=my_zone:64m inactive=24h max_size=64m;
proxy_cache_key "$scheme$request_method$host$request_uri";

    location ~ .*\.(gif|jpg|png|html|htm|css|js|ico|swf|pdf)$ {
        #Proxy
        proxy_set_header        Host $host;
        proxy_ignore_headers    Set-Cookie Cache-Control;   #这句代码很关键，尤其要忽略set-cookie

        proxy_set_header            X-real-ip $remote_addr;
        proxy_set_header            X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass https://con; # upstream的

        #Use Proxy Cache
        #定义的缓存池名称
        proxy_cache my_zone;
        proxy_cache_key "$host$request_uri";   #定义缓存存放目录的子目录命名规则
        add_header Cache "$upstream_cache_status"; #缓存的HTTP头部加了一个Cache
        proxy_cache_valid  200 304 301 302 8h;
        proxy_cache_valid  404 1m;
        proxy_cache_valid  any 2d;
    }

整体不复杂，指定了静态文件的类型的正则，这些文件将不会在源站进行请求，会现在Nginx的缓存里面取。当然，这里的请求量不大，所以就使用了较小的空间 64M, 也是热数据的思想，这里的缓存内容是放在内存盘里面的。

---

配置之后，继续查看响应头：

可以看到，这里的缓存已经是 HIT 的状态。说明配置成功。使用 df -h 查看缓存的分区，已经使用部分空间。

---

安全！ 全站HTTPS

由于 WordPress 的管理界面是直接账号密码登陆的，所以如果直接使用 HTTP 在页面上进行登陆，还真的是有些不放心，所以这里的 HTTPS 必须是得加上。HTTPS 的服务器配置，对于 HTTPS 的配置，可以直接取标准模板里面进行拷贝，这里就不在赘述，一样的可以本站搜索 NGinx 得到相关的结果。

这里给出一段比较精巧的代码，用来实现全站的 Https 的，这里直接把 80 端口的请求进行重定向到目标站点（https）。

server {
     listen 80 default_server;
     #listen [::]:80;
     server_name _;
     return 302 https://$host$request_uri;
     #rewrite ^(.*)$  https://$host$1 permanent;

     error_page 404 /404.html;
        location = /40x.html {
        }
}

KCP 弱网络加速

这里使用了比较 LOW 的方法，使用 FRP 把本地的主机映射到外网，由于前面使用的境外的 VPS，所以网络环境是相当的不好，请求的 TTFB 往往长达十几秒，所以必须是使用 KCP 来解决弱网络下面的问题。

关于KCP 的介绍：

https://github.com/skywind3000/kcp

更快 ! redis ！

没想到是在这种情况下接触到了 redis。先做一个基础的了解吧，这个是一个基于内存的非关系数据库，由于其强大的性能。多用于做 对象缓存。

由于之前 wordpress 的官方镜像是直接打包 php-fpm 的，其中默认没有 redis 的moudule。
所以需要安装组件，构建新的镜像。构建命令下面已经给出：

FROM wordpress:latest
ENV PHPREDIS_VERSION 3.1.3
RUN curl -L -o /tmp/redis.tar.gz https://github.com/phpredis/phpredis/archive/$PHPREDIS_VERSION.tar.gz \
&& tar xfz /tmp/redis.tar.gz \
&& rm -r /tmp/redis.tar.gz \
&& mkdir -p /usr/src/php/ext \
&& mv phpredis-$PHPREDIS_VERSION /usr/src/php/ext/redis \
&& docker-php-ext-install redis \
&& rm -rf /usr/src/php

构建过程的Dockerfile 参考链接：

https://blog.csdn.net/xxx9001/article/details/81914074

---

在镜像本身有了 php 的 redis 插件之后，我们需要在我们的stack里面添加redis的服务。所以我们修改 compose文件，添加redis 的配置:

   redis:
     image: redis
     restart: always

之后直接进行更新这个 stack 即可。连接时候默认的host:port 是 redis:6379。

---

在wordpress里面直接进行redis的插件安装即可。
这里使用的是 LiteSpeed Cache

之后直接使用命令使用 shell 连上 redis 的容器：
docker exec -i -t mynginx /bin/bash redis-cli
之后来使用 keys * 来显示所有的缓存键。

后

经过一番折腾之后，站点，也就是本站的访问体验也算是得到了较大程度的加强，使用 Google 的 pagespeed-insight 进行测速：

[PageSpeed Insights]( https://developers.google.com/speed/pagespeed/insights/?hl=zh-cn)

得到的评分已经达到了70+的水平，在TTFB达到 2-3 秒的时间下，算是比较OK的了，还是比较开心的。
至此，优化的操作到此告一段落啦

with man nothing is possible but with god all things are possible