php並發測試

① 為什麼這么多人覺得運行php的並發可以上1000

關鍵還在於nginx+php+fastcgi搭建完或搭建過程中的一些優化。

② 解決FastCGI 進程超過了配置的活動超時時限的問題

近日，需要滿足測試需求，進行大數據並發測試時，報出【HTTP
錯誤
500.0
-
Internal
Server
Error
E:PHPphp-cgi.exe
-
FastCGI
進程超過了配置的活動超時時限】
解決辦法：
IIS7->FastCGI設置->雙擊"php-cgi.exe"->"活動超時"
項默認是設置為70(秒)，改為600(10分鍾，此處根據需求設置可以略高~)

③ PHP做游戲服務端可以達到多少並發

PHP做游戲服務端可以達到並發十萬。

包括使用緩存加速工具，經過優化後web性能有明顯的提高。這是我用壓力測試工具測試的並發數量。

自己下載個軟體來做下壓力測試才能得出較准確的數據，使用nginx更多是用來支持動態頁面，而且還可以做代理和一些限制設置，但論功能而言比apache更廣， apache 更擅長於對靜態頁面的解釋，穩定且比nginx配置更為簡單。

2012年數據：

2012上半年，中國游戲市場(包括PC網路游戲市場、移動網路游戲市場、PC單機游戲市場等)實際銷售收入248.4億元人民幣，比2011上半年增長了18.5%。

2012上半年，中國PC網路游戲市場實際銷售收入（包括了客戶端網游、網頁游戲、社交遊戲及游戲平台的市場銷售額）為235.5億元人民幣，比2011上半年增長了16.9%。

2012上半年，中國自主研發的PC網路游戲市場實際銷售收入為168.6億元人民幣，占網路游戲市場實際銷售收入的71.6%，較2011年同期的63%左右有明顯提升。

④ php寫的程序，進行性能測試，各項資源都正常，增加並發，tps不增長，響應時間增長，您覺得瓶頸在哪

問題沒說清楚，也不好下定論啊，如果性能測試就壓100個用戶，在沒達到瓶頸的情況，各項指標應該都是平穩的，波動起伏不會太大，只有慢慢增加用戶，才會知道瓶頸所在隨著用戶的增加，下面各值會跟隨增加吞吐量，CPU，點擊率。。。等事務響應時間（這個系統一般沒達到極限是不變的）當事務響應時間開始明顯變長，說明系統達到了極限可以是CPU極限，可能是點擊率極限，可能是網路極限。。。你繼續增加用戶了，響應時間變長，吞吐量點擊開始明顯下降，說明就到瓶頸了，然後在看是什麼地方的瓶頸如果單一的吞吐量上不去，也可能是用戶訪問不多，吞吐量當然上不去

⑤ php 高並發解決思路解決方案

php 高並發解決思路解決方案，如何應對網站大流量高並發情況。本文為大家總結了常用的處理方式，但不是細節，後續一系列細節教程給出。希望大家喜歡。

一 高並發的概念

在互聯網時代，並發，高並發通常是指並發訪問。也就是在某個時間點，有多少個訪問同時到來。

二 高並發架構相關概念

1、QPS (每秒查詢率) : 每秒鍾請求或者查詢的數量，在互聯網領域，指每秒響應請求數(指 HTTP 請求)

2、PV（Page View）：綜合瀏覽量，即頁面瀏覽量或者點擊量，一個訪客在 24 小時內訪問的頁面數量

--註：同一個人瀏覽你的網站的同一頁面，只記做一次 pv

3、吞吐量（fetches/sec） ：單位時間內處理的請求數量 （通常由 QPS 和並發數決定）

4、響應時間：從請求發出到收到響應花費的時間

5、獨立訪客（UV）：一定時間范圍內，相同訪客多次訪問網站，只計算為 1 個獨立訪客

6、帶寬：計算帶寬需關注兩個指標，峰值流量和頁面的平均大小

7、日網站帶寬： PV/統計時間（換算到秒） * 平均頁面大小（kb）* 8

三 需要注意點：

1、QPS 不等於並發連接數（QPS 是每秒 HTTP 請求數量，並發連接數是系統同時處理的請求數量）

2、峰值每秒請求數（QPS）= （總 PV 數*80%）/ （六小時秒數*20%）【代表 80%的訪問量都集中在 20%的時間內】

3、壓力測試： 測試能承受的最大並發數 以及測試最大承受的 QPS 值

4、常用的性能測試工具【ab，wrk，httpload，Web Bench，Siege，Apache JMeter】

四 優化

1、當 QPS 小於 50 時

優化方案:為一般小型網站,不用考慮優化

2、當 QPS 達到 100 時,遇到數據查詢瓶頸

優化方案: 資料庫緩存層,資料庫的負載均衡

3、當 QPS 達到 800 時, 遇到帶寬瓶頸

優化方案:CDN 加速,負載均衡

4、當 QPS 達到 1000 時

優化方案: 做 html 靜態緩存

5、當 QPS 達到 2000 時

優化方案: 做業務分離,分布式存儲

五、高並發解決方案案例:

1、流量優化

防盜鏈處理(去除惡意請求)

2、前端優化

(1) 減少 HTTP 請求[將 css,js 等合並]

(2) 添加非同步請求(先不將所有數據都展示給用戶,用戶觸發某個事件,才會非同步請求數據)

(3) 啟用瀏覽器緩存和文件壓縮

(4) CDN 加速

(5) 建立獨立的圖片伺服器(減少 I/O)

3、服務端優化

(1) 頁面靜態化

(2) 並發處理

(3) 隊列處理

4、資料庫優化

(1) 資料庫緩存

(2) 分庫分表,分區

(3) 讀寫分離

(4) 負載均衡

5、web 伺服器優化

(1) nginx 反向代理實現負載均衡

(2) lvs 實現負載均衡

⑥ jmeter 壓力測試地址佔用

壓測發起設備：windows 10
網路：區域網
壓測軟體：Jmeter 5.0
壓測系統內存：Ubuntu 4核8G
PHP 版本：php7.1.23
Nginx 版本：nginx1.14.0
Mysql版本：5.7.24
Redis: 開啟
CDN：關閉

壓測的初期，在設置了 150qps/s 的並發數下壓測幾分鍾後 Jmeter 就出現了如下報錯。

開始考慮的方向是Nginx、PHP、MySQL做了相關限制導致線程被佔用， 但是修改對應的配置後發現沒有任何效果，該報錯的還是報錯。 查了一波資料，發現 windows 環境下的埠循環回收需要消耗2～4分鍾。由此猜測可能是由於 windows下壓測埠數有限，埠資源被占滿，沒有及時循環回收，導致報錯。

使用 win + R 快捷鍵打開 cmd ，輸入 regedit 命令打開注冊表

2.1 找到 HKEY_LOCAL_ 目錄。

2.2 右擊 Parameters ，添加一個新的 DWORD ，命名為 MaxUserPort 。

2.3 然後雙擊 MaxUserPort ，輸入 65534，基數選擇 十進制（如果是分布式運行的話，控制機器和負載機器都需要這樣操作）。

2.4 修改配置完畢後， 需要重啟 windows 才會生效。

採用上述的解決方案之後，windows 下設置 150qps/s 並發數進行壓測，暫時解決了埠佔用的問題。在此基礎上，將壓測的並發數提高至 700qps/s，兩分鍾內達到 66000+ 個請求，數量超過了 65534 埠數，再次出現了同一報錯。

step1: 使用 win + R 快捷鍵打開 cmd ，輸入 regedit 命令打開注冊表。

step2: 找到 HKEY_LOCAL_ 目錄。

step3: 右擊 parameters ，添加一個新的DWORD，命名為 TcpTimedWaitDelay ，將值設置為 30 , 縮短 TIME_WAIT 的等待時間。

step4: 重啟windows，配置項生效。

Close_Wait 會佔用一個連接，網路可用連接小。當數量過多時，可能會引起網路性能下降，並佔用系統非換頁內存。尤其是在有連接池的情況下(比如 HttpRequest )，會耗盡連接池的網路連接數，導致無法建立網路連接。

step1: 使用 win + R 快捷鍵打開 cmd ，輸入 regedit 命令打開注冊表。

step2: 找到 HKEY_LOCAL_ 目錄。

step3: 在該目錄下添加新的配置項。設置合理的 Keepalive 參數。

step4: 重啟windows，配置項生效。

⑦ 如何使用ab對WebSocket伺服器做並發性能測試

Apache伺服器自帶了ab壓力測試工具，可以用來測試網站性能，使用簡單方便。
工具/原料
Apache
方法/步驟
打開Apache伺服器的安裝路徑，在bin目錄中有一個ab.exe的可執行程序，就是我們要介紹的壓力測試工具。

在Windows系統的命令行下，進入ab.exe程序所在目錄，執行ab.exe程序。注意直接雙擊無法正確運行。

執行ab命令成功後，可以看到如圖提示。該幫助很清楚詳細的介紹了ab的用法以及各個參數的含義。
ab 的用法是：ab [options] [http://]hostname[:port]/path
例如：ab -n 5000 -c 200 http://localhost/index.php
上例表示總共訪問http://localhost/index.php這個腳本5000次，200並發同時執行。

ab常用參數的介紹：
-n ：總共的請求執行數，預設是1；
-c： 並發數，預設是1；
-t：測試所進行的總時間，秒為單位，預設50000s
-p：post時的數據文件
-w: 以html表的格式輸出結果

執行測試用例：ab -n 1000 -c 100 -w http://localhost/index.php >>c:\1.html
上面的測試用例表示100並發的情況下，共測試訪問index.php腳本1000次，並將測試結果保存到c:\1.html文件中。

測試報告如圖，可知在該100並發訪問的情況下，共測試訪問1000次，失敗了852次。可知該腳本在此環境無法滿足100並發訪問的要求。

修改參數繼續測試。測試並發50和30兩種情況，由測試報告得知，在並發訪問降到30時，錯誤的訪問數降為39。
步驟閱讀

⑧ 4顆四核3.6處理器8G內存，要是linux AS4.0+php+Mysql最大並發能達到多少啊

我自己3台伺服器
1台WEB
1台流媒體
1台WEB的數據及圖片等存儲

WEB伺服器，最主要的是CPU的限制
像流媒體，最主要還是帶寬，，其次就是內存
最後一台作為數據存儲的，，主要就是帶寬了

你這個配置已經不錯了，，

並發數無法和你討論，你起碼得將你用途公布，才可以給你一個非常非常粗糙的估算，，和實際的會出入很大。

⑨ 【python】【壓力測試】Locust壓力測試工具

性能測試參數

熟悉 Apache ab 工具的同學都知道，它是沒有界面的，通過命令行執行。 Locust 同樣也提供的命令行運行，好處就是更節省客戶端資源。

啟動參數：
--no-web 表示不使用Web界面運行測試。
-c 設置虛擬用戶數。
-r 設置每秒啟動虛擬用戶數。
-t 設置設置運行時間。

出現的報錯及解決辦法：
使用Locust進行性能測試，Locust no-web模式執行命令locust -f zkxl_verify_ locust.py --host= https://www..com --no-web -c 10 -r 2 -t 1m
提示locust: error: unrecognized arguments: --no-web -c

參考locust官方文檔 https://docs.locust.io/en/latest/running-locust-without-web-ui.html?highlight=no-web
將命令參數--no-web 更改為 --headless，將命令中指定用戶並發數的參數 -c 改為 -u，即更改命令為：locust -f zkxl_verify_ locust.py --host= https://www..com --headless -u 10 -r 2 -t 1m 即可.

locust的測試數據可以保存到CSV文件中，有兩種方法可以進行此操作：
首先，通過Web UI運行Locust時，可以在「Download Data」選項卡下得到CSV文件。
其次，可以使用標簽運行Locust，該標簽將定期保存兩個CSV文件。如果計劃使用--no-web標簽以自動化方式運行Locust

文件將被命名為example_response_times.csv 和 example_stats.csv （使用--csv=example）並記錄Locust構建的信息。
如果你想要更快(慢)的寫入速度，也可以自動以寫入頻率：

此數據將寫入兩個文件，並將_response_times.csv和_stats.csv添加到你提供的名稱中：

和

打開命令提示符（或Linux終端），輸入 locust --help 。

參考： 官方文檔

一旦單台機器不夠模擬足夠多的用戶時，Locust支持運行在多台機器中進行壓力測試。

為了實現這個，你應該在 master 模式中使用 --master 標記來啟用一個 Locust 實例。這個實例將會運行你啟動測試的 Locust 交互網站並查看實時統計數據。master 節點的機器自身不會模擬任何用戶。相反，你必須使用 --slave 標記啟動一台到多台 Locustslave 機器節點，與標記 --master-host 一起使用(指出master機器的IP/hostname)。

常用的做法是在一台獨立的機器中運行master，在slave機器中每個處理器內核運行一個slave實例。

在 master 模式下啟動 Locust:

在每個 slave 中執行(192.168.0.14 替換為你 msater 的IP):

參數

--master

設置 Locust 為 master 模式。網頁交互會在這台節點機器中運行。

--slave

設置 Locust 為 slave 模式。

--master-host=X.X.X.X

可選項，與 --slave 一起結合使用，用於設置 master 模式下的 master 機器的IP/hostname(默認設置為127.0.0.1)

--master-port=5557

可選項，與 --slave 一起結合使用，用於設置 master 模式下的 master 機器中 Locust 的埠(默認為5557)。注意，locust 將會使用這個指定的埠號，同時指定埠+1的號也會被佔用。因此，5557 會被使用，Locust將會使用 5557 和 5558。

--master-bind-host=X.X.X.X`

可選項，與 --master 一起結合使用。決定在 master 模式下將會綁定什麼網路介面。默認設置為*(所有可用的介面)。

--master-bind-port=5557

可選項，與 --master 一起結合使用。決定哪個網路埠 master 模式將會監聽。默認設置為 5557。注意 Locust 會使用指定的埠號，同時指定埠+1的號也會被佔用。因此，5557 會被使用，Locust 將會使用 5557 和 5558。

--expect-slaves=X

在 no-web 模式下啟動 master 時使用。master 將等待X連接節點在測試開始之前連接。

如下圖，我啟動了一個 master 和兩個 slave，由兩個 slave 來向被測試系統發送請求。

client屬性：

TaskSet類:實現了虛擬用戶所執行任務的調度演算法，包括規劃任務執行順序(schele_task)、挑選下一個任務(execute_next_task)、執行任務(execute_task)、休眠等待(wait)、中斷控制(interrupt)等等。
在此基礎上，我們就可以在TaskSet子類中採用非常簡潔的方式來描述虛擬用戶的業務測試場景，對虛擬用戶的所有行為(任務)進行組織和描述，並可以對不同任務的權重進行配置。

在TaskSet子類中定義任務信息時，可以採取兩種方式， @task 裝飾器和 tasks 屬性。

@task(1)中的數字表示任務的執行頻率，數值越大表示執行的頻率越高

採用tasks屬性定義任務：

tasks = {test_job1:1, test_job2:2}中，test_job1:1,test_job2:2表示事件執行的頻率，即test_job2的執行頻率是test_job1的兩倍

on_start函數是在Taskset子類中使用比較頻繁的函數。在正式執行測試前執行一次，主要用於完成一些初始化的工作。
例如，當測試某個搜索功能，而該搜索功能又要求必須為登錄態的時候，就可以先在on_start中進行登錄操作，HttpLocust使用到了requests.Session，因此後續所有任務執行過程中就都具有登錄態了

在TaskSequence類中，[email protected]_task()可以用來控制任務的執行順序；裡面的數值越小執行越靠前；

在Taskset類中，內置WAIT_TIME功能，它用於確定模擬用戶在執行任務之間將等待多長時間。Locust提供了一些內置的函數，返回一些常用的wait_time方法。
1、 between(min,max)函數 ：用得比較多的函數
wait_time = between(3.0, 10.5)：任務之間等待的時間是3到10.5秒之間的任意時間
還可以用任意函數來定義等待時間， 比如平均1秒的等待時間
wait_time = lambda self: random.expovariate(1) 1000
2、 constant(number) 函數：
wait_time=constant(3)：任務之間等待的時候是3秒鍾，且等待的時候不能超過任務運行的總時間，也就是在執行py文件時設置的時間
3、 constant_pacing(number) *函數:
wait_time=constant_pacing(3)：所以任務每隔3秒執行，但是當到達運行的總時間時，任務運行結束；

現實中有很多任務其實也是有嵌套結構的，比如用戶打開一個網頁首頁後，用戶可能會不喜歡這個網頁直接離開，或者喜歡就留下來，留下來的話，可以選擇看書、聽音樂、或者離開；

在有Taskset嵌套的情況下，執行子任務時, 通過 self.interrupt() 來終止子任務的執行, 來回到父任務類中執行, 否則子任務會一直執行；

在上一頁的案例中，在stay這個類中，對interrupt()方法的調用是非常重要的，這可以讓一個用戶跳出stay這個類有機會執行leave這個任務，否則他一旦進入stay任務就會一直在看書或者聽音樂而難以自拔。

在進行介面多用戶並發測試時，數據的重復使用可能會造成腳本的失敗，那麼需要對用戶數據進行參數化來使腳本運行成功。
已登錄功能為例：

創建 login_user() 方法，定義登錄字典 users , 通過randint 隨機獲取字典中的用戶數據。
在 login() 登錄任務中，調用 login_user() 方法實現 隨機用戶的登錄。

在此我們舉出網路搜索的例子，假設每個人搜索的內容是不相同的；那麼我們可以假設把數據放到隊列中，然後從隊列中依次把數據取出來；
可以利用python中Queue隊列來進行處理；

Queue的種類 ：
Queue.Queue(maxsize=0)：先進先出隊列
Queue.LifoQueue(maxsize=0)：後進先出隊列
Queue.PriorityQueue(maxsize=0)：構造一個優先隊列

參數maxsize是個整數，指明了隊列中能存放的數據個數的上限。一旦達到上限，插入會導致阻塞，直到隊列中的數據被消費掉。如果maxsize小於或者等於0，隊列大小沒有限制

Queue的基本方法 ：

個別情況下測試數據可重復使用，因此我們可以把參數化數據定義為一個列表，在列表中取出數據；

在某些請求中，需要攜帶之前response中提取的參數，常見場景就是session_id。Python中可用通過re正則匹配，對於返回的html頁面，可用採用lxml庫來定位獲取需要的參數；
我們以Phpwind登陸的來進行舉例，在登陸的介面中需要把token參數傳給伺服器，token的值由頁的介面返回；

方法一：使用正則表達式
方法二：採用lxml庫來定位獲取需要的參數

技術點：
1、導模塊：lxml模塊
2、etree.HTML() 從返回html頁面獲取html文件的dom結構
3、xpath() 獲取token的xpath路徑

catch_response = True ：布爾類型，如果設置為 True, 允許該請求被標記為失敗。
通過 client.get() 方法發送請求，將整個請求的給 response， 通過 response.status_code 得請求響應的 HTTP 狀態碼。如果不為 200 則通過 response.failure('Failed!') 列印失敗！

參考文章：
https://www.jianshu.com/p/a48f4af81e67
https://www.cnblogs.com/fnng/p/6081798.html
http://class.itest.info/locust 【蟲師】
https://cloud.tencent.com/developer/article/1594240 【官方文檔的中文翻譯】

⑩ 使用Jmeter進行http介面性能測試

在進行網頁或應用程序後台介面開發時，一般要及時測試開發的介面能否正確接收和返回數據，對於單次測試，Postman插件是個不錯的Http請求模擬工具。

但是Postman只能模擬單客戶端的單次請求，而對於模擬多用戶並發等性能測試，就必須藉助其他的工具了，這里推薦功能強大的JMeter自動化測試工具

Apache JMeter - Apache JMeter™

Apache JMeter是Apache組織開發的基於Java的壓力測試工具。用於對軟體做壓力測試，它最初被設計用於Web應用測試但後來擴展到其他測試領域。 它可以用於測試靜態和動態資源例如靜態文件、Java 小服務程序、CGI 腳本、Java 對象、資料庫， FTP 伺服器， 等等。JMeter 可以用於對伺服器、網路或對象模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體性能。

下面就以上圖的Restful類型的介面為例簡單介紹使用Jmeter進行介面測試的方法。

獲取某個具體網關設備的基本信息。

請求

方法：GET

URI：/api/gateway/<gateway_id>

參數：

在HTTP請求（http request）的頭部（header）添加Userid和Token欄位作為用戶驗證欄位

響應

返回值：JSON格式的網關信息

參數：

.啟動jmeter：在bin下以管理員身份運行jmeter.bat，啟動jmeter

2. 創建測試計劃：

默認啟動jmeter時會載入一個測試技術模板，保存測試計劃：修改名稱為Apitest,點擊保存，選擇保存路徑,後面的步驟，每次添加或修改了了一些選項，軟體並不會自動保存到jmx文件中，所以進行測試後，如果需要保存本次測試選項，要手動到「文件」菜單中保存一下。

3. 添加線程組

右鍵左邊樹中的測試計劃「Apitest」節點，「添 加」→」Threads」→」線程組」

添加成功後，「Apitest」節點下多了「線程組」 節點,當然這個線程組的名稱是可以自己設定的。

4. 添加http默認請求：（用來配置公共參數,不是http請求）

右鍵線程組，選擇「添加」→ 「配置元件」→「HTTP請求默認值」，點擊「HTTP請求默認值」後

添加成功後，線程組」節點下多了「HTTP請求默認值」節點

這里可以設置主機地址等一下公共參數，比如我們的例子中請求路徑前面都是主機地址+index.php,就可以統一在"http請求默認值"里設置

填寫默認請求名、伺服器、默認請求路徑，保存測試計劃。

5.添加http請求信息頭

這一項並不是必須的，只不過我們的例子中使用了Userid和Token放在HTTP請求頭中用作用戶驗證

右鍵「Apitest」，選擇「添加」→ 「配置元件」→「HTTP信息頭管理器」

6. 添加http請求

右鍵「Apitest」，選擇「添加」→ 「Sampler」→「HTTP請求」

添加成功後，出現新的節點「HTTP請求」，就可以填寫具體的請求參數了。

填寫完成，保存測試計劃

7. 添加監聽器：

右鍵線程組，選擇「添加」→「監聽器」→「XXXXXXXXX」

可以添加的監聽器有很多種，可以添加多個監聽器，這里我們添加幾個常用的「圖形結果」、「察看結果樹」、「聚合報告」

添加成功後，「線程組」下增加了幾個節點

8. 試運行

點擊執行

可以查看各個「監聽器」的結果

Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這里顯示的就是 Name 屬性的值

#Samples：表示你這次測試中一共發出了多少個請求，如果模擬10個用戶，每個用戶迭代10次，那麼這里顯示100

Average：平均響應時間——默認情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間

Median：中位數，也就是 50％ 用戶的響應時間

90% Line：90％ 用戶的響應時間

Note：關於 50％ 和 90％ 並發用戶數的含義，請參考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小響應時間

Max：最大響應時間

Error%：本次測試中出現錯誤的請求的數量/請求的總數

Throughput：吞吐量——默認情況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數

KB/Sec：每秒從伺服器端接收到的數據量，相當於LoadRunner中的Throughput/Sec

9. 修改線程組的線程數等參數，用於壓力測試

點擊左側樹形導航中的「線程組」

設置上面幾個參數，模擬的總的請求數是：線程數*循環次數。執行一下，用「圖形結果」監聽器查看一下

樣本數目：總共發送到伺服器的請求數.

最新樣本：代表時間的數字,是伺服器響應最後一個請求的時間.

吞吐量：伺服器每分鍾處理的請求數.

平均值：總運行時間除以發送到伺服器的請求數.

中間值：時間的數字,有一半的伺服器響應時間低於該值而另一半高於該值.

偏離：伺服器響應時間變化、離散程度測量值的大小,或者,換句話說,就是數據的分布.