- https://www.websiteplanet.com/glossary/web-hosting/what-is-gzip
API 응답 최적화 방법 중 하나로 GZIP 압축을 이용하는 방법이 있다고 한다. 뭔가 데이터를 압축해서 보내면 네트워크 전송량이 줄어들어서 응답속도가 빨라질 것 같긴 한데, 실제로 효과가 있을까 궁금해서 실행해봤다.
일단 먼저 gzip 이란? zip 이 들어가서 알겠지만 리눅스 프로젝트인 GNU + zip 약자로 파일 압축 알고리즘이다. zip 은 뭐 여러개의 파일을 묶어서 압축할 수 있고 gzip 은 하나의 바이트 스트림을 압축하는 방식임(그래서 보통 우리 맥에서 tar + gzip 으로 묶어서 많이 사용함). 어쨌든 단일 바이트 스트림 압축 알고리즘으로 여러 파일압축 신경 안써도 돼서 오버헤드가 zip 보다 좀 더 작고 효율적이라고 한다.
spring-boot 에서 톰켓 에서 gzip 설정을 자동으로 지원하기떄문에 application.yml 에 다음과 같이 설정해주면 된다.
server:
compression:
enabled: true
mime-types: application/json,application/xml,text/html,text/xml,text/plain
min-response-size: 1024
그리고 나서 대용량 json 응답을 주는 API 를 하나 만들었다. 약 45MB 정도 되는 json 응답이다.
45.83MB(400ms) -> 2.53MB(700ms) 로 응답 크기가 효율적으로 줄었지만 응답속도가 더 느려졌다.
이유를 보니까 gzipping + unzipping 하는데 CPU 오버헤드가 크게 발생한다. 여기에 걸리는 시간이 300ms 가 더 증가함. 그래서 무조건 gzip 이 좋은건 아니고, 네트워크 대역폭이 낮을 때 유리해진다. 내부망에서는 네트워크 지연이 매우 낮기 때문에 gzip 이 CPU 오버헤드가 더 커져버려서 오히려 성능 저하를 일으킬 수 있다.
RTT 낮은 환경에서는 gzip 을 사용하지 않는게 좋음! 해당 실험을 한 곳은 로컬이라 거의 RTT 가 0 에 수렴하는 환경이었기 때문에 gzip 이 오히려 성능 저하를 일으킨 케이스였다.
- https://www.websiteplanet.com/glossary/web-hosting/what-is-gzip
I heard that one way to optimize API responses is to use GZIP compression. It feels like if data is compressed before being sent, network transfer size will decrease and response speed should improve. But I was curious whether it actually works, so I tried it.
First, what is gzip? As the word zip suggests, it is short for GNU + zip, a file compression algorithm from the Linux project. zip can bundle and compress multiple files, while gzip compresses a single byte stream. That is why it is commonly used together with tar + gzip on Mac. In any case, because it is a single byte-stream compression algorithm and does not need to care about compressing multiple files, it is said to have lower overhead and better efficiency than zip.
Spring Boot automatically supports gzip configuration through Tomcat, so you can configure application.yml like below.
server:
compression:
enabled: true
mime-types: application/json,application/xml,text/html,text/xml,text/plain
min-response-size: 1024
Then I created an API that returns a large JSON response. It is about a 45MB JSON response.
The response size dropped efficiently from 45.83MB to 2.53MB, but the response time became slower, from 400ms to 700ms.
Looking at the reason, gzipping and unzipping cause significant CPU overhead. This added about 300ms. So gzip is not always good. It becomes useful when network bandwidth is low. In an internal network, network latency is very low, so the CPU overhead of gzip can become larger and actually degrade performance.
In a low-RTT environment, it is better not to use gzip. This experiment was done locally, where RTT was almost close to 0, so gzip was a case where it actually made performance worse.