Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[docdb] Support gzipped responses in webserver #9090

Closed
iSignal opened this issue Jun 24, 2021 · 1 comment
Closed

[docdb] Support gzipped responses in webserver #9090

iSignal opened this issue Jun 24, 2021 · 1 comment
Assignees
Labels
area/docdb YugabyteDB core features

Comments

@iSignal
Copy link
Contributor

iSignal commented Jun 24, 2021

Metrics can be pretty large in certain scenarios and we sometimes scrape them every 10s. Returning gzipped responses when the http client specifies Accept-Encoding: gzip would help make the prometheus scrape consume less network b/w.

apache/kudu@8f52582 might be useful.

@iSignal iSignal added the area/docdb YugabyteDB core features label Jun 24, 2021
@tedyu tedyu self-assigned this Jun 25, 2021
@tedyu
Copy link
Contributor

tedyu commented Jun 25, 2021

Here is unfinished patch:
yb-websvr-comp-2.txt

tedyu added a commit that referenced this issue Jul 7, 2021
Summary:
Metrics can be pretty large in certain scenarios and we sometimes scrape them every 10s.
Returning gzipped responses when the http client specifies Accept-Encoding: gzip would help make the prometheus scrape consume less network bandwidth.

Ported from apache/kudu@8f52582

From zlib manual:

  Lower compression levels result in faster execution, but less compression

Here level 1 is used. We can start with this level.
If prometheous metrics are very large, we can choose higher level.

A flag, webserver_zlib_compression_level, has been introduced with default level of 1.
Another flag, webserver_compression_threshold_kb (default 4KB), allows specifying the threshold above which compression is performed.

Test Plan: WebserverTest.TestHttpCompression

Reviewers: mbautin, amitanand, sanketh

Reviewed By: sanketh

Subscribers: sanketh, mbautin, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D12072
@tedyu tedyu closed this as completed Jul 7, 2021
tedyu added a commit that referenced this issue Jul 14, 2021
Summary:
Metrics can be pretty large in certain scenarios and we sometimes scrape them every 10s.
Returning gzipped responses when the http client specifies Accept-Encoding: gzip would help make the prometheus scrape consume less network bandwidth.

Ported from apache/kudu@8f52582

From zlib manual:
```
Lower compression levels result in faster execution, but less compression
```
Here level 1 is used. We can start with this level.
If prometheous metrics are very large, we can choose higher level.

A flag, webserver_zlib_compression_level, has been introduced with default level of 1.
Another flag, webserver_compression_threshold_kb (default 4KB), allows specifying the threshold above which compression is performed.

Test Plan:
Jenkins: rebase: 2.6

WebserverTest.TestHttpCompression

On universe with this feature, 114864 bytes of /metrics output was compressed to
```
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Content-Length: 7008
< Content-Encoding: gzip
```

Reviewers: sanketh

Reviewed By: sanketh

Subscribers: ybase, bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D12239
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features
Projects
None yet
Development

No branches or pull requests

3 participants