php curl 中的gzip壓縮效能測試

前因：

請求介面次數很多，每日兩億多次，主要是有些介面返回資料量很大高達110kb（為了減少請求次數，將多個介面合併成乙個導致的）。

後端介面的nginx已經開啟gzip，所以做個測試，看看是否在請求時使用壓縮解壓

php curl 的擴充套件安裝這裡就不說了

用到的curl的兩個引數

//在http 請求頭加入 gzip壓縮

//curl返回的結果，採用gzip解壓
curl_setopt($ch, curlopt_encoding, "gzip");

1、不使用壓縮解壓

$s1 = microtime(true);

$ch = curl_init();
for($i=0; $i<100;$i++)
curl_close($ch);
echo microtime(true)-$s1;
echo "\n";

測試結果    請求100次平均耗時 2.1s   0.021s/次

2、使用壓縮解壓

$s1 = microtime(true);

$ch = curl_init();
for($i=0; $i<100;$i++)
curl_close($ch);
echo microtime(true)-$s1;
echo "\n";

測試結果    請求100次平均耗時 2.6s   0.026/次

結果

1、不使用壓縮比使用壓縮 請求一次快 5ms

2、千兆網，在區域網內傳輸這些資料大概是 0.7ms

結論

暫時不使用 curl 的壓縮和解壓

開啟gzip壓縮

前端gzip壓縮一直都是必備的，簡單又能能壓縮不少的檔案體積，用了好久了今天記錄一下。我們伺服器用的nginx，進入伺服器下nginx.conf檔案，gzip on gzip min length 1k gzip buffers 4 16k gzip comp level 4 壓縮程度，1 9，建議...

檔案壓縮（Gzip）

今天頭鐵用system.io.compression類來寫一下檔案的gzip壓縮，結果 給自己整暈了 主要是壓縮之後我發現是有內容的，又想著寫一下解壓部分，結果要麼溢位，要麼解壓成功後得到乙個啥也沒有的空殼。下面我給大家分享一下壓縮部分吧 我覺得應該也是有問題的，因為他有內容但是明顯不夠，純屬個人看...

開啟Apache的gzip壓縮

我自己寫過的乙個專案中，最後打包出1.37m，可以說是挺大了，我在移動端測試的時候也是，載入速度非常慢。所以，在我開啟apache的gzip壓縮之後 必須的，就像乙個開關一樣，告訴apache對傳輸到瀏覽器的內容進行壓縮 setoutputfilter deflate deflatecompress...