提醒：本文最后更新于 2606 天前，文中所描述的信息可能已发生改变，请仔细核实。
如题。这次更新修补了6个重要的安全漏洞（主要为XSS类）并修正了39个问题，详见发行注记。
算是个比较重要的更新。建议大家尽快升级。
最近忙于工作和一些杂七杂八的吧，不过还是对Nginx的FastCGI和MySQL配置进行调优。
优化结果，丢张测试图，所有测试都在1分钟内完成。
前三次，因为流量清洗的原因，所以测试不完整。
我们来看看第一次测试，一共成功了9W+次访问，有1W多超时，实际接收数据1.72G。
在2500并发的时候，平均600ms+响应；6000并发时，近7500ms+的平均响应时间；在接近7500并发，被流量清洗了。
再来看第五次测试，成功10W+次访问，8k+超时，实际接收数据2G。这是在没有流量清洗下的结果。
在2500并发时，也是平均600ms+的平均响应时间；在3500并发时，有个小高峰，3000ms+的平均响应时间；6500并发时，平均响应达到第二高峰，超过10000ms的响应时间；7500并发时，达到最高峰11500ms+的平均响应时间；9500到1W并发，也是有比较高的响应时间。
针对这些，主要对Nginx的FastCGI规则进行调优，调优结果，使曲线相对平整，不会过于波动起伏。
其大幅度波动原因，主要在于缓存过期后，更新缓存时没有锁导致的，当并发高加上缓存过期，FastCGI可能处理着上W条更新缓存的请求，导致这一情况发生。
解决方案主要是使用fastcgi_cache_lock，还有在fastcgi_cache_use_stale添加updating项。
最后针对MySQL总体进行了微调，略微降低平均响应时间值，有了最后一次测试结果。
成功了20W+次的访问，有8K+的超时及8个网络错误，实际接受数据3.75G。可以见到2500并发时，只要平均500ms+的响应时间了；在10000并发时，平均响应时间在2000ms左右。
对于这个结果还是比较满意的，超时对比成功次数，其实算是比较少的，主要还在于服务器的IO及运算能力达不到的原因导致。
怎么说呢，在没有Varnish的情况下，负载在大并发下还是显得有些高，或者说高出不少，有时间我会再看看缓存规则这块，能不能有所改善。
关于测试工具，来自SendGrid Lab的Loader，工具免费使用，其免费套餐对个人来说足够了。
需要加入白名单的测试IP有：
54.85.131.200
52.86.198.91
54.208.68.192
54.85.214.144
52.91.128.14
54.89.44.6
54.175.144.60
52.91.118.90
54.85.128.114
54.197.122.196
52.87.220.244
54.162.105.71
52.87.255.0
52.87.219.148
52.55.246.193
52.90.0.22
172.217.4.168
172.217.5.72
172.217.11.72
172.217.5.200
216.58.193.200
216.58.216.40
216.58.216.8
216.58.219.40
216.58.219.8
172.217.4.136
172.217.11.168
54.234.74.136
34.203.38.68转载请注明转自:kn007的个人博客的《更新至WordPress 4.7.3》