一般的なパフォーマンスの最適化の概念
スループット（TPS、QPS）：単にトランザクションまたは終了秒当たりクエリ数の数です。さらに通常は、システムが扱うことができる時間の単位あたりの要求の特定の多数を示し、それがより良いTPS高いことが通常望ましいです
応答時間：リクエストから受け取るシステムが戻るに送り出される時間。応答時間は平均化されていないが、このような一般的に使用される90％の応答時間として、値を平均した後、再度不安定を除去するために、不安定を除去するために10％の応答時間を指し、安定した残りの90％の後平均応答時間。クラスタの観点から、実際には、それが外れ値を削除することです。
エラー率：要求の合計数の数の不正な要求、すなわち比。圧力が増加すると、ケースがあるかもしれないが、要求処理の処理、エラー数が増加し続けます。
三の大関連性、孤立データは、問題を説明することはできません。典型的な関係もエラー率を増加させることができる、スループットが増加し、応答遅れが高くなる可能性があり、です。したがって、TPSは、単一の10ワットを考え出すと、問題を説明することはできません。
パフォーマンスチューニングのアイデア
一般的に、チューニングの前提条件への必要性はそれが証拠に、問題を拡大して、それが本当の圧力水ラインまたはラインテスト中である、すなわちかどうか、そこにあります。
問題の現象のこれらのより明白な最初の印象によると、最初の印象の確立の結果を確認し、現象の原因を分析し、問題を解決しようとする証拠を収集します。
1.パフォーマンス診断テスト
新しい以上のコードを持っていたが、システムを変えるのシステムでは、診断テストや、必要な操作を行います。一般的に、それは徹底的にテストすることが望ましいスタンドアロンのストレステストです。ストレステストは、おそらく圧力がアップしているとき、あなたはいくつかのエラーや問題への露出はありませんどのくらいのシステム制限TPS、把握することができ、どのようなおおよそのシステムリソースの消費量であることの可能なシステムのパフォーマンスのボトルネックがありますさ。
以下は、構成および診断テストの結果です。これは、機械10を測定12,000圧力への同時ユーザの結果であるTPSが複数7ワット、82MS平均応答時間、2.5％の誤差率に、見ることができます。
図からどのような情報も得ることができますか？まず、後半TPSの急速な下落は、実際には、領域に並行処理のような大規模な量その崩壊をサポートすることができなかった、いくつかの可能性がありました、一つのシステムは、単に並行処理のような大規模な量を買う余裕はない、と問題の第二中間システムは、TPSにつながります落ちます。第二に、時間が増加すると、エラーレートが大幅にシステムは非常に多くの要求に対処することができなかったことを示す、増加しています。そして、前の2つの比較的安定した平均応答時間を結合、システムは、一般的に推測されるような大規模な同時に耐えることができません。それはおそらく、単一で、7,000人以上のTPS 10機であるため、また、将来的には、基礎として調整することができます。
アプリケーションの特性のために、だけでなく、この時点でそれを分析する、つまり、アプリケーションのリソースを占有することがあります。例えば、CPU集約型のアプリケーションやIO集中型アプリケーションは、（また、密なディスクまたはネットワークに分けることができます）
2.パフォーマンスの最適化の目標を定義します
多くの場合、人々は、より高い、より良いパフォーマンスの最適化、スループット、であることを、言うのを聞く、または性能試験を行い、TPSターゲットは50000です。実際に、この情報を得ることができ、あなたは、パフォーマンステストを行うことができますか？まだ十分に明確な目標？
実際には、私の意見では、パフォーマンステストのいじめを行うための明確な目標を定義されていません。
パフォーマンスの最適化目標スループットは、一般的に最大90％の応答時間よりもはるかに少ない、エラーレートが数より少ないです。しかし、また、我々は他のパフォーマンス指標、CPU使用率、メモリ使用率、ディスク使用量、使用帯域幅などに焦点を当てる必要があります。診断テストは、問題は、具体的には、高負荷として、この問題のために最適化することができることを見出したため、CPUの消費量が多すぎると、ターゲットは変わらないCPU負荷ケースの応答時間およびエラー率を減少させる、TPSであってもよいです。またはメモリあまりにも急速に成長し、GCより頻繁に、目標は、可能なメモリリークを識別すること、または関連するJVMのメモリー・チューニングのためにも。要するに、目標は調整するより柔軟にすることができますが、明確でなければなりません。
3.分析
工程分析システムは、基本的性能の一千千種である、より柔軟です。ここでは、出て彼らに困難です。唯一のいくつかの一般的な方法、ツールやアイデアについて話しています。
CPUの場合：
監視用CPUは、実際には、Linuxは、一つはvmstatのある、ツール、1つのトップを使用することは比較的容易2を提供してきました。CPUは、4つの値に焦点を当ててvmstatコマンドについての2つのコマンドは、ここでは、トップを参照し手の込んだない：私たち（ユーザー）、SY（システム）、WA（待機）、ID（アイドル）。理論的には、彼らは100％まで追加する必要があります。そして最初の3つの値のそれぞれは、特定の問題の存在を示すことができる高すぎます。
上
http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/top.html
vmstat
http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/vmstat.html
us过高：
a. 代码问题。比如一个耗时的循环不加sleep，或者在一些cpu密集计算（如xml解析，加解密，加解压，数据计算）时没处理好
b. gc频繁。一个比较容易遗漏的问题就是gc频繁时us容易过高，因为垃圾回收属于大量计算的过程。gc频繁带来的cpu过高常伴有内存的大量波动，通过内存来判断并解决该问题更好。
小技巧：如何定位us过高的线程并查看它的状态。
a. top命令找到消耗us过高的进程pid
b. top -Hp pid找到对应的线程tid
c. printf %x tid转为16进制tid16
d. jstack pid | grep -C 20 tid16 即可查到该线程堆栈
sy过高：
a. 上下文切换次数过多。通常是系统内线程数量较多，并且线程经常在切换，由于系统抢占相对切换时间和次数比较合理，所以sy过高通常都是主动让出cpu的情况，比如sleep或者lock wait, io wait。
wa过高：
a. 等待io的cpu占比较多。注意与上面情况的区别，io wait引起的sy过高指的是io不停的wait然后唤醒，因为数量较大，导致上下文切换较多，强调的是动态的过程；而io wait引起的wa过高指的是io wait的线程占比较多，cpu切换到这个线程是io wait，到那个线程也是io wait，于是总cpu就是wait占比较高。
id过高：
a. 很多人认为id高是好的，其实在性能测试中id高说明资源未完全利用，或者压测不到位，并不是好事。
针对内存：
关于java应用的内存，通常只需要关注jvm内存，但有些特殊情况也需要关注物理内存。关于jvm内存，常见的工具有jstat, jmap, pidstat, vmstat, top。
jvm内存：
异常gc :
a. 通常gc发生意味着总归是有一块区域空间不足而触发gc。而许多导致异常gc的情况通常是持有了不必要的引用而没有即时的释放，比如像cache这样的地方就容易处理不好导致内存泄露引发异常gc。
b. 有可能是程序的行为是正常的，但是由于没有配置对合适的gc参数导致异常gc，这种情况通常需要调优gc参数或者堆代大小参数。
c. Full gc 发生的情况:
-
永久代满
-
年老代满
-
minor gc晋升到旧生代的平均大小大于旧生代剩余大小
-
CMS gc中promotion fail或concurrent mode fail
OOM：
a. OOM经常伴随着异常gc，之所以单独拿出来讲，是因为它的危害更大一些，异常gc顶多是收集速度过快或者回收不了内存，但是起码有个缓冲时间，但是出了OOM问题就大了。至于各种类型的OOM如何区分，如何发生，请参考这里（http://www.jianshu.com/p/2fdee831ed03），算是总结得比较全面的。对于常见的OOM，基本上可以一下子指出问题所在。
b. heap区，对象创建过多或持有太多无效引用（泄露）或者堆内存分配不足。使用jmap找到内存中对象的分布，使用ps找到相应进程及初始内存配置。
c. stack区, 不正确的递归调用。
d. perm区，初始加载包过多，分配内存不足。
e. 堆外内存区，分配ByteBuffer未释放导致。
针对IO：
IO分为网络IO和文件IO，针对网络IO比较有用的工具有sar（https://linuxstory.org/generate-cpu-memory-io-report-sar-command/）,netstat（https://linux.cn/article-2434-1.html）,netstat是一个非常牛逼的命令，可以助于排查很多问题, 针对文件io的工具有pidstat,iostat（http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/iostat.html）
文件IO：
a. 从技术上来说，对于大文件IO可以采取的措施是异步批处理，采用异步方式用于削峰并累计buffer，采用批处理能够让磁盘寻道连续从而更加快速。
网络IO：
网络IO的问题较为复杂，仅举几个常见的：
a. 大量TIME_WAIT。根据TCP协议，主动发起关闭连接的那一方，关闭了自己这端的连接后再收到被动发起关闭的那一方的关闭请求后，会将状态变为TIME_WAIT，并等待2MSL, 目的是等待自己的回执发送到对方。如果在服务器上发现大量TIME_WAIT，说明服务器主动断开了连接，什么情况下服务器会主动断开连接，很可能是客户端忘了断开连接，所以一个典型的案例就是jdbc连接忘记关闭，则数据库服务器可能会出现大量的TIME_WAIT状态。
b. 大量CLOSE_WAIT。CLOSE_WAIT状态，在收到主动关闭连接的一方发出关闭连接之后，被动关闭的一方进入CLOSE_WAIT状态，如果这时候被hang住了没进行后续关闭，则会出现大量CLOSE_WAIT。啥情况会被hang住呢，举几个例子，比如刚刚的忘记关闭数据库连接，在应用服务器这端，大量的浏览器请求进来，由于没有连接池连接被hang住，这时候浏览器等待一定时间超时发送关闭连接请求，而应用服务器这边由于servlet线程被hang住了，自然没有办法走第二个关闭回去。因此在应用服务器出现大量CLOSE_WAIT。另一个例子是httpClient的坑，在调用response.getEntity(); 前都不会做inputStream.close()，如果在调用response.getEntity()前就返回了，就狗带了。（这个例子可以参考http://blog.csdn.net/shootyou/article/details/6615051）
4.优化并重新测试验证
-
性能调优思路 http://www.voidcn.com/blog/bigtree_3721/article/p-5786972.html
-
linux下性能监控命令 http://linuxtools-rst.readthedocs.io/zh_CN/latest/advance/index.html
-
关于JVM CPU资源占用过高的问题排查 http://my.oschina.net/shipley/blog/520062
-
java排查工具 http://my.oschina.net/feichexia/blog/196575
-
jvm参数调优 http://www.cnblogs.com/java-zhao/archive/2016/02/08/5185092.html
-
java linux系统调优工具 https://www.ibm.com/developerworks/cn/java/j-lo-performance-tuning-practice/
-
gc优化的一些思路 http://mm.fancymore.com/reading/gc%E4%BC%98%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%B7%AF.html
-
性能优化的思路和步骤 http://www.uml.org.cn/j2ee/201602013.asp
-
性能调优攻略 http://coolshell.cn/articles/7490.html
-
JVM性能调优入门 http://www.jianshu.com/p/c6a04c88900a
-
JVM性能调优 http://blog.csdn.net/chen77716/article/details/5695893
-
Tomcat性能优化 https://yq.aliyun.com/articles/38861?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&2017323&utm_content=m_14698
-