Commit fbb588d9 authored by gejun's avatar gejun

describe -http_body_compress_threshold in docs

parent ee9c2736
...@@ -148,7 +148,11 @@ Notes on http header: ...@@ -148,7 +148,11 @@ Notes on http header:
# 压缩request body # 压缩request body
调用Controller::set_request_compress_type(brpc::COMPRESS_TYPE_GZIP)可将http body用gzip压缩,并设置"Content-Encoding"为"gzip"。 调用Controller::set_request_compress_type(baidu::rpc::COMPRESS_TYPE_GZIP)将尝试用gzip压缩http body。
“尝试“指的是压缩有可能不发生,条件有:
- body尺寸小于-http_body_compress_threshold指定的字节数,默认是512。这是因为gzip并不是一个很快的压缩算法,当body较小时,压缩增加的延时可能比网络传输省下的还多。
# 解压response body # 解压response body
......
...@@ -270,7 +270,10 @@ cntl->http_request().uri().SetQuery("time", "2015/1/2"); ...@@ -270,7 +270,10 @@ cntl->http_request().uri().SetQuery("time", "2015/1/2");
http服务常对http body进行压缩,对于文本网页可以有效减少传输时间,加快页面的展现速度。 http服务常对http body进行压缩,对于文本网页可以有效减少传输时间,加快页面的展现速度。
在r33093后,调用Controller::set_response_compress_type(brpc::COMPRESS_TYPE_GZIP)将尝试用gzip压缩http body,并设置"Content-Encoding"为"gzip"。“尝试”指的是如果请求中没有设置Accept-encoding或不包含gzip,压缩不会进行。比如curl不加--compressed时是不支持压缩的,这时server端总是会返回不压缩的结果。 设置Controller::set_response_compress_type(baidu::rpc::COMPRESS_TYPE_GZIP)后将尝试用gzip压缩http body。“尝试“指的是压缩有可能不发生,条件有:
- 请求中没有设置Accept-encoding或不包含gzip。比如curl不加--compressed时是不支持压缩的,这时server总是会返回不压缩的结果。
- body尺寸小于-http_body_compress_threshold指定的字节数,默认是512。这是因为gzip并不是一个很快的压缩算法,当body较小时,压缩增加的延时可能比网络传输省下的还多。
# 解压request body # 解压request body
......
...@@ -601,9 +601,11 @@ set_log_id() sets a 64-bit integral log_id, which is sent to the server-side alo ...@@ -601,9 +601,11 @@ set_log_id() sets a 64-bit integral log_id, which is sent to the server-side alo
## Attachment ## Attachment
baidu_std and hulu_pbrpc supports attachment, which is set by user to bypass serialization of protobuf. As a client, the data in Controller::request_attachment() will be received by the server and response_attachment() contains attachment sent back by the server. Attachment is not compressed by brpc. baidu_std and hulu_pbrpc supports attachments which are sent along with messages and set by users to bypass serialization of protobuf. As a client, data set in Controller::request_attachment() will be received by server and response_attachment() contains attachment sent back by the server.
In http, attachment corresponds to [message body](http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html), namely the data to post is stored in request_attachment(). Attachment is not compressed by framework.
In http, attachment corresponds to [message body](http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html), namely the data to post to server is stored in request_attachment().
## Authentication ## Authentication
TODO: Describe how authentication methods are extended. TODO: Describe how authentication methods are extended.
......
...@@ -165,7 +165,9 @@ When server returns a non-2xx HTTP status code, the HTTP request is considered t ...@@ -165,7 +165,9 @@ When server returns a non-2xx HTTP status code, the HTTP request is considered t
# Compress Request Body # Compress Request Body
Call `Controller::set_request_compress_type(brpc::COMPRESS_TYPE_GZIP)` and then the framework will use gzip to compress HTTP body and set `Content-Encoding` to gzip. Calling `Controller::set_request_compress_type(brpc::COMPRESS_TYPE_GZIP)` makes framework try to gzip the HTTP body. "try to" means the compression may not happen, because:
* Size of body is smaller than bytes specified by -http_body_compress_threshold, which is 512 by default. The reason is that gzip is not a very fast compression algorithm, when body is small, the delay caused by compression may even larger than the latency saved by faster transportation.
# Decompress Response Body # Decompress Response Body
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment