[Performance] 🟢 MTTFB AVG Diff. 30.5% Improved by - RDB b-tree indexing with Long `POST /api-chat/chat`

[ghkdqhrbals]

성능개선 이전에 기존 서비스의 성능측정

10분간 채팅전송 API 의 퍼포먼스를 ramp-up VUSER 300 으로 측정하였습니다. 아래의 테이블은 Thread warm up 이전과 이후 차이를 관찰합니다. 그리고 그래프는 웜업 이후의 그래프입니다.

이후 성능개선 비교는 warm-up 이후를 기준으로 비교합니다.

Metric	Before Thread Warm-up	After Thread Warm-up	Change
TPS 평균 (Average)	341.90	390.94	14.34% 🟢
TPS p95	446.50	464.73	4.08% 🟢
TPS p99	500.07	491.26	-1.76% 🔴
MTTFB 평균	649.70 ms	496.27 ms	23.62% 🟢
MTTFB p95	1602.63 ms	882.81 ms	44.91% 🟢
MTTFB p99	2231.59 ms	1163.81 ms	47.85% 🟢
MTTFB 차이 평균	184.45 ms	106.51 ms	42.26% 🟢
MTTFB 평균적인 변동률	22.49%	20.77%	7.65% 🟢

• 사용 DB Active Connection(PgAdmin)

• 커스텀 지표(Grafana/Prometheus/micrometer)

[ghkdqhrbals]

Chatting 테이블 PK 를 String 에서 Long 타입으로 변경 후 seq 에 따라 자동으로 삽입되도록 설정

Metric	Before	After	Change
TPS 평균	390.94	416.85	6.63% 🟢
TPS p95	464.73	472.70	1.71% 🟢
TPS p99	491.26	520.06	5.86% 🟢
MTTFB 평균	496.27 ms	456.42 ms	8.03% 🟢
MTTFB p95	882.81 ms	799.67 ms	9.42% 🟢
MTTFB p99	1163.81 ms	1130.67 ms	2.85% 🟢
MTTFB 차이 평균	106.51 ms	74.02 ms	30.5% 🟢
MTTFB 평균적인 변동률	20.77%	15.27%	26.48% 🟢

• Chat 의 id 타입 변경 시 성능차이가 나는 이유는 뭘까?

  현재 Chat 의 id 는 String 로 설정되어있는데 Long 타입으로 변경한 뒤 MTTFB 평균 변동치가 30% 안정화 되었습니다. 이유가 뭘까요? 바로 Long 타입으로 변경하고 Postgresql 의 SERIAL 을 통해 자동증가 옵션을 사용한다면 b트리 리밸런싱이 거의 또는 전혀 필요하지 않기 때문이죠! INSERT 쿼리 성능이 증가한 것입니다.

  • b-tree 차수는 몇?

  Postgresql 은 기본인덱싱 전략이 b트리로 되어있어요. 그리고 이 b트리의 차수는 Postgresql 가 자동으로 결정한답니다. 수동으로 만지는 건 막혀있어요. 일반적으로 노드의 크기가 8KB 로 설정되어 있고 이에 맞추어 각 노드의 차수가 설정된다고 보면 될 것 같아요.

  • Long 타입 ID의 이점
    1. 크기와 효율성: Long 타입은 64비트(8바이트)의 크기를 가지며, 이는 UUID(128비트, 16바이트)보다 작습니다. 작은 크기는 인덱스의 메모리 사용량을 줄이고, 디스크 I/O를 최소화합니다. 그러니까 "key의 크기가 작을수록 노드의 차수가 증가하고 block 단위 디스크 i/o 가 발생하는 빈도수가 낮아진다"는 것이죠.
    2. 순차적 증가: Long 타입 ID는 주로 DB 에서 시퀀스를 받아와 순차적으로 증가시킵니다. 이는 B-트리의 균형을 유지하며, 새로운 데이터가 트리의 맨 끝에 추가되므로 재조정(rebalancing)이 거의 필요하지 않습니다. 삽입 성능이 뛰어나겠죠? 만약 UUID 로 하면 진짜 여기저기 추가되기 때문에 리밸런싱이 계속해서 일어나야합니다. 쉽게 말하면 Long 은 여러 노드들의 빈 자리를 차근차근 채워나가지만 String 은 노드들의 빈자리를 무작위로 채워나가는 것이기때문에 리밸런싱 빈도수가 높습니다.

  3. 범위 검색 최적화: 숫자 기반의 ID는 범위 검색에 적합합니다. 예를 들어, 특정 ID 범위의 데이터를 효율적으로 검색할 수 있습니다. 채팅의 경우에는 아무래도 채팅id 가 그룹처럼 붙어있습니다. 즉, 어떠한 범위가 있기 때문에 Long 타입 id 가 유리합니다.

  • String 을 b-tree key 로 설정한다면 유리한 점도 있습니다.

  String 값이 특별한 의미가 있을 때 : 예로 제품 이름, 주소, 설명 등을 색인화하고 검색할 때 String 키는 효과적입니다. 하지만 Chat id 의 경우 특별한 의미가 없기때문에 Long 타입이 더 성능면에서 이점을 가져다 줄거에요.