性能測試過程中，為了給服務器足夠的壓力，少不了要使用壓力機，即模擬客戶端的機器，壓力機如果使用不當，測試結果就會不准確，反映不了服務器的真實性能情況。
因此，我們需要充分了解壓力機，並對其進行調優，從而避免壓力機自身瓶頸對壓測帶來影響，為性能測試結果的准確可靠，提供前置條件。
下面，我們分三步來確保壓力機靠譜：
STEP1：了解壓力機自身可能成為瓶頸的配置，並調優；
STEP2：了解被模擬程序自身可能成為瓶頸的配置，並調優；
STEP3：找到壓力機上，單進程的性能瓶頸，以避免在施壓過程中受此干擾；
STEP1
1，網絡通訊協議相關配置調優（以TCP為例），優化最大連接數，理論上TCP最大連接數為65535，因此，理論上單機的瞬時並發最大不可能超過65535；
既然存在使用壓力機，必然是通過某種網絡通訊協議來建立連接，並發送請求。以TCP協議為例，先來了解TCP協議：
如何標識一個TCP連接？
在確定最大連接數之前，先來看看系統如何標識一個tcp連接。系統用一個4四元組來唯一標識一個TCP連接：{local ip, local port,remote ip,remote port}。
client最大tcp連接數（理論上）
client每次發起tcp連接請求時，除非綁定端口，通常會讓系統選取一個空閑的本地端口（local port），該端口是獨占的，不能和其他tcp連接共享。tcp端口的數據類型是unsigned short，因此本地端口個數最大只有65536，端口0有特殊含義，不能使用，這樣可用端口最多只有65535，所以在全部作為client端的情況下，最大tcp連接數為65535，這些連接可以連到不同的server ip。
server最大tcp連接數（理論上），與本文無關，詳見：http://www.cnblogs.com/mydomain/archive/2013/05/27/3100835.html
上面給出的是理論上的單機最大連接數，在實際環境中，受到機器資源、操作系統等的限制，其最大並發tcp連接數遠不能達到理論上限，另外1024以下的端口通常為保留端口。
除端口限制外，TCP連接的內存設置，也會影響到最大連接數。在默認2.6內核配置下，經過試驗，每個socket占用內存在15~20k之間。
綜上，關於TCP最大連接數，linux/Unix下有以下三類配置可以調優
A：Linux網絡內核對本地端口號范圍的限制：
修改/etc/sysctl.conf文件，在文件中添加或修改如下行：
``` net.ipv4.ip_local_port_range = 1024 65000 ``` 這表明將系統對本地端口范圍限制設置為1024~65000之間。請注意，本地端口范圍的最小值必須大於或等於1024；而端口范圍的最大值則應小於或等於65535。修改完后保存此文件。
修改完成后，執行sysctl
sysctl -p
如果系統沒有錯誤提示，就表明新的本地端口范圍設置成功。如果按上述端口范圍進行設置，則理論上單獨一個進程最多可以同時建立60000多個
B：Linux網絡內核的IP_TABLE防火牆對最大跟蹤的TCP連接數的限制，如果沒有防火牆，可忽略此條：（參考：http://blog.chinaunix.net/uid-24907956-id-3428052.html）
首先確定有沒有防火牆
service iptables status
如果有，條件允許，可以直接
service iptables stop iptables
再查看防火牆狀態：
service iptables status
運行結果：
iptables: Firewall is not running.
如果不能關閉防火牆，則修改IP_TABLE防火牆對最大跟蹤的TCP連接數：
修改/etc/sysctl.conf文件，在文件中添加或修改如net.ipv4.ip_conntrack_max = 40960
修改完成后，執行sysctl
sysctl -p
如果系統沒有錯誤提示，就表明系統對新的最大跟蹤的TCP連接數限制修改成功。若按上述參數進行設置，則理論上單獨一個進程最多可以同時建立40960個TCP客戶端連接。
C：TCP相關內存限制
在默認2.6內核配置下，經過試驗，每個socket占用內存在15~20k之間。
修改配置文件：/etc/sysctl.conf
net.core.rmem_default = 262144 net.core.wmem_default = 262144 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 **net.ipv4.tcp_rmem = 4096 4096 16777216 net.ipv4.tcp_wmem = 4096 4096 16777216 net.ipv4.tcp_mem = 786432 2097152 3145728 net.ipv4.tcp_max_syn_backlog = 262144** net.core.netdev_max_backlog = 20000 net.ipv4.tcp_fin_timeout = 15 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_max_orphans = 131072
配置文件生效：sudo /sbin/sysctl -p
主要看這幾項，按機器內存大小，進行調節：
net.ipv4.tcp_rmem 用來配置讀緩沖的大小，三個值，第一個是這個讀緩沖的最小值，第三個是最大值，中間的是默認值。我們可以在程序中修改讀緩沖的大小，但是不能超過最小與最大。為了使每個socket所使用的內存數最小，我這里設置默認值為4096。
net.ipv4.tcp_wmem 用來配置寫緩沖的大小。讀緩沖與寫緩沖在大小，直接影響到socket在內核中內存的占用。
net.ipv4.tcp_mem 則是配置tcp的內存大小，其單位是頁，而不是字節。當超過第二個值時，TCP進入 pressure模式，此時TCP嘗試穩定其內存的使用，當小於第一個值時，就退出pressure模式。當內存占用超過第三個值時，TCP就拒絕分配 socket了，查看dmesg，會打出很多的日志“TCP: too many of orphaned sockets”。
net.ipv4.tcp_max_orphans 這個值也要設置一下，這個值表示系統所能處理不屬於任何進程的 socket數量，當我們需要快速建立大量連接時，就需要關注下這個值了。當不屬於任何進程的socket的數量大於這個值時，dmesg就會看 到”too many of orphaned sockets”。
另外，附上LINUX 查看tcp連接數及狀態，以及狀態詳請，參見： http://blog.sina.com.cn/s/blog_623630d50101r93l.html
2，調整最大打開文件數；http://www.cnblogs.com/peida/archive/2013/02/26/2932972.html
在linux環境下，任何事物都以文件的形式存在，通過文件不僅僅可以訪問常規數據，還可以訪問網絡連接和硬件。所以如傳輸控制協議 (TCP) 和用戶數據報協議 (UDP) 套接字等，系統在后台都為該應用程序分配了一個文件描述符，無論這個文件的本質如何，該文件描述符為應用程序與基礎操作系統之間的交互提供了通用接口。
lsof打開的文件可以是：
普通文件、目錄、網絡文件系統的文件、字符或設備文件、(函數)共享庫、管道，命名管道、符號鏈接、網絡文件（例如：NFS file、網絡socket，unix域名socket）、還有其它類型的文件，等等
故，作為壓力機，每個TCP/UDP連接都會占用一個文件打開數，此處，可能成為瓶頸。
3，打開進程數限制（root用戶本項是無限）
如果你對進程總數量沒有特殊要求，可以不修改本選項。
執行命令：
ulimit -a
查看結果：
max user processes (-u) 16484
如果此項可能成為瓶頸，則修改此項。
4，確認網卡、路由不會成為瓶頸
此處不做詳解。
5，確認網絡帶寬
此處不做詳解，查看實時帶寬流量 https://help.aliyun.com/knowledge_detail/5988901.html?pos=11
6，壓力機其他可調優的參數：
參考：http://blog.csdn.net/my_yang/article/details/45788717
STEP2 以java為例
1，java堆內存、棧內存，理論詳見：http://blog.csdn.net/qh_java/article/details/9084091
重要的是：
在java中每new一個線程，jvm都是向操作系統請求new一個本地線程，此時操作系統會使用剩余的內存空間來為線程分配內存，而不是使用jvm的內存。這樣，當操作系統的可用內存越少，則jvm可用創建的新線程也就越少。見：http://blog.sina.com.cn/s/blog_684fe8af0100wzg5.html
因此，可以理解為線程使用的內存，不在“使用-Xms -Xmx設置的內存”中，需要根據實際情況進行調節，不宜過大，否則能啟動的線程數量越小；
如果是maven項目，使用jemeter，且使用maven的jemeter插件，那么在POM里，jmeter插件中設置此內存大小；
另外，附上如何計算，只考慮內存的情況下，機器理論上能打開的最大線程數：http://blog.csdn.net/feng27156/article/details/19333575
官網查線程棧默認值（64位為1M）http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 搜XX:ThreadStackSize
2，maven內存
maven本身編譯的內存也不宜設置過小或過大，會影響能啟動的線程數；
3，其他施壓程序的瓶頸
有的框架或程序，可以限制單台機器，連接到本服務的最大線程數，此配置可能成為瓶頸，比如dubbo的 actives配置（每服務消費者每服務每方法最大並發調用數）
其他類似的配置；
STEP3：
找到壓力機上，施壓程序單進程的性能瓶頸；
如果是物理機，且並發數不大（幾百到4/5千），可以忽略此條。
除以上已知配置可能會影響壓力機性能瓶頸以外，不排除其他影響壓力機性能的因素，因此，在遠程機器上，搭建一個mock程序，該程序什么都不做，直接返回成功。注意：mock程序部署機器物理配置最好能和壓力機對等（對等時，至少部署兩台），如果不能對等，部署多台，以排除部署機器的瓶頸；
通過逐步增加線程數，觀察平均響應時間和TPS，隨着線程數的增加，TPS很難上升，平均響應時間明顯增加的情況下，基本可以說明已經達到壓力機的瓶頸，記下此時的線程數，在壓測時，單台壓力機最大線程數不宜超過該線程數，否則壓測結果中，TPS和平均響應時間不准，壓測結果不准確。
總結：
STEP3很重要，因為在實踐中，一台8核 64G內存的機器，單進程，最大的線程數超過10000時，被測服務（20台機器做實驗）的壓力很難再上去，因此STEP1只能說是排除那些可能成為瓶頸的機器配置，STEP2為避免踩已知的坑，STEP3才能確認壓力機的單進程施壓能力到底是多少；
原文地址http://blog.csdn.net/kaka1121/article/details/51496387
==============================================================================================================================================================================================================================================
性能測試中TPS上不去的幾種原因淺析
昨晚在某個測試群看到有人問了一個問題：壓力測試中TPS一直上不去，是什么原因？稍微整理了下思路，列舉性的簡略回答了他的問題。
這篇博客，就具體說說在實際壓力測試中，為什么有時候TPS上不去的原因。如有遺漏或不對的，請評論區指出，不勝感激。。。
先來解釋下什么叫TPS：
TPS（Transaction Per Second）：每秒事務數，指服務器在單位時間內（秒）可以處理的事務數量，一般以request/second為單位。
關於性能測試的其他一些常見術語，可參考之前的博客：性能測試：常見術語淺析
下面就說說壓測中為什么TPS上不去的原因：
1、網絡帶寬
在壓力測試中，有時候要模擬大量的用戶請求，如果單位時間內傳遞的數據包過大，超過了帶寬的傳輸能力，那么就會造成網絡資源競爭，間接導致服務端接收到的請求數達不到服務端的處理能力上限。
2、連接池
可用的連接數太少，造成請求等待。連接池一般分為服務器連接池（比如Tomcat）和數據庫連接池（或者理解為最大允許連接數也行）。
（關於連接池的具體內容，可參考之前的博客：性能測試：連接池和線程）
3、垃圾回收機制
從常見的應用服務器來說，比如Tomcat，因為java的的堆棧內存是動態分配，具體的回收機制是基於算法，如果新生代的Eden和Survivor區頻繁的進行Minor GC，老年代的full GC也回收較頻繁，那么對TPS
也是有一定影響的，因為垃圾回收其本身就會占用一定的資源。
4、數據庫配置
高並發情況下，如果請求數據需要寫入數據庫，且需要寫入多個表的時候，如果數據庫的最大連接數不夠，或者寫入數據的SQL沒有索引沒有綁定變量，抑或沒有主從分離、讀寫分離等，
就會導致數據庫事務處理過慢，影響到TPS。
5、通信連接機制
串行、並行、長連接、管道連接等，不同的連接情況，也間接的會對TPS造成影響。
（關於協議的連接，可參考之前的博客：HTTP協議進階：連接管理）
6、硬件資源
包括CPU（配置、使用率等）、內存（占用率等）、磁盤（I/O、頁交換等）。
7、壓力機
比如jmeter，單機負載能力有限，如果需要模擬的用戶請求數超過其負載極限，也會間接影響TPS（這個時候就需要進行分布式壓測來解決其單機負載的問題）。
8、壓測腳本
還是以jemter舉個例子，之前工作中同事遇到的，進行階梯式加壓測試，最大的模擬請求數超過了設置的線程數，導致線程不足。
提到這個原因，想表達意思是：有時候測試腳本參數配置等原因，也會影響測試結果。
9、業務邏輯
業務解耦度較低，較為復雜，整個事務處理線被拉長導致的問題。
10、系統架構
比如是否有緩存服務，緩存服務器配置，緩存命中率、緩存穿透以及緩存過期等，都會影響到測試結果。
PS：性能瓶頸分析不能單從局部分析，要綜合起來，多維度分析問題原因。上面列出的幾點，可能有描述不當或者遺漏的，僅供參考。。。
如果有不准確的，請評論指正，謝謝！