一直觉得那些能写博客或者知乎上能得到很多赞的人很了不起，他们不仅对于自己掌握的知识理解的很透彻，还能讲他们通俗易懂的解释给别人。我一直都不太擅于总结，感觉自己花了很多时间去学习，接触到的知识也不少，但是真正能为己所用，并且表述出来的很少。其实，只有你自己把你学到的表述出来了，你才是真正的掌握了它们。或许有时候是因为太忙，没时间，而忘记了总结。但是其实大部分时候还是因为太懒而放弃了总结。
最近工作中为一个系统的服务器更换而做了一些调优的设置。感觉解决问题的思路是这次收获最大的。因此尝试着进行了下总结：
首先，为何要做这次性能调优的工作。
之前我们的系统运行在tomcat+apache架构组成的6台服务器上。但是因为性能逐渐不足，加上之前的服务器是跟别的系统共用，已经没办法再扩展了。所以决定搬到一个全新构建的服务器集群下。加之公司规定，新构建的系统一概采用Nginx+Wildfly的架构，所以新环境里采用了Nginx+Wildfly的架构，而为了达到对硬件资源的有效利用，对它们分别进行了一些性能的调优。
关于性能调优的一个基本的思路，我的理解如下：
影响服务器性能的三个主要因素：
CPU(计算能力)+IO(读写能力)＋内存(存储能力)
测试达到最大性能时的瓶颈因素，然后找到原因，尝试修改中间件的设置或者系统代码去降低瓶颈值，以便让所有资源得到充分利用。
找到瓶颈很简单，但是找到原因就不太容易了，总结下到到目前为止遇到和处理过的问题，我给出一下几个建议：
如果系统逻辑很复杂，最好检查最耗费资源的处理是不是妥当(分析Thread dump)
如果对象是db服务器，需要查找最耗时的sql需不需要能够优化(分析Sql dump)
如果服务器资源还没达到最大利用率但是处理件数却已经达到极限，就需要看看中间件的设置是不是有问题(调整heap size、thread pool等设置)。
然后，分享下这次调优的过程：
测试工具：Jmeter
测试客户机：5台左右
服务器架构：web服务器1台(nginx)，application服务器1台(wildfly)
服务器硬件：web服务器跟application服务器分别是2核cpu，4G内存，100G硬盘(无ssd)
①逐渐调整Jmeter件数，大概在每秒900/件的时候，错误开始频繁发生
②通过log查找出错误的原因在Web服务器(Nginx)
错误内容：
socket() failed(24:Too many files)while connecting to upstream, client:xxx
③修改Nginx的设置，提高openfile的数值
修改内容：
提高了worker_connections(1024→10240)和worker_rlimit_nofile(1024→10240)的值。
※修改文件：nginx.conf
※要注意nginx用户的openfile设置值一定要高于nginx.conf里面的设置，否则conf文件里的设置会被忽略
④逐渐调整Jmeter件数，大概可以达到6000件/秒，超过这个数值nginx会隔几秒会出现几次timeout的错误
这个时候cpu已经达到100%左右，内存也接近70%。因此判定现有硬件的条件下6000件/秒左右就是极限了。
⑤因为考虑到ap服务器今后跟对其他系统的访问延迟问题，在系统逻辑处理中故意加入了500ms左右的延迟。
然后throughput变成了150件/秒
⑥逐渐调高了wildfly设置文件里的task-max-threads值，调整数值在1200左右的时候恢复到了4000件/秒
※修改文件：domain.xml
※修改方式：
・启动wildfly ctl
jboss-cli.sh -c
・执行修改task-max-threads的命令
/profile=full-1/subsystem=io/worker=default:write-attribute(name=task-max-threads, value=1200)
顺便说一下，max-concurrent-requests和task-max-threas同时设置的情况下，max-concurrent-requests的优先等级更高一些
max-concurrent-requests的设置方法：
/profile=full-1/subsystem=undertow/configuration=filter/connection-limit-filter:add(concurrent-requests=1200,queue-size=0)
测到这里基本满足了我们对系统性能的需求，加之jmeter一些限制，也就没有再往极限测试了。
