offset-based-pagination VS Cursor-based-pagination
Paging
한정된 네트워크 자원을 효율적으로 활용하기 위해 특정한 정렬 기준에 따라 데이터를 분할하여 가져오는 것이다.
서버의 입장에서도 클라이언트의 입장에서도 특정한 정렬 기준에 따라 + 지정된 갯수 의 데이터를 가져오는 것이다.
- 페이지 네이션은 보통 두 가지 방식으로 처리할 수 있다.
- 오프셋 기반 페이지네이션 (Offset-based Pagination)
- 커서 기반 페이지네이션 (Cursor-based Pagination)
둘 다 동일한 조건과 동일한 환경에서 성능테스트를 진행했다.
- Thread Properties 설정
- Number of Threads (users) : 가상사용자 (Thread)의 수 -> 1000
- Ramp-up period (seconds) : 요청 주기(초) -> 10
- Loop Count : 테스트를 반복하는 횟수(Option. Infinite - 무한대로 호출)-> 1
- 요청 발생 방식
- 총 1000명의 가상 사용자 (Thread)가 테스트에 참여
- Ramp-up 시간 10초 안에 이 1000명이 순차적으로 투입
- 각 사용자(쓰레드)는 1회 요청만 수행
- 요청 타이밍 계산
- Ramp-up 기간 동안 1000명의 사용자 분산 투입
- 즉, 10초 동안 1초에 100명씩 추가 →
1000 / 10 = 100 threads/sec
< 오프셋 기반 페이지네이션 >
-> 내림차순(최신순) 페이징을 적용하고 있기 때문에, 첫 요청 시 page는 마지막 페이지 번호로 설정됩니다. (총 4433개 데이터)
첫 번째 실행
두 번째 실행
세 번째 실행
네 번째 실행
다섯 번째 실행
종합 평균 성능 결과
| 항목 | 평균값 |
|---|---|
| # Samples | 3,000 |
| Average (ms) | 103.4 ms |
| Min (ms) | 12.0 ms |
| Max (ms) | 431.2 ms |
| Standard Deviation | 61.88 ms |
| Throughput | 12.28 /sec |
| Received KB/sec | 14.84 KB/sec |
| Sent KB/sec | 2.35 KB/sec |
| Avg. Bytes | 1179.0 bytes |
| Error % | 0.00% |
건당 주요 값 요약
| 처리량 (Throughput) | 샘플 수 | Avg(ms) | Max | Min | Std.Dev | TPS |
|---|---|---|---|---|---|---|
| 1000건 | 1000 | 96 | 343 | 16 | 59.05 | 99.7/sec |
| 2000건 | 2000 | 113 | 453 | 16 | 65.03 | 12.9/sec |
| 3000건 | 3000 | 105 | 453 | 12 | 62.46 | 11.1/sec |
| 4000건 | 4000 | 100 | 453 | 8 | 60.95 | 12.8/sec |
| 5000건 | 5000 | 103 | 453 | 8 | 60.90 | 14.8/sec |
분석
- 처리량 (Throughput) : 1,000건에서 99.7/sec로 매우 높다가 이후 테스트에서는 11~14/sec 범위로 유지됨 → 초기 과부하 가능성 또는 워밍업 효과일 수 있음.
- 응답 시간 : 평균 100~113ms로 일정하게 유지되며, 큰 편차 없음.
- 표준편차 역시 59~65ms로 비교적 안정적.
- 에러율은 전 테스트에서 0%로, 모든 요청이 정상 처리됨.
- Avg. Bytes는 모든 테스트에서 동일하여 일관된 응답 구조를 보여줌.
< 커서 기반 페이지네이션 >
-> 내림차순으로 (최신 먼저) 페이징 처리를 하기 때문에 nextCusorId는 마지막 페이지 나오는 id로 설정
첫 번째 실행
두 번째 실행
세 번째 실행
네 번째 실행
다섯 번째 실행
종합 평균 성능 결과
| 항목 | 평균값 |
|---|---|
| # Samples | 3,000 |
| Average (ms) | 28.8 ms |
| Min (ms) | 2.0 ms |
| Max (ms) | 209.4 ms |
| Standard Deviation | 29.52 ms |
| Throughput | 15.7 /sec |
| Received KB/sec | 11.79 KB/sec |
| Sent KB/sec | 3.10 KB/sec |
| Avg. Bytes | 746.0 bytes |
| Error % | 0.00% |
건당 주요 값 요약
| 처리량 (Throughput) | 샘플 수 | Avg(ms) | Max | Min | Std.Dev | TPS |
|---|---|---|---|---|---|---|
| 1000건 | 7 | 149 | 243 | 2 | 20.25 | 101.6/sec |
| 2000건 | 31 | 169 | 243 | 2 | 34.22 | 14.1/sec |
| 3000건 | 37 | 243 | 243 | 2 | 35.31 | 16.6/sec |
| 4000건 | 35 | 243 | 243 | 2 | 31.91 | 14.7/sec |
| 5000건 | 34 | 243 | 243 | 2 | 29.92 | 13.5/sec |
분석
- 응답 시간(Avg) : 평균 28.8ms로 매우 빠름. (오프셋 방식 평균 103.4ms보다 약 3.6배 빠름)
- 처리량 (Throughput) : 평균 약 15.7/sec로 오프셋 평균 12.28/sec보다 더 높음.
- 표준편차: 약 29.5ms로, 오프셋보다 안정적(Offset: ~61.9ms).
- 에러율: 모든 테스트에서 0% 유지, 안정성 확보.
- 트래픽량: Avg. Bytes는 746.0 bytes로 오프셋의 1179.0 bytes보다 적음 → 더 적은 데이터로 동일한 결과 제공.
결론
| 기준 | Offset Paging | Cursor Paging | 비교 |
|---|---|---|---|
| Avg. 응답시간 | 103.4 ms | 28.8 ms | ▼ 72% 개선 |
| Throughput | 12.28/sec | 15.7/sec | ▲ 28% 증가 |
| Std. Dev | 61.88 ms | 29.52 ms | ▼ 절반 이하로 안정 |
| Avg. Bytes | 1179.0 | 746.0 | ▼ 데이터 효율적 |
cursor과 offset 성능 비교
| 항목 | Offset Pagination | Cursor Pagination | 💡비교 분석 |
|---|---|---|---|
| 평균 응답시간 (Avg, ms) | 103.4 ms | 28.8 ms | 커서 방식이 3.6배 빠름 |
| 최소 응답시간 (Min, ms) | 12 ms | 2 ms | 커서 방식이 더 낮음 |
| 최대 응답시간 (Max, ms) | 431.2 ms | 209.4 ms | 커서 방식이 더 안정적 |
| 표준편차 (Std. Dev) | 61.88 ms | 29.52 ms | 커서 방식이 덜 흔들림 |
| 처리량 (Throughput) | 12.28/sec | 15.7/sec | 커서 방식이 더 빠른 처리 |
| 수신 트래픽 (Received KB/sec) | 14.84 KB/s | 11.79 KB/s | 오프셋은 데이터 양이 더 많음 |
| 송신 트래픽 (Sent KB/sec) | 2.35 KB/s | 3.10 KB/s | 커서는 약간 더 많이 보냄 |
| 응답 크기 (Avg. Bytes) | 1179.0 bytes | 746.0 bytes | 커서가 더 작고 효율적 |
| 에러율 (Error %) | 0.00% | 0.00% | 동일하게 안정적 |
최종 결론
Cursor 기반 페이지네이션은 성능(응답속도, 처리량)과 안정성(표준편차) 면에서 모두 우수합니다.
특히 페이지네이션이 클라이언트/사용자 요청이 잦은 서비스(예: API, 무한 스크롤)에서는 확연한 이점이 있습니다.
Offset 방식은 단순하지만, 데이터 양이 많아질수록 성능이 급격히 저하될 수 있습니다.
상황에 따른 추천 방식 : 성능과 확장성이 중요한 경우 Cursor 기반 권장
KIM