https://www.cnblogs.com/kasuo/archive/2013/06/06/3122295.html
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工具的原因，還是服務器的原因。
