배경
현재 회사에서 FastAPI를 쓰고 있다. 자바를 전문적으로 쓸 수 있는 개발자도, 팀장님도 잘 모르시는 상황이기에 (혹은 여러가지 이유로 인해) 자바가 아닌 상대적으로 다루기 쉬운 파이썬을 사용하고 있으며, 그 중에 FastAPI 프레임워크를 사용하고 있고 앞으로도 그렇게 사용할거 같다.
둘 다 사용해본 입장에서 성능 측면에서는 컴파일러이니까 springboot가 fastapi보다 빠르다고 생각은 하지만 얼마나 성능차이가 날까 궁금해서 한 번 직접 더미 데이터로 실험을 해보려고 한다.
컴퓨터 사양은 다음과 같고
프로세스 : 12th Gen Intel(R) Core(TM) i7-12700F (20 CPUs), ~2.1GHz
메모리 : 16384MB
Springboot와 FastAPI에 대한 사양은 다음과 같다. (Java, Python 버젼 포함)
Java 17
Springboot version - 3.2.2
Python 3.12
FastAPI version - 0.110.2
데이터는 다음과 같이 구성했고, 100만개로 세팅하였다.
DB 버젼은 다음과 같다.
MariaDB [(none)]> select version();
+-----------------+
| version() |
+-----------------+
| 10.11.6-MariaDB |
+-----------------+
1 row in set (0.001 sec)
CREATE TABLE employees
(
id SERIAL PRIMARY KEY,
first_name VARCHAR(100) NOT NULL,
last_name VARCHAR(100) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
phone_number VARCHAR(15),
hire_date DATE NOT NULL,
job_title VARCHAR(100) NOT NULL,
salary DECIMAL(10, 2) NOT NULL,
department VARCHAR(100),
has_parking_space BOOLEAN DEFAULT false,
contract_duration INTERVAL
);
코드
@RestController
@RequiredArgsConstructor
public class SimpleExecutorController {
....
@GetMapping("/employees")
@Cacheable("employees")
public Page<Employee> getAllEmployees(Pageable pageable) {
return simpleExecutorService.findAll(pageable);
}
}
@Service
@Log4j2
@RequiredArgsConstructor
public class SimpleExecutorService {
private final EmployeeRepository employeeRepository;
...
@Cacheable("employees") // 결과를 캐시
public Page<Employee> findAll(Pageable pageable) {
return employeeRepository.findAll(pageable);
}
}
# main.py
from faker import Faker
from fastapi import FastAPI
from app.database import engineconn
from app.models import models
from app.models.models import Employees
app = FastAPI()
engine = engineconn()
session = engine.sessionmaker()
@app.get("/employees")
async def read_employees():
example = session.query(models.Employees).all()
return example
# models.py
from sqlalchemy import Column, Integer, String, Date, Float, Boolean
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class Employees(Base):
__tablename__ = "employees"
id = Column(Integer, primary_key=True, autoincrement=True)
first_name = Column(String(100), nullable=False)
last_name = Column(String(100), nullable=False)
email = Column(String(100), nullable=False)
phone_number = Column(String(15), nullable=True)
hire_date = Column(Date, nullable=False)
job_title = Column(String(100), nullable=False)
salary = Column(Float, nullable=False)
department = Column(String(100), nullable=True)
has_parking_space = Column(Boolean, default=False, nullable=True)
contract_duration = Column(Integer, nullable=True)
테스트
유저수는 2000명 기준으로 했고, 1분동안 테스트
Framework | Sample | Average | Min | Max | Std. Dev | Error % | Throughput | Received KB/sec | Sent KB/sec | Avg. Bytes |
---|---|---|---|---|---|---|---|---|---|---|
Spring Boot | 3315 | 62383 | 855 | 98059 | 29500.09 | 0.00% | 22.2 | 124.87 | 3.08 | 5753.7 |
FastAPI | 3800 | 346 | 0 | 2227 | 644.06 | 87.18% | 1470.6 | 4311.76 | 26.14 | 3002.4 |
Samples - 응답 갯수 (표본 수)
Average - 응답 평균 (ms)
Min - 응답 최소 (ms)
Max - 응답 최대 (ms)
Std. Dev. - 응답 표준편차
Error % - 에러율
Throughput - 시간당 처리량 (TPS)
Received KB/sec - 시간당(sec) 받은 데이터(KB)
Sent KB/sec - 시간당(sec) 보낸 데이터(KB)
Avg. Bytes - 평균 바이트
지금 보면 springboot가 fastapi에 비해 수치가 낮은 것을 볼 수 있는데 error를 보면 사실 fastapi는 얼마못가서 애플리케이션이 버티질 못하는 상황이기에 thoughtput 보는것이 의미가 없긴하다. 그리고 회사에서는 workers 수치를 높여 tps를 개선하긴 했지만 윈도우에서는 그 수치를 높여도 프로세스 숫자가 높아지지 않는다는 것을 오늘에서야 알았다. 그래서 윈도우에서는 workers 수치를 높여도 2000개의 요청을 버티지 못하고 애플리케이션이 죽어버리는 현상이 일어났다.
결론
생각대로 springboot가 많은 요청을 fastapi 비해서 많이 처리를 할 수 있다는 것을 알게 되었다. 다만 내가 잘못 테스트를 하는지를 모르겠지만 단순 select query 테스트를 하는건데도 springboot에서도 22 TPS 수치밖에 안 나왔다. 적어도 200~300정도는 나와야 하지 않을까 생각했는데 생각보다 너무 적게 나온거 같다.
그래서 다음 글에는 springboot 기반으로 개선 관련된 것을 한 번 포스팅을 하려 한다.
'기타' 카테고리의 다른 글
MSA에 대한 장단점 (0) | 2024.04.09 |
---|---|
SHA-1과 SHA-2 해시 알고리즘의 차이점: 보안성을 중심으로 (0) | 2024.04.03 |
"HMAC: 보안의 핵심을 이해하기" (0) | 2024.04.02 |
JWT (JSON Web Token) 기초: 구조와 작동 원리 이해하기 (0) | 2024.04.01 |
mcrouter의 라우팅 기법 이해하기: 기본 설정과 사용 방법 (0) | 2024.04.01 |