開始以為是單機運行腳本運行不過來，所以另加了一台負載機同時運行腳本
分布式環境部署參考：r
https://www.cnblogs.com/whitewasher/p/6946207.html
但是依然還是會報錯，后面查閱了相關資料后發現，是因為windows本身提供的端口訪問機制的問題。
Windows XP提供給 TCP/IP鏈接的端口為 1024-5000，並且要四分鍾來循環回收他們。就導致我們在短時間內跑大量的請求時將端口占滿了。
解決方案為：
1.cmd中，用regedit命令打開注冊表
2.在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下，
1 .右擊parameters，添加一個新的DWORD，名字為MaxUserPort
2 .然后雙擊MaxUserPort，輸入數值數據為65534，基數選擇十進制（如果是分布式運行的話，控制機器和負載機器都需要這樣操作哦）
3.修改配置完畢之后記得重啟機器才會生效
2. 在Windows機器上用Jmeter做性能測試，匯總下我自身遇到的錯誤和解決方案
java.net.BindException: Address already in use: JVM_Bind
原因分析：壓測服務器問題，由於並發太高，導致自身port不夠用，需要調整機器的端口，可用netstat -ano看出來；去掉下面的/c查看詳細端口占用
定位：
netstat -ano | find "10.215.70.172:443" | find "ESTABLISHED" /c
50
netstat -ano | find "10.215.70.172:443" | find "SYN" /c
netstat -ano | find "10.215.70.172:443" | find "TIME_WAIT" /c
2233
解決方案：
cmd中，用regedit命令打開注冊表;在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下， 1）右擊parameters，添加一個新的DWORD/QWORD，名字為MaxUserPort 2）然后雙擊MaxUserPort，輸入數值數據為65534，基數選擇十進制,重啟電腦生效
Nginx: 99: Cannot assign requested address for upstream
如下鏈接解決方案：
http://blog.51cto.com/12223582/1877316
3. JMeter測試問題:address already in use
在Windows Server 2003執行JMeter，當並發線程數較高時（尤其是測試機器還存在連接其他服務器的socket），可能會產生address already in use的異常。
搜索一番，很多文章指出是Windows的bug。通過在測試機器添加注冊表項MaxUserPort、TcpTimedWaitDelay，並設置恰當值可解決該錯誤（當沒有這兩個注冊表項時）；或者修改為合適的值（如果已經存在這兩個注冊表項）。
方法：
在運行JMeter agent的機器上上添加注冊表條目MaxUserPort和TcpTimedWaitDelay，分別設置值為65534、30，以增大可分配的tcp連接端口數、減小處於TIME_WAIT狀態的連接的生存時間。
該方法確認對Windows Server也有效，因為在Windows Server 2003 R2上發現缺失MaxUserPort和TcpTimedWaitDelay。具體設置見下面的連接。
解決方法：
打開注冊表：ctrl+r 輸入regedit
進入注冊表，路徑為：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
新建DWORD值，（十進制）設置為30秒。名稱:TcpTimedWaitDe,值:30
新建DWORD值，（十進制）最大連接數65534。名稱:MaxUserPort,值:65534
4. Non HTTP response code: java.net.SocketException/Non HTTP response message: Permission denied...
最近在做性能測試過程中遇到了高並發時，后台監控各項指標都很正常，但是測試結果中很多Non HTTP response code: java.net.SocketException/Non HTTP response message: Permission denied: connect的錯誤，翻了一下帖子發現是system.properties中配置有些問題，特此記錄一下，沒有時間細分析，先上解決方法：
修改%JMETER_HOME%/bin/system.properties文件中的java.net.preferIPv4Stack=true即可；
5.java.net.SocketException: Socket closed問題
解決方法： 將每條HTTP Request 添加以下配置 
在Advanced中配置 implementation 選擇HttpClient4,Connect 選擇連接保持時間 單位為毫秒
6. java.net.SocketException/Non HTTP response message: Connection reset
user.properties：
httpclient4.retrycount=1
hc.parameters.file=hc.parameters
hc.parameters：
http.connection.stalecheck$Boolean=true
7. Jmeter壓測報錯：Non HTTP response code: java.net.ConnectExceptionexception的解決辦法
前一段時間進行jmeter壓測時，一直報錯，查看了下日志才發現報了一堆Non HTTP response code: java.net.ConnectExceptionexception，直接jmeter就沒發送到服務端
本想加個Constant Throughput Timer去進行控制qps從而避免錯誤率，可是那樣qps就不是服務器的最大壓力值了。
想了好幾種方法，也將jmeter.properties中的httpclienc.timeout調大去嘗試，還是有這個錯誤
最后試了一下將client implementation配置成java，結果奇跡出現了，發送不出去的錯誤被避免了，qps的量也上來了
總結：有加解密的情況下，默認的HTTPClinet在POST時會自動將特殊字符轉義，然而Java在發送過程中卻未處理；
jmeter發送http請求時，implementation會有以下幾種選項
JAVA：使用的是JAVA JVM提供的http方法，但有一定的限制，
1、當jmeter釋放一個請求后，同樣的進程中可能不會再使用了；
2、只使用於單進程模式；
3、不支持虛擬主機，不支持相關的方法，不支持存儲證書的請求
HttpClient4.1：使用的是Apache HttpClient4.1部件
空白：使用Http默認請求中配置或jmeter.properties中jmeter.httpsample中的配置
8. Jmeter之Non HTTP response code: java.net.SocketException/Non HTTP response message: Permission denied: connect
最近在做性能測試過程中遇到了高並發時，后台監控各項指標都很正常，但是測試結果中很多Non HTTP response code: java.net.SocketException/Non HTTP response message: Permission denied: connect的錯誤，翻了一下帖子發現是system.properties中配置有些問題，特此記錄一下，沒有時間細分析，先上解決方法：
修改%JMETER_HOME%/bin/system.properties文件中的java.net.preferIPv4Stack=true即可；
需要了解原因的可以參考該貼：
https://blog.csdn.net/hualusiyu/article/details/53490183
9. Connection reset
Apache JMeter對啟用SSL的應用程序執行性能和/或負載測試時，SSL套接字錯誤可能是經常遇到的麻煩，嚴重阻礙了您的測試工作。本文重點介紹如何通過相應地配置和調優JMeter來克服這些與連接相關的錯誤。
在Jmeter中指示SSL套接字問題的錯誤消息示例包括：
Non HTTP response code: java.net.SocketException Non HTTP response message: Connection reset`
`Non HTTP response code: java.net.SocketTimeoutException Non HTTP response message: connect timed out`
`Non HTTP response code: java.net.SocketTimeoutException Non HTTP response message: Read timed out
建議＃1：使用最新版本的JMeter
強烈建議使用最新版本，以利用新的改進和組件。
避免在最后一個版本之前使用早於3個版本的版本。
建議＃2：在JMeter中啟用DEBUG模式
將以下內容添加到jmeter.properties以啟用JMeter Logger面板：
jmeter.loggerpanel.display=true
要通過JMeter菜單將日志級別增加到DEBUG：
Options -> Log Level -> DEBUG 
要通過log4j2.xml啟用上下文和線路日志記錄的調試模式：
<Logger name="org.apache.http" level="debug" />
建議＃3：設置連接超時
JMeter中的默認連接超時是開箱即用的20秒。為幫助診斷和解決套接字連接問題，增加此值通常很有幫助。為此，請在JMeter測試計划中為HTTP Request對象指定更高的連接超時。例如，設置為60000（毫秒）以將總超時增加到60秒。
從“配置元素”選項中添加“HTTP請求默認”配置元素（即，右鍵單擊測試計划並添加此“HTTP請求默認值”）。
在“HTTP請求默認值”中，有一個選項 - 連接'超時（毫秒）'在此字段中指定您的連接超時值，它將應用於所有子采樣器。如果在測試計划級別添加了“HTTP請求默認值”，則它將應用於所有采樣器和所有線程組。
要指定單獨的連接超時，請在每個采樣器的相同字段中指定。單個采樣器連接超時將覆蓋“HTTP請求默認”連接超時值。
建議＃4：延遲線程創建
JMeter可以選擇延遲線程創建，直到線程開始采樣（即，在任何線程組延遲和線程本身的加速時間之后）。這允許非常大的線程總數，前提是不會有太多並發的線程。
建議5：禁用並行下載
JMeter使用更多資源來模擬瀏覽器並行獲取嵌入資源，如css，gif，js和靜態內容。如果有許多用戶，則可能會創建太多線程，並且由於JMeter端的帶寬爭用而開始對響應時間產生負面影響。如果要模擬許多用戶，建議禁用並行下載，因為JMeter不會模擬瀏覽器的緩存，瀏覽器也不會在后續請求中重新下載嵌入式資源。
建議＃6：配置受信任和客戶端SSL證書
如果您的應用程序服務器層上有內部簽名或自簽名證書，則需要將JMeter配置為將這些證書識別為有效。要解決此問題，請修改system.properties並使用相關的簽名者證書配置信任庫。
# Truststore properties (trusted certificates)javax.net.ssl.trustStore=C:/trust.jksjavax.net.ssl.trustStorePassword=sample
如果您的應用程序需要SSL客戶端證書身份驗證或授權，則需要創建密鑰庫並在指向該密鑰庫的system.properties文件中設置以下屬性：
# Keystore properties (client certificates)javax.net.ssl.keyStore=C:/key.jksjavax.net.ssl.keyStorePassword=sample
建議7：調整JMeter SSL配置
在jmeter.properties中設置下面的屬性，以調整JMeter處理SSL會話，協議和密碼的方式：
要啟用SSL會話共享：
https.sessioncontext.shared=true
設置默認HTTPS協議級別：
https.default.protocol=TLSv1.2
要啟用多個HTTPS協議：
https.socket.protocols=TLSv1 TLSv1.2
要啟用多個密碼：
https.cipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
要在測試期間保留SSL上下文：
https.use.cached.ssl.context=true
在http 4上設置重試次數
httpclient4.retrycount=1
建議＃8：啟用陳舊連接檢查
為避免HTTP連接池出現問題，可能需要在JMeter中啟用陳舊連接檢查。在JMeter測試運行期間接收“Socket Closed”異常時，應使用此步驟。要啟用過時連接檢查，請在user.properties中設置以下屬性：
http.connection.stalecheck$Boolean=true
建議＃9：在Web服務器上啟用HTTP Keep-Alive
Keep-Alive是HTTP協議的一個非常重要的特性。它允許客戶端通過單個TCP連接發出多個HTTP請求。這提供了很大的性能提升，因為否則建立許多TCP連接將產生大量不必要的網絡開銷。
建議＃10：檢查負載均衡器配置
如果負載測試遇到負載均衡器前端的應用程序，請確保負載均衡器配置了足夠的最大連接限制以處理預期負載。同樣，驗證負載平衡算法不會將過多的流量偏向一個或多個應用程序服務器實例，並且該負載充分分散在應用程序服務器后端之間。
9 .高並發下載tomcat下的文件時，發生java.net.SocketException: Connection reset解決方案
（1）問題產生：使用500個線程並發下載tomcat工程中的一個文件時，服務器出現java.net.SocketException: Connection reset異常，
客戶端出現connect timeout；
（2）分析認為是服務器連接超過最大並發數而重置，導致客戶端連接超時；
於是配置tomcat的配置文件，修改最大並發連接數：
在/home/econf/apache-tomcat-6.0.20/conf目錄下，修改server.xml 在<Connector port="8080" 標簽內添加 maxThreads="500" minSpareThreads="50" maxSpareThreads="100" enableLookups="false" acceptCount="500"
之后重啟tomcat
此問題解決
10. Jmeter 遇到的問題：rc="Non HTTP response code: java.net.NoRouteToHostException" rm="Non HTTP response mess
在使用Jmeter壓測時，遇到日志中有大量的錯誤：
rc="Non HTTP response code: java.net.NoRouteToHostException" rm="Non HTTP response message: Cannot assign requested address" 如下圖：
原因：Jmeter 發壓機的端口不夠用
解決辦法： \1. netstat|grep TIME_WAIT |wc -l 查看目前處在TIME_WAIT狀態的值大不大 \2. 檢查系統sysctl中配置項：（/etc/sysctl.conf） net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_max_tw_buckets = 10000 （5000也OK，主要是前兩個值） \3. 如果上面三個值都正常，cat /proc/sys/net/ipv4/ip_local_port_range 查看可使用的端口范圍。如果是默認范圍，可修改為：net.ipv4.ip_local_port_range = 1024 65535 \4. 執行：sysctl -p ，使設置立即生效。
11. 采坑匯總
踩坑一：
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: connect timed out
查看Load time的時間要大於request設置的connect time out時間，所以拋出該異常。可能是由於服務端有較多請求正在處理（且處理時間較長），導致JMeter不能連接上服務器而產生的。
踩坑二：
Java.NET.BindException: Address already in use: connect
原因：短時間內new socket操作很多,而socket.close()操作並不能立即釋放綁定的端口,而是把端口設置為TIMEWAIT 狀態,過段時間(默認240s)才釋放,(用netstat -na可以看到),最后系統資源耗盡(windows上是耗盡了pool of ephemeral ports ,這段區間在1024-5000之間)
解決方法：在運行JMeter agent的機器上，添加注冊表條目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort：最大動態端口數（Default = 5000, Max = 65534）
TcpTimedWaitDelay：TCP等待延遲時間（30）
TcpNumConnections：TCP最大連接數（Default = 16,777,214）
MaxFreeTcbs：最大TCP控制塊（1000-2000）
MaxHashTableSize：最大TCB Hash table數量（64-65536）
解析中值為10進制，下方腳本已全轉換為16進制
Windows Registry Editor Version 5.00
"MaxUserPort"=dword:fffe
"TcpTimedWaitDelay"=dword:1e
"TcpNumConnections"=dword:fffffe
"MaxFreeTcbs"=dword:7D0
"MaxHashTableSize"=dword:10000
踩坑三：
java.lang.OutOfMemoryError: Java heap space
原因：觀察運行jmeter機器的內存，占用較高，超過了jmeter設置的內存上限。
解決方案：修改jmeter配置文件，調整內存可用的范圍
修改/bin/jmeter.bat文件：找到這2行
set HEAP=-Xms256m -Xmx256m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
改為：
set HEAP=-Xms1024m –Xmx2048m（最大值不能超過系統內存的1/2）
set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m
踩坑四：
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: Read timed out
發生該錯誤時，jmeter已經連接上服務器，查看load time沒有超過設定的request timeout時間，錯誤可能的原因是，服務器那邊未處理該線程的請求，或者為保證服務能力，斷掉了連接。
為了驗證該猜想，持續大於半小時向服務器發送該並發數量的請求，一段時間后，request收到503的response，證明猜想。
踩坑五：
Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:
原因：分布式測試時，server和agent之間的連接有問題。單個機器排查后，發現是某個agent機器安裝了多個網卡，rmi遠程的時候找的是虛擬機的網卡，導致連接失敗。
解決方案：禁掉不使用的虛擬機網卡，測試之后再恢復。
踩坑六：
接口參數有中文時，請求后傳參是亂碼？
內容編碼設置為utf-8
踩坑七：
接口參數化有中文時，請求后傳參是亂碼？
內容編碼設置為gb2312
踩坑八：
請求接口響應亂碼，編碼問題修改配置文件：
jmeter.properties中的sampleresult.default.encoding參數，改成sampleresult.default.encoding=utf-8
jmeter安裝路徑，改參數E:\jmeter\apache-jmeter-3.0\bin文件jmeter.properties中
#sampleresult.default.encoding=ISO-8859-1改為
sampleresult.default.encoding=utf-8
12. Jmeter問題集錦
踩坑一：
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: connect timed out
查看Load time的時間要大於request設置的connect time out時間，所以拋出該異常。可能是由於服務端有較多請求正在處理（且處理時間較長），導致JMeter不能連接上服務器而產生的。
踩坑二：
Java.NET.BindException: Address already in use: connect
原因：短時間內new socket操作很多,而socket.close()操作並不能立即釋放綁定的端口,而是把端口設置為TIMEWAIT 狀態,過段時間(默認240s)才釋放,(用netstat -na可以看到),最后系統資源耗盡(windows上是耗盡了pool of ephemeral ports ,這段區間在1024-5000之間)
解決方法：在運行JMeter agent的機器上，添加注冊表條目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort：最大動態端口數（Default = 5000, Max = 65534）
TcpTimedWaitDelay：TCP等待延遲時間（30）
TcpNumConnections：TCP最大連接數（Default = 16,777,214）
MaxFreeTcbs：最大TCP控制塊（1000-2000）
MaxHashTableSize：最大TCB Hash table數量（64-65536）
解析中值為10進制，下方腳本已全轉換為16進制
Windows Registry Editor Version 5.00
"MaxUserPort"=dword:fffe
"TcpTimedWaitDelay"=dword:1e
"TcpNumConnections"=dword:fffffe
"MaxFreeTcbs"=dword:7D0
"MaxHashTableSize"=dword:10000
踩坑三：
java.lang.OutOfMemoryError: Java heap space
原因：觀察運行jmeter機器的內存，占用較高，超過了jmeter設置的內存上限。
解決方案：修改jmeter配置文件，調整內存可用的范圍
修改/bin/jmeter.bat文件：找到這2行
set HEAP=-Xms256m -Xmx256m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
改為：
set HEAP=-Xms1024m –Xmx2048m（最大值不能超過系統內存的1/2）
set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m
踩坑四：
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: Read timed out
發生該錯誤時，jmeter已經連接上服務器，查看load time沒有超過設定的request timeout時間，錯誤可能的原因是，服務器那邊未處理該線程的請求，或者為保證服務能力，斷掉了連接。
為了驗證該猜想，持續大於半小時向服務器發送該並發數量的請求，一段時間后，request收到503的response，證明猜想。
踩坑五：
Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:
原因：分布式測試時，server和agent之間的連接有問題。單個機器排查后，發現是某個agent機器安裝了多個網卡，rmi遠程的時候找的是虛擬機的網卡，導致連接失敗。
解決方案：禁掉不使用的虛擬機網卡，測試之后再恢復。
踩坑六：
接口參數有中文時，請求后傳參是亂碼？
內容編碼設置為utf-8
踩坑七：
接口參數化有中文時，請求后傳參是亂碼？
內容編碼設置為gb2312
踩坑八：
請求接口響應亂碼，編碼問題修改配置文件：
jmeter.properties中的sampleresult.default.encoding參數，改成sampleresult.default.encoding=utf-8
jmeter安裝路徑，改參數E:\jmeter\apache-jmeter-3.0\bin文件jmeter.properties中
#sampleresult.default.encoding=ISO-8859-1改為
sampleresult.default.encoding=utf-8
13. JMeter測試問題：java.net.SocketTimeoutException: connect timed out，Read timed out
-
JMeter測試計划線程組設置：Ramp-UP Period為5秒。勾選【delay thread creation until needed 】允許需要時創建線程。循環次數設為10。
-
線程組包含兩個請求，分別是①上傳數據，②下載數據。設置兩個請求之間sleep 3000ms。其他為缺省設置。
-
每個請求connect time out：3000ms
-
每個請求response time out：3000ms
分別以遞增線程數執行測試，由兩個agent分別執行。在線程數為500時，產生錯誤：
錯誤1：Response message: Non HTTP response message: connect timed out
錯誤分析：通過Load time值看，由於該線程耗費時間（3002）大於設置的connect time out（3000ms），因此拋出該異常。問題可能是由於服務端有較多請求正在處理（且處理時間較長），導致JMeter不能連接上服務器而產生的。
JMeter原始錯誤信息：
概要：
Thread Name: 線程組 1-367
Sample Start: 2013-07-05 11:04:17 CST
Load time: 3002
Latency: 0
Size in bytes: 1677
Headers size in bytes: 0
Body size in bytes: 1677
Sample Count: 1
Error Count: 1
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: connect timed out
詳細信息：
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:395)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:234)
at sun.net.www.http.HttpClient.New(HttpClient.java:307)
at sun.net.www.http.HttpClient.New(HttpClient.java:324)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:970)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836)
at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.sample(HTTPJavaImpl.java:487)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1088)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1077)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:428)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:256)
at java.lang.Thread.run(Thread.java:662)
錯誤2：Response message: Non HTTP response message: Read timed out
錯誤分析：通過返回錯誤信息看，發生該錯誤時，JMeter已經連接上服務器，但是產生read time out。從load time（2998）看，所用時間並沒有超過設定超時時間（3000），因此錯誤不大可能是JMeter本身產生的。一種可能是，服務器那邊未處理該線程的請求，或者為保證服務能力，斷掉了連接。
JMeter原始錯誤信息：
概要：
Thread Name: 線程組 1-10
Sample Start: 2013-07-05 11:12:45 CST
Load time: 2988
Latency: 0
Size in bytes: 2431
Headers size in bytes: 0
Body size in bytes: 2431
Sample Count: 1
Error Count: 1
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: Read timed out
詳細信息：
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:697)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:640)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2300)
at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:579)
at java.net.URLConnection.getContentLength(URLConnection.java:474)
at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.readResponse(HTTPJavaImpl.java:230)
關於JMeter結果指標值說明的：
http://www.cnblogs.com/Carrie_Liang/archive/2008/11/10/1330997.html
http://asmetg.blog.163.com/blog/static/105828863201111644313362/
回到通常的情況，最近幾天，當我為一項測試增加虛擬用戶數量時，遇到了以下錯誤。我試圖測試低至90個虛擬用戶的J2EE應用程序，每個虛擬用戶的啟動時間為一秒鍾，延遲之間的間隔為一秒鍾。
錯誤– jmeter.protocol.http.sampler.HTTPSampler：readResponse：java.net.SocketTimeoutException：讀取超時
錯誤– jmeter.protocol.http.sampler.HTTPSampler：原因：java.net.SocketTimeoutException：讀取超時
錯誤– jmeter.protocol.http.sampler.HTTPSampler：readResponse：java.net.SocketException：服務器中的文件意外結束
我花了幾個小時試圖在互聯網上找到有關此錯誤消息的信息，但是在閱讀了一些主題並注意到Google返回的結果少於我的搜索結果之后，我開始想像這不是我的jmeter中的問題配置，但在應用程序本身。當然，這本來應該是尋找的第一位，但是我有點失去了注意力，考慮了所有其他可能的因素，例如JMeter Agent內存，Glassfish一側的最大連接數，Glassfish一側的最大線程數， EJB池效率，JDBC池效率等。
因此，我首先嘗試的是使用最少1個JMeter Agent（而不是3個）再次運行該測試，並將虛擬用戶數量從1、2、4、6和10增加到10。一旦我開始對超過6個虛擬用戶進行測試，錯誤就會開始出現。因此，我得出這樣的結論：某些應用程序請求執行時間太長，使應用程序服務器的線程繁忙，並且不允許傳入請求使用資源。
因此，我再次在一個簡單的JMeter GUI中運行了相同的測試，將線程組配置為10個虛擬用戶。結果呢？我的要求之一是大約需要30秒才能完成（對於10個用戶），而大約要花6秒（對於1個虛擬用戶），再次運行測試，逐漸增加n個虛擬用戶，僅證實了我的理論，即響應時間在增加與虛擬用戶數量成比例（當然，我在想什么？
很明顯，當我的請求中有5個花了30秒以上才能完成（因此5個可用的http線程正忙）時，就沒有空間容納第六，第七等等。
因此，對於仍然在尋找該錯誤的所有人，它在您的應用程序實現中占90％以上。某種東西正在占用資源，服務器斷開了連接。以增量方式檢查所有請求，並找到瓶頸。
並且總是從最后一步開始（在這種情況下，我沒有這樣做!
希望這會有所幫助。如果我找到了它，我肯定會使用它
使用Jmeter做性能測試前需要修改的配置
使用jmeter對多個項目做性能測試后發現，jmeter很多默認配置是無法支持我們直接開始性能測試任務的；所以在此本人收集了一些未修改配置時會出現的常見問題，並給出了對應的解決方案
問題一：接口錯誤信息為java.net.BindException: Address already in use 原因： 短時間內new socket操作很多,而socket.close()操作並不能立即釋放綁定的端口,而是把端口設置為TIMEWAIT 狀態,過段時間才釋放,(用netstat -na可以看到),最后系統資源耗盡(windows上是耗盡了pool of ephemeral ports ,這段區間在1024-5000之間)。 解決辦法： 1.按win+R打開運行，輸入regedit命令打開注冊表； 2.在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下， 1）右擊parameters，添加一個新的DWORD，名字為MaxUserPort 2）然后雙擊MaxUserPort，輸入數值數據為65534，基數選擇十進制 3.重啟電腦
問題二：運行jmeter腳本后無數據返回，jmeter server顯示連接后就立即結束 原因： 這是剛接觸jmeter工具不久的朋友，或者是在使用分布式部署之后容易犯的錯誤，Jmeter執行時未獲取到參數化文件csv data set config地址中的數據 解決辦法： jmeter測試數據slave機器一定要存放，並且master機器的csv測試數據地址要以填寫slave機器的地址
問題三：jmeter運行時報內存溢出OutOfMemoryError 原因： Jmeter預設的內存不足，需要手動修改 解決辦法： windows環境下，修改jmeter.bat： set HEAP=-Xms256m -Xmx256m set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m 改為： set HEAP=-Xms512m -Xmx2048m set NEW=-XX:NewSize=256m -XX:MaxNewSize=1024m （此數據可根據自己電腦性能適當修改） linux環境下，修改jmeter.sh java $JVM_ARGS -Xms1G -Xmx5G -XX:MaxPermSize=512m -Dapple.laf.useScreenMenuBar=true -jar dirname $0/ApacheJMeter.jar “$@”
問題四：jmeter亂碼問題 解決辦法： 在jmeter.properties 這個文件里面找到sampleresult.default.encoding=xx，后面xx改成utf-8，然后刪除前面的注釋符號#。 如jmeter的body里面中文顯示不出來，可找到JSyntaxTextArea然后把以js開頭的注釋取消。 JDBC請求查詢結果亂碼，可在JDBC連接配置中將URL加上characterEncoding=UTF-8
問題五：jmeter只有status信息，無response詳細信息 原因： Jmeter默認禁掉了運行過程中每個request的具體response信息收集，只保留了status 解決辦法： 修改jmeter.properties文件中Results file configuration。把所有和response相關False的項改為True
1、修改物理內存
使用jmeter進行壓力測試時遇到一段時間后報內存溢出outfmenmory錯誤，導致jmeter卡死了，先嘗試在jmeter.bat中增加了JVM_ARGS="-Xmx2048m -Xms2048m -Xmn256m -XX:PermSize=128m -Xss256k"，但結果運行時間增加了，但最終還是報內存溢出，百度后按照網友的建議更改了如下設置后jmeter就沒有再卡了：
1、windows環境下，修改jmeter.bat： set HEAP=-Xms512m -Xmx4000m set NEW=-XX:NewSize=256m -XX:MaxNewSize=1024m 改為： set HEAP=-Xms256m -Xmx1024m set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m set PERM=-XX:PermSize=1024m -XX:MaxPermSize=1024m 根據經驗，heap最多設置為物理內存的一半，默認設置為512M.如果heap超過物理內存的一半，可能運行jmeter會慢，甚至出現內存溢出，原因java比較吃內存，占CPU.
注意：JDK32位的電腦Xmx不能超過1500m，最大1378m.否則在啟動Jmeter時會報錯：
2、jmeter 錄制 排除/包含模式設置
設置包含模式及排除模式，若不設置，在錄制完之后，可以把不需要的.css .jpg的行刪掉。標准的包含模式及排除模式如下所列。
i. .* - all
ii. .*.png – png images
iii. .*.gif – gif images
iv. .*.jpg – jpeg images
v. .*.php
vi. .*.jsp
vii. .*.html
viii. .*.htm
ix. .*.js
3、jmeter 可視化圖形報告配置
1、使用CMD 進入jmeter bin目錄
輸入：jmeter -n -t （腳本路徑） -l testLogFile -e -o （存放報告的路徑）
樣本：jmeter -n -t C:\Users\samsung-\Desktop\接口報告\腳本\登錄頁面+我的窩頁.jmx -l testLogFile -e -o ./out
2、對已有的CSV文件生成報告，需配置jmeter.properties
配置修改：
jmeter.save.saveservice.bytes = true
# Only available with HttpClient4
#jmeter.save.saveservice.sent_bytes=true
jmeter.save.saveservice.label = true
jmeter.save.saveservice.latency = true
jmeter.save.saveservice.response_code = true
jmeter.save.saveservice.response_message = true
jmeter.save.saveservice.successful = true
jmeter.save.saveservice.thread_counts = true
jmeter.save.saveservice.thread_name = true
jmeter.save.saveservice.time = true
jmeter.save.saveservice.connect_time = true
# the timestamp format must include the time and should include the date.
# For example the default, which is milliseconds since the epoch:
jmeter.save.saveservice.timestamp_format = ms
# Or the following would also be suitable
jmeter.save.saveservice.timestamp_format = yyyy/MM/dd HH:mm:ss如果需要Errors報告更詳細，配置：jmeter.save.saveservice.assertion_results_failure_message = true使用事物控制器請確認Generate parent sample為未勾選
對已有CSV日志文件生成報告
命令：jmeter -g <log file> -o <Path to output folder>
參考：http://www.cnblogs.com/greattao/p/6813156.html
4、上傳圖片
某些瀏覽器（例如Firefox和Opera）在上傳文件時不包含文件的全名。這可能導致JMeter代理服務器失敗。一個解決方案是確保任何要上傳的文件都位於JMeter工作目錄中，方法是復制文件，或者在包含文件的目錄中啟動JMeter。
5、記錄在JMeter中本機不可用的基於HTTP的非文本協議
您可能需要記錄JMeter（自定義二進制協議，Adobe Flex，Microsoft Silverlight，...）默認情況下未處理的HTTP協議。雖然JMeter不提供本地代理實現來記錄這些協議，但您可以通過實現自定義SamplerCreator來記錄這些協議。此采樣器創建者將將二進制格式轉換為可添加到JMeter測試用例的HTTPSamplerBase子類。有關詳細信息，請參閱“擴展JMeter”。
6、JMeter4.0版本修改成中文界面
分布式壓測配置修改及啟動
配置修改: 修改 master 配置 修改 jmeter.properties remote_hosts 字段值，IP 為分布式 agent 的 IP 和端口。端口默認值 1099。 remote_hosts=agent1IP:1099,agent2IP:1099
修改 slave 配置 -Jserver.rmi.ssl.disable=true
壓測命令：
分別在不同 slave 上啟動分布式 agent jmeter-server -Jserver.rmi.ssl.disable=true -Djava.awt.headless=true -Djava.rmi.server.hostname=agent1IP
jmeter-server -Jserver.rmi.ssl.disable=true -Djava.awt.headless=true -Djava.rmi.server.hostname=agent2IP master 機器上使用命令 jmeter -Djava.awt.headless=true -Jserver.rmi.ssl.disable=true -n -t c.jmx -R agent1IP,agent2IP -l test.jtl
二
jmeter常見錯誤：
-
錯誤一： Response code: Non HTTP response code: java.net.SocketTimeoutException Response message: Non HTTP response message: connect timed out
查看Load time的時間要大於request設置的connect time out時間，所以拋出該異常。可能是由於服務端有較多請求正在處理（且處理時間較長），導致JMeter不能連接上服務器而產生的。
-
錯誤二： Java.NET.BindException: Address already in use: connect
原因：短時間內new socket操作很多,而socket.close()操作並不能立即釋放綁定的端口,而是把端口設置為TIMEWAIT 狀態,過段時間(默認240s)才釋放,(用netstat -na可以看到),最后系統資源耗盡(windows上是耗盡了pool of ephemeral ports ,這段區間在1024-5000之間) 解決方法：在運行JMeter agent的機器上，添加注冊表條目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters MaxUserPort 65334 TcpTimedWaitDelay 30
-
錯誤三： java.lang.OutOfMemoryError: Java heap space
原因：觀察運行jmeter機器的內存，占用較高，超過了jmeter設置的內存上限。 解決方案：修改jmeter配置文件，調整內存可用的范圍
修改/bin/jmeter.bat文件：找到這2行 set HEAP=-Xms256m -Xmx256m set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m 改為： set HEAP=-Xms1024m –Xmx2048m（最大值不能超過系統內存的1/2） set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m
-
錯誤四： Response code: Non HTTP response code: java.net.SocketTimeoutException Response message: Non HTTP response message: Read timed out
發生該錯誤時，jmeter已經連接上服務器，查看load time沒有超過設定的request timeout時間，錯誤可能的原因是，服務器那邊未處理該線程的請求，或者為保證服務能力，斷掉了連接。 為了驗證該猜想，持續大於半小時向服務器發送該並發數量的請求，一段時間后，request收到503的response，證明猜想。
-
錯誤五： Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:
原因：分布式測試時，server和agent之間的連接有問題。單個機器排查后，發現是某個agent機器安裝了多個網卡，rmi遠程的時候找的是虛擬機的網卡，導致連接失敗。 解決方案：禁掉不使用的虛擬機網卡，測試之后再恢復。
jmeter**腳本運行的過程中，服務器性能參數沒有明顯變化（CPU，內存，I/O），但request的響應時間很長。**
原因：觀察jmeter agent機器網絡使用情況，網絡使用持續達到帶寬的限制峰值。request 發送的過程中pending在網絡中，實際並發的request並沒有同一時間到達服務器，所以服務器沒有明顯變化。 解決方案：提高jmeter agent機器網絡帶寬。
-
錯誤六：
Connection timed out: connect
java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:121)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.jmeter.protocol.http.sampler.hc.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:318)
at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:114)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:654)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:413)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.followRedirects(HTTPSamplerBase.java:1542)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1636)
at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:519)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:493)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491)
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254)
at java.lang.Thread.run(Unknown Source)
原因分析：
可能是因為端口號耗盡，一般一台服務器的端口號最多是65535個，建議使用該命令分別查看下壓測機與服務器的端口使用情況，netstat -nat|grep -i 8080|wc -l，如果這個個數在6w左右，那可能就是端口號用盡,同時查看下大多數的端口狀態，應該都是time_wait狀態 解決方案： 如果是壓測機，端口號用盡，那就增加壓測機，使用jmeter分布式壓測（jmeter默認開啟keep_alive的） 如果數服務器，端口號用盡，最大的可能是服務器端開了短鏈接，把短鏈接配置變成長連接即可 因為如果服務器端是短鏈接，當jmeter每發起一個請求就會建立一次tcp三次握手，傳輸完數據后，連接其實沒有關，連接狀態是time_wait,下個請求來了，會重新開啟一個新的端口，建立tcp三次握手，傳輸數據....，這樣隨着請求的越來越多，端口就會變得越來越少，所以端口很快耗盡，而且大多數端口都處於time_wait狀態,如果服務器端也支持長連接，那么下次請求來了，就會在上次請求的通道上繼續傳輸，端口使用率大大的降低，就有效的避免了端口耗盡問題。
原因：Jmeter默認禁掉了運行過程中每個request的具體response信息收集，只保留了status。 解決方法：修改jmeter.properties文件中Results file configuration。把所有和response相關False的項改為True。運行后將輸出保存.jtl文件中。添加tree監聽器，過濾只顯示error request，可以查看到request和response的具體信息，從而判斷出錯原因。
tree report**中顯示socket time out相關的錯誤，如何判斷是jmeter工具的原因，還是服務器的原因。**