TPS(Transcation Per Seconds)와 포화 지점(Saturation Point)

TPS(Transcation Per Seconds)란 초당 처리 트랜잭션을 의미한다.

 

Saturation Point(포화 지점)와 TPS의 관계

서비스의 처리 시간(Service Time)이 일정한 환경에서는 동시 사용자가 증가할수록 TPS(Transactions Per Second)는 일정 구간까지 거의 선형적으로 증가​한다. 이는 서버에 아직 충분한 처리 여유가 있어 추가 요청을 효율적으로 처리할 수 있기 때문이다.

그러나 사용자가 계속 증가하면 CPU, 메모리, DB 커넥션, 네트워크 등의 자원이 한계에 도달하게 되고, 어느 시점부터는 TPS가 더 이상 증가하지 않는 구간이 발생한다. 이 지점을 Saturation Point(포화 지점) 라고 하며, 이때의 동시 사용자 수를 ​최대 허용 동시 사용자(Maximum Concurrent Users) 라고 한다.

 

Saturation Point 이후의 동작

성능 튜닝이 적절하게 이루어진 시스템이라면 Saturation Point 이후에는 TPS가 일정 수준에서 유지되고,

대신 요청이 대기하면서 응답 시간이 점차 증가한다.

 

반면, 튜닝이 제대로 이루어지지 않은 시스템은 Saturation Point를 지난 이후 오히려 TPS가 감소하는 현상이 발생할 수 있다.

이러한 현상은 스레드 경합(Thread Contention), 과도한 컨텍스트 스위칭(Context Switching), DB Lock, Garbage Collection(GC), I/O 병목 등의 문제로 인해 서버의 처리 효율이 떨어지기 때문이다.

이상적인 시스템의 특성

• Saturation Point 이전: 동시 사용자가 증가할수록 TPS가 선형적으로 증가한다.
• Saturation Point 이후: TPS는 일정 수준을 유지하고 응답 시간만 증가한다.
• Saturation Point 이후 TPS가 감소한다면 성능 병목이 존재하므로 원인을 분석하고 개선해야 한다.

예시

예를 들어, 어떤 서비스가 동시 사용자 300명에서 Saturation Point에 도달했다고 가정해 보자.

• 최대 TPS: 50 TPS
• Saturation Point: 동시 사용자 300명

이 상태에서는 동시 사용자가 300명을 초과하더라도 TPS는 50 TPS 이상으로 증가하지 않는다. 대신 서버 내부에 처리 대기(Request Queue)가 발생하여 응답 시간이 계속 길어진다.

만약 동시에 처리해야 할 요청이 300건이고 시스템이 초당 50건(TPS 50) 을 처리할 수 있다면, 모든 요청을 처리하는 데에는 이론적으로 ​약 6초(300 ÷ 50) 가 소요된다. 실제 환경에서는 네트워크 지연, 스케줄링, 애플리케이션 처리 시간 등의 영향으로 이보다 더 오래 걸릴 수도 있다.

 

Saturation Point를 측정하는 이유

TPS와 동시 사용자 수의 관계를 측정하면 시스템이 어느 시점에서 한계에 도달하는지 미리 예측할 수 있으며, 이를 통해 서비스의 최대 처리 능력을 객관적으로 평가할 수 있다.

이러한 목적의 대표적인 성능 테스트가 Critical Performance Test(임계 성능 테스트) 이다. 이 테스트의 핵심 목표는 Saturation Point를 찾아내는 것​이며, 이를 통해 다음과 같은 정보를 확인할 수 있다.

• 시스템이 처리할 수 있는 최대 TPS
• Saturation Point에서의 평균 및 최대 응답 시간
• CPU, 메모리, 디스크, 네트워크 등의 자원 사용률
• 시스템이 안정적으로 처리 가능한 최대 허용 동시 사용자 수
• 성능 병목(Bottleneck)이 발생하는 구간과 원인

이러한 결과는 시스템 증설, 성능 튜닝, 용량 산정(Capacity Planning)의 기준이 되며, 실제 운영 환경에서 안정적인 서비스를 제공하기 위한 중요한 지표로 활용된다.