Google Cloud Storage TTFB随gzip增加

当我将资产上传到云存储时，使用gsutil cp -z js,css,html, ，那么它们的TTFB（Time To First Byte）服务时间从〜20ms增加到180ms。Google Cloud Storage TTFB随gzip增加

这是很大的性能影响。为什么会发生这种情况以及如何解决此问题？

这里更多的样本（网址仍然有效，如果你想尝试自己）：

$ ab -c 5 -n 50 https://storage.googleapis.com/latencytest/test-raw.txt 

Concurrency Level:  5 
Time taken for tests: 2.048 seconds 
Complete requests:  50 
Failed requests:  0 
Total transferred:  45710 bytes 
HTML transferred:  8050 bytes 
Requests per second: 24.41 [#/sec] (mean) 
Time per request:  204.846 [ms] (mean) 
Time per request:  40.969 [ms] (mean, across all concurrent requests) 
Transfer rate:   21.79 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  88 117 16.7 112  160 
Processing: 21 73 112.8  36  487 
Waiting:  21 71 113.3  34  487 
Total:  122 189 118.4 146  613 


$ ab -c 5 -n 50 https://storage.googleapis.com/latencytest/test.txt 

Concurrency Level:  5 
Time taken for tests: 3.374 seconds 
Complete requests:  50 
Failed requests:  0 
Total transferred:  45150 bytes 
HTML transferred:  7250 bytes 
Requests per second: 14.82 [#/sec] (mean) 
Time per request:  337.403 [ms] (mean) 
Time per request:  67.481 [ms] (mean, across all concurrent requests) 
Transfer rate:   13.07 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  90 109 9.0 107  136 
Processing: 174 206 44.6 190  389 
Waiting:  172 204 44.3 189  384 
Total:  274 315 47.3 299  495

对gzip压缩的文件卷曲输出：

$ curl -s -v https://storage.googleapis.com/latencytest/test.txt > /dev/null 
* Trying 2a00:1450:400e:805::2010... 
* Connected to storage.googleapis.com (2a00:1450:400e:805::2010) port 443 (#0) 
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
* Server certificate: *.storage.googleapis.com 
* Server certificate: Google Internet Authority G2 
* Server certificate: GeoTrust Global CA 
> GET /latencytest/test.txt HTTP/1.1 
> Host: storage.googleapis.com 
> User-Agent: curl/7.43.0 
> Accept: */* 
> 
< HTTP/1.1 200 OK 
< X-GUploader-UploadID: AEnB2UpBZ1SoG2fiD3_qSOmIWWvL86Kd-r21kXOS08UlvMOc90Eco-vd3ol3NnwDrkJKwKk7zav0ePdp9QYXm7lt4NdV39h-VQ 
< Date: Tue, 17 Jan 2017 20:44:19 GMT 
< Cache-Control: no-transform 
< Expires: Wed, 17 Jan 2018 20:44:19 GMT 
< Last-Modified: Mon, 16 Jan 2017 13:46:54 GMT 
< ETag: "88b49948e59eaad05d60a52001b50d7a" 
< x-goog-generation: 1484574414392000 
< x-goog-metageneration: 2 
< x-goog-stored-content-encoding: gzip 
< x-goog-stored-content-length: 145 
< Content-Type: text/plain 
< Content-Encoding: gzip 
< Content-Language: en 
< x-goog-hash: crc32c=MlL4Uw== 
< x-goog-hash: md5=iLSZSOWeqtBdYKUgAbUNeg== 
< x-goog-storage-class: STANDARD 
< Accept-Ranges: bytes 
< Server: UploadServer 
< Alt-Svc: quic=":443"; ma=2592000; v="35,34" 
< Transfer-Encoding: chunked 
< 
{ [261 bytes data] 
* Connection #0 to host storage.googleapis.com left intact

来源

2017-01-16 dkoch

它不是从你的文章中明确，但我认为下载请求不包括“Accept-Encoding：gzip”请求标头。这会导致gzip编码在运行中被删除（这将会增加延迟）。参看https://cloud.google.com/storage/docs/transcoding#decompressive_transcoding – lot

我不这么认为，看看我最近编辑的头文件卷曲 – dkoch

我看到，你设置了缓存控制：no-transform（这将防止gunzipping）。从本地尝试这些URL，它看起来像非gzip的版本被分块（传输编码）。我将不得不多看一看堆栈的哪一部分。与此同时，你是否用http而不是https来测试你的a/b测试？使用http的 – lot

由于lot想通了，Cache-Control: no-transform, public解决了这个问题。

来源

2017-01-18 18:27:29 dkoch

Google Cloud Storage TTFB随gzip增加

回答

相关问题