레일건 서비스가 diff를 이용한 압축을 하기 때문에 더 느릴거라는
기진곰님 말씀에 간단한 테스트를 해봤습니다.
별건 아니고 리눅스 쉘에서 diff와 gzip을 이용한 속도 테스트인데요...
적당한 39206짜리 텍스트 파일 하나를 골라서
쉘 스크립트로 각각 1000회씩 돌렸습니다.
time sh -c 'for i in `seq 1000`; do diff test.txt test2.txt > result.txt; done'
파이프로 보내는 이유는 diff 출력이 콘솔로 나오다보니까 그거 프린트 시간이 너무 오래 걸려서요.
그리고 gzip은 특성상 기존 파일을 지우고 새로운 압축결과를 파일로 써야 하기 때문에
그걸로 잡아먹는 IO 시간이 있는데 diff는 결과를 콘솔로 출력해서 그런게 없으니까
콘솔 출력을 null로 보내거나 >>로 이어쓰기를 하면 너무 빨라져서
둘의 결과를 비슷하게 맞추기 위해서 한겁니다.
>로 하면 매번 기존 result.txt를 지우고 새로 파일을 생성하기 때문에
gzip 테스트와 동작이 같아져서 부하는 거의 비슷하게 됩니다.
써지는 파일 크기도 비슷합니다.
diff의 결과로 나오는 텍스트 파일 크기는 8588바이트
gzip 압축결과로 나오는 압축파일 크기는 11662바이트입니다.
time sh -c 'for i in `seq 1000`; do gzip -k -f test.txt; done'
그럼 대망의 테스트 결과는~~
gzip은 2.948초
diff는 3.348초
예 대략 10% 정도의 차이가 나면서 gzip이 조금 더 빠릅니다.
다만 여기서 생각해볼 것은 gzip은 파일 하나를 읽고 하나를 쓰지만
diff는 파일 2개를 읽고 하나를 쓴다는겁니다. 거기서 나는 IO 차이도
약간은 있을거구요... IO가 잡아먹는 시간은 상당합니다. diff에서
파이프라인 출력을 null로 돌려버리면 2배 빨라지거든요 전체 실행 시간의
50%가 write에 걸리는 시간.. read에 걸리는 시간도 비율은 상당할겁니다.
근데 실제 환경인 레일건은 diff처럼 비교를 위해 파일 2개를 읽지 않으니까요.
그리고 뭣보다도.. 리눅스 diff는 파이썬으로 만들었더군요...
물론 바이너리로 만들어져 있기는 하지만.. 최적화와는 거리가 멀테니
완전히 C로 만들 경우에는 상당한 성능 향상이 있지 않을까 합니다.
(레일건 서비스를 C로 만들었거라는 가정입니다만... 아마도..??
diff 알고리즘 속도 최적화가 레일건 목숨줄일텐데 그렇게 안이하게 만들진
않았겠죠.. 아마도.. )
다만 웹서버가 여러대일경우 gzip에 의한 CPU 부하는 분산될텐데
레일건은 집중되니.. 단순한 CPU 부하의 총합으로 계산하긴 어렵겠네요.
다만 서버가 딱 한대뿐이라면 gzip 압축을 끄고 그냥 레일건으로
대체해도 CPU 사용 측면에선 거의 차이는 없다고 생각합니다.
레일건은 트래픽을 최대한 줄이기 위해 diff 결과를 또 압축하지요 ㅎㅎ
이 때 gzip을 사용하는지 다른 알고리즘을 사용하는지는 모르겠지만, 아무튼 합계 2~3배의 CPU가 소요됩니다.
레일건이 웹서버와 통신할 때는 gzip을 지원하지 않는 클라이언트인 척 하므로, 따로 gzip을 끌 필요는 없습니다.
Accept-Encoding: gzip 헤더가 없으면 웹서버나 XE에서도 굳이 gzip을 돌리지 않으니까요.
단, 압축을 안 하니까 레일건 서버와 웹서버를 따로 둘 경우 그 사이의 트래픽이 폭발적으로 증가합니다.
실제로 레일건이 내부망 대역폭을 400Mbps 이상 쓰는 것을 본 적도 있어요.
localhost라면 상관없지만, 이쯤 되면 기가비트 랜선이라도 레이턴시가 증가하기 시작합니다.
이 문제 때문에 gzip을 지원하는 리버스 프록시를 중간에 끼워서 통신하도록 세팅하기도 했습니다.
네트워크가 포화상태가 되는 것을 막기 위해 CPU를 희생해서 불필요한 압축을 한 거죠...
P.S. gzip -c 옵션을 사용하면 원본 파일을 삭제하지도 않고, 압축 파일을 생성하지도 않고
그대로 stdout으로 출력하므로, 벤치마킹시 이걸 /dev/null로 보내면 불필요한 I/O를 줄일 수 있어요.