php吞吐率,php速度

本文目錄一覽：

• 1、maxtolud設置多大好
• 2、php 高並發解決思路解決方案
• 3、php寫的程序，進行性能測試，各項資源都正常，增加並發，tps不增長，響應時間增長，您覺得瓶頸在哪？
• 4、php 從rabbitmq consume 和 get的區別
• 5、thinkphp5 怎麼記錄詳細日誌
• 6、獨享128M內存的彈性web託管怎麼樣呢？做phpwind

maxtolud設置多大好

根據reqs來設置。

maxtolud較好的設置方式根據reqs吞吐率，單位時間裡服務器處理的最大請求數，單位reqs來設置，若程序是100reqs的處理能力，那麼就設置100比較好，這是動態來調整的。

一般來說性能越好你可以設置越高，20分鐘至30分鐘都可以。由於服務器PHP腳本需要長時間運行，有的可能會超過10分鐘因此設置了900秒，這樣不會導致PHPCGI死掉而出現502Badgateway這個錯誤。

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 實現負載均衡

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

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

php 從rabbitmq consume 和 get的區別

以下是阿里雲查到的解釋

在RabbitMQ中消費者有2種方式獲取隊列中的消息:

a)  一種是通過basic.consume命令，訂閱某一個隊列中的消息,channel會自動在處理完上一條消息之後，接收下一條消息。（同一個channel消息處理是串行的）。除非關閉channel或者取消訂閱，否則客戶端將會一直接收隊列的消息。

b)  另外一種方式是通過basic.get命令主動獲取隊列中的消息，但是絕對不可以通過循環調用basic.get來代替basic.consume，這是因為basic.get RabbitMQ在實際執行的時候，是首先consume某一個隊列，然後檢索第一條消息，然後再取消訂閱。如果是高吞吐率的消費者，最好還是建議使用basic.consume。

簡單總結一下就是說：

consume是只要隊列裡面還有消息就一直取。

get是只取了隊列裡面的第一條消息。

因為get開銷大，如果需要從一個隊列取消息的話，首選consume方式，慎用循環get方式。

thinkphp5 怎麼記錄詳細日誌

onethink里有這個功能，記錄操作日誌的，可以參考一下

需要先把所有需要記錄的行為添加一下，這個工作量巨大，如果每個行為都要記錄的話··· 所以一般都是把重要的記錄就可以了。

onethink 是 thinkphp開發的 可能跟你的存在版本差異

代碼可以參考以下：

[ 2017-02-21T20:31:33+08:00 ] 192.168.2.106 192.168.2.107 POST /Stardaily/public/index.php/app/User/autoLogin

[ log ] 192.168.2.106:80/Stardaily/public/index.php/app/User/autoLogin [運行時間：0.334305s][吞吐率：2.99req/s] [內存消耗：2,620.18kb] [文件加載：85]

[ info ] [ LANG ] F:\PHP\phpStudy\WWW\Stardaily\thinkphp\lang\zh-cn.php

[ info ] [ ROUTE ] array (

‘type’ = ‘module’,

‘module’ =

array (

0 = ‘app’,

1 = ‘User’,

2 = ‘autoLogin’,

),

)

[ info ] [ HEADER ] array (

‘accept-encoding’ = ‘gzip, deflate’,

‘content-length’ = ’52’,

‘accept-language’ = ‘zh-Hans-CN;q=1, zh-Hant-CN;q=0.9’,

‘user-agent’ = ‘StarDaily/1.1.1 (iPod touch; iOS 10.2; Scale/2.00)’,

‘accept’ = ‘*/*’,

‘connection’ = ‘keep-alive’,

‘content-type’ = ‘application/x-www-form-urlencoded’,

‘host’ = ‘192.168.2.106:80’,

)

[ info ] [ PARAM ] array (

‘account_id’ = ’52’,

‘token’ = ‘68699dad96c7e1741dba59d8b4ce127f’,

)

[ info ] [ RUN ] app\app\controller\User-autoLogin[ F:\PHP\phpStudy\WWW\Stardaily\application\app\controller\User.php ]

[ info ] [ DB ] INIT Pgsql

[ info ] [ LOG ] INIT File

獨享128M內存的彈性web託管怎麼樣呢？做phpwind

128m有點小，主要看網站的並發量。

一般每個php-fpm進程要佔到25m左右，你這點內存極限也就能開5個fpm，5個fpm並發處理動態頁面，假設平均腳本執行時間在0.1s，服務器的吞吐率是50。這裡50是比較樂觀的情況，並且沒考慮帶寬因素。