Python 3.14용 작업 큐 라이브러리 solid-jobs-py 0.1.0은 하위 인터프리터로 작업을 병렬 실행하며, 제작자가 진행한 로컬 벤치마크에서 동시 작업자 8명 기준 Celery보다 메모리를 약 48% 적게 사용했다. CPU 작업 처리량은 대체로 비슷했지만, 입출력 작업에서는 동시성이 낮을 때 Celery가 5~15% 앞섰다.
solid-jobs-py는 Ruby용 solid-jobs를 Python으로 옮긴 작업 큐다. Python 작업자들이 Redis에 직접 접근하는 대신 Ruby 동반 프로세스(sidecar)가 solid-redis를 통해 Redis 요청을 처리한다. 실제 CPU 병렬 실행에는 Python 3.14의 concurrent.interpreters를 사용한다.
사용하려면 Python 3.14 이상, Ruby와 solid-redis 1.0.13 이상, Redis 서버가 필요하다. 설치 명령은 pip install .이다. 작업은 Task를 상속해 정의하고 큐에 넣으며, 작업자 실행 명령은 solid-jobs다. Rails/ActiveJob 어댑터, warm pool, Ractor 전용 코드는 이식되지 않았다.
벤치마크 결과와 조건
벤치마크는 Python 3.14.7, Apple Silicon의 논리 CPU 12개, Celery 5.6.3, solid-jobs-py 0.1.0과 로컬 Redis를 사용했다. 시스템별 새 작업자를 띄워 1,000개 작업을 6회 측정한 중앙값이며, 메모리는 Ruby 동반 프로세스까지 포함한 전체 프로세스 트리의 최대 RSS다. Celery는 prefork 풀과 Redis 브로커를 사용했다.
동시성 8에서 CPU 작업 처리량은 Celery 957건/초, solid-jobs-py 924건/초였고, 메모리는 각각 270MiB와 141MiB였다. 혼합 작업 처리량은 각각 1,133건/초와 1,059건/초였다. 입출력 작업은 각각 1,311건/초와 1,114건/초로 Celery가 앞섰다. 제작자는 입출력 작업의 차이가 time.sleep(5 ms)의 macOS 실행 시간 차이에서 비롯됐으며, 하위 인터프리터 자체의 비용은 아니라고 설명했다.
동시성 4·8·16으로 진행한 별도 스트레스 측정에서도 solid-jobs-py는 Celery보다 메모리를 적게 썼다. 다만 처리량은 작업 종류와 동시성에 따라 달랐다. 동시성 16에서는 CPU와 혼합 작업에서 solid-jobs-py가 앞섰고, 입출력 작업은 거의 비슷했다.
빈 작업(noop) 측정에서는 예약과 확인 응답(ack)을 한 번의 Redis 왕복으로 묶은 뒤 solid-jobs-py가 Celery보다 1명 작업자에서 1.94배, 4명에서 3.06배 높은 처리량을 기록했다. 이는 이 라이브러리의 특정 빈 작업 측정 결과이며 일반 작업 처리 성능을 뜻하지 않는다.
안정성 측정은 시스템별 5분간 진행했다. 두 시스템 모두 처리량과 메모리가 안정적이었고 작업 손실은 없었지만, 30분 측정은 하지 않았다. 제작자는 전체 측정에서 144회, 각 회당 1,000개 작업이 모두 실행됐으며 오류와 중복은 없었다고 보고했다. 다만 예약 신뢰성이나 장애 복구 보장은 벤치마크로 측정한 항목이 아니라고 밝혔다. 결과는 합성 작업을 이용한 로컬 테스트이므로 실제 서비스 용량을 예측하는 자료로 볼 수는 없다.
전체 벤치마크 코드와 보고서는 GitHub 저장소에서 확인할 수 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요