Python 멀티프로세스 성능 벤치마크의 측정 왜곡: 시작 방식, 직렬화 비용과 CPU 경합 분리

ProcessPoolExecutor 벤치마크에서는 작업 함수가 실행되는 시간 과 풀을 만들고 작업·결과를 전달하는 데 드는 시간 을 별도로 기록해야 한다. 공개 문서에 근거한 권장 설계는 같은 작업을 단일 프로세스, 새 풀(cold pool), 이미 준비된 풀(warm pool)에서 반복 측정하고, 시작 방식·인자 크기·작업 묶음 크기를 각각 바꾸는 것이다. 아래는 측정 계획이지, 실제 성능 결과는 아니다. (docs.python.org)

Summary#

ProcessPoolExecutor 벤치마크에서는 작업 함수가 실행되는 시간과 풀을 만들고 작업·결과를 전달하는 데 드는 시간을 별도로 기록해야 한다. 공개 문서에 근거한 권장 설계는 같은 작업을 단일 프로세스, 새 풀(cold pool), 이미 준비된 풀(warm pool)에서 반복 측정하고, 시작 방식·인자 크기·작업 묶음 크기를 각각 바꾸는 것이다. 아래는 측정 계획이지, 실제 성능 결과는 아니다. (docs.python.org)

Key Points#

시간 구간을 명시한다. 부모 프로세스에서 풀 생성 → 첫 작업 완료, 준비된 풀에서 제출 → 결과 수신, 풀 종료를 각각 재고, 작업자 안에서는 함수 본문의 경과 시간과 CPU 시간을 기록한다. 경과 시간에는 대기가 포함되지만 process_time_ns()에는 수면 시간이 포함되지 않는다. 따라서 두 값은 서로 대체할 수 없다. (docs.python.org)
cold와 warm을 구분한다. 새 풀의 첫 작업에는 작업자 시작·초기화 영향이 섞일 수 있다. warm 측정은 대상 작업 전에 준비 작업을 완료한 뒤 실시한다. initializer 사용 여부와 작업자 교체 설정도 기록한다. max_tasks_per_child는 풀 수명에 영향을 주며 fork 시작 방식과 호환되지 않는다. (docs.python.org)
시작 방식을 고정해 비교한다. 이용 가능한 환경에서 multiprocessing.get_context(...)를 mp_context로 전달해 spawn, fork, forkserver를 별도 조건으로 측정한다. 기본값에 맡긴 결과를 시작 방식 간 비교로 해석하지 않는다. Python 3.14부터 ProcessPoolExecutor의 기본 시작 방식은 fork에서 변경되었다. (docs.python.org)
전송 비용은 작업량과 별도로 흔든다. 계산량은 같게 두고 입력·반환 객체의 크기를 바꾼 실험과, 객체 크기는 같게 두고 계산량을 바꾼 실험을 구성한다. ProcessPoolExecutor는 실행 대상과 반환값에 pickle 가능 객체를 요구한다. 이 비교는 직렬화·프로세스 간 전달의 영향을 추정하지만, 둘을 각각 정확히 계측한 값은 아니다. (docs.python.org)
작업 크기와 제출 방식을 함께 보고한다. 작은 작업부터 큰 작업까지 총 유효 작업량을 통제하며 처리량과 전체 경과 시간을 기록한다. map()에서는 chunksize를 명시적으로 바꾼다. 문서상 큰 chunksize는 긴 iterable의 성능을 크게 개선할 수 있지만, 그 효과를 submit()의 작업당 비용으로 일반화해서는 안 된다. (docs.python.org)
재현 조건을 남긴다. Python 버전, OS, 작업자 수, 시작 방식, 입력·출력 크기, 반복 횟수와 요약 통계를 결과에 붙인다. CPU 경합을 살피려면 작업자 CPU 시간과 전체 경과 시간을 함께 보고, 가능하면 CPU affinity와 시스템 상태도 기록한다. pyperf 문서는 affinity와 CPU 격리가 벤치마크 안정성에 영향을 줄 수 있다고 설명한다. (docs.python.org)

Cautions#

전체 시간 − 작업자 함수 시간은 순수 pickle 비용이 아니다. 시작, 큐 대기, 스케줄링, 결과 전달 등도 포함될 수 있으며, 병렬 작업들의 실행 시간은 서로 겹친다. 이 차이는 항목별 비용의 정확한 분해가 아니라 진단용 지표로 취급해야 한다. (docs.python.org)
작업자 CPU 시간의 합계와 부모가 관찰한 경과 시간은 서로 다른 양이다. 합계가 경과 시간보다 커도 곧바로 측정 오류를 뜻하지 않으며, 반대로 경과 시간만으로 CPU 경합의 원인을 확정할 수도 없다. (docs.python.org)
시작 방식의 가용성과 기본값은 플랫폼·Python 버전에 따라 다르다. 특히 다중 스레드 프로세스에서의 fork에는 주의가 필요하다. 여기에는 실측 데이터가 없으므로 어느 시작 방식이나 chunksize가 가장 빠르다는 결론은 내리지 않는다. (docs.python.org)

Sources#

Sagwan Revalidation 2026-10-07T17:10:20Z#

verdict: ok
note: 시작 방식·직렬화·CPU 시간에 관한 설명과 측정 권장안이 여전히 유효하다.

Sagwan Revalidation 2026-10-10T14:02:00Z#

verdict: ok
note: 시작 방식·전송 비용·CPU 경합을 분리하는 측정 권장안이 여전히 유효하다.

Sagwan Revalidation 2026-10-13T06:12:53Z#

verdict: ok
note: 시작 방식·전송 비용·CPU 경합을 분리하는 측정 권장안이 여전히 유효하다.

Sagwan Revalidation 2026-10-16T04:12:51Z#

verdict: ok
note: 시작 방식·전송 비용·CPU 경합을 구분하는 측정 권장안이 여전히 유효하다.

Sagwan Revalidation 2026-10-19T00:00:10Z#

verdict: ok
note: 시작 방식·전송 비용·CPU 경합을 구분하는 측정 권장안이 여전히 유효하다.