Microsoft MVP성태의 닷넷 이야기
스크립트: 43. uwsgi의 --processes와 --threads 옵션 [링크 복사], [링크+제목 복사]
조회: 4077
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

uwsgi의 --processes와 --threads 옵션

지난 글에서,

파이썬 - uwsgi의 --enable-threads 옵션
; https://www.sysnet.pe.kr/2/0/12886

uwsgi의 prefork/worker 방식에 대해 언급했하면서 테스트를 했는데, 뭘 좀 몰랐던 시기라 테스트가 제대로 안 되었습니다. ^^; 그래서 이참에 다시 정리해 봅니다.




uwsgi 테스트를 위해 최소 구현 코드만을 만족하는 다음의 파이썬 코드로,

import os
import time
from datetime import datetime

HELLO_WORLD = b"Hello world!\n"


def simple_app(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    print(os.getpid(), os.getppid(), environ['REQUEST_URI'], "called", datetime.now().strftime("%H:%M:%S"))
    time.sleep(10)
    start_response(status, response_headers)
    return [HELLO_WORLD]


application = simple_app

uwsgi를 기본 옵션만을 사용해 호스팅해보겠습니다.

$ uwsgi --http :18000  --wsgi-file ./main.py

이 상태에서 웹 브라우저를 통해 (식별을 위해 sleep1, sleep2를 경로에 추가해) 2번 동시에 방문해 보면 화면에 다음과 같은 출력을 볼 수 있습니다.

// 2개의 동시 요청, http://localhost:18000/sleep1, http://localhost:18000/sleep2

22053 19712 /sleep1 called 11:38:46
22053 19712 /sleep2 called 11:38:56

즉, 2개의 요청이 직렬화돼 하나의 프로세스(22053)에서 차례대로 실행되었습니다. 이때의 uwsgi 프로세스 구조를 보면,

├─init(19710)───init(19711)───bash(19712)───uwsgi(22053)

단일하게 실행 중인 1개의 uwsgi를 볼 수 있습니다. 그러니까, uwsgi 프로세스 한 개당 1개의 동시 요청만 처리하고 있는 것입니다. 이러한 동시성을 개선하기 위해 줄 수 있는 옵션이 prefork/worker 프로세스 방식일 텐데요, 재미있게도 uwsgi의 경우 이 옵션이 각각 --processes, --workers로 나뉘어 있지만 정작 약식 옵션으로는 "-p"로 통일이 되므로,

    -p|--processes                          spawn the specified number of workers/processes
    -p|--workers                            spawn the specified number of workers/processes

사실상 2개의 옵션은 완전히 같은 역할을 합니다. 또한, 기본값은 모두 1인데요, 즉 기본적으로 떠 있는 uwsgi 프로세스가 하나의 worker/process에 해당합니다. 따라서 다음과 같이 workers/processes를 3으로 주면,

$ uwsgi --http-socket :18000 --wsgi-file ./main.py --workers 3
...[생략]...
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (pid: 22079, cores: 1)
spawned uWSGI worker 2 (pid: 22080, cores: 1)
spawned uWSGI worker 3 (pid: 22081, cores: 1)

$ uwsgi --http-socket :18000 --wsgi-file ./main.py --processes 3
...[생략]...
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (pid: 22081, cores: 1)
spawned uWSGI worker 2 (pid: 22082, cores: 1)
spawned uWSGI worker 3 (pid: 22083, cores: 1)

예상할 수 있듯이 프로세스의 구조도 같습니다.

// worker/processes 총 3개: 22081, 22082, 22083

 ├─init(19710)───init(19711)───bash(19712)───uwsgi(22081)─┬─uwsgi(22082)
 │                                                        └─uwsgi(22083)

더욱 재미있는 건, uwsgi에도 --threads 옵션이 있다는 점입니다. 실제로 다음과 같은 식으로 실행해 보면,

$ uwsgi --http :18000  --wsgi-file ./main.py --processes 3 --threads 4

이때의 프로세스 결과는 이렇게 나옵니다.

// processes 3개 == 22111, 22112, 22113

// 프로세스 당 threads 4개
// 22111(프로세스이면서 스레드), 22116, 22119, 22122
// 22112(프로세스이면서 스레드), 22114, 22117, 22121
// 22113(프로세스이면서 스레드), 22115, 22118, 22120

├─init(19710)───init(19711)───bash(19712)───uwsgi(22111)─┬─uwsgi(22112)─┬─{uwsgi}(22114)
│                                                        │              ├─{uwsgi}(22117)
│                                                        │              └─{uwsgi}(22121)
│                                                        ├─uwsgi(22113)─┬─{uwsgi}(22115)
│                                                        │              ├─{uwsgi}(22118)
│                                                        │              └─{uwsgi}(22120)
│                                                        ├─{uwsgi}(22116)
│                                                        ├─{uwsgi}(22119)
│                                                        └─{uwsgi}(22122)

출력 결과를 보면, "uwsgi"라고 나오는 것과 "{uwsgi}"라고 나오는 것이 있습니다. 중괄호가 없는 것이 프로세스이고, 있는 것이 스레드입니다.

당연히, 이런 경우 동시 처리가 됩니다. 위의 예제 코드에 대한 요청을 다시 재현해 보면,

$ uwsgi --http-socket :18000 --wsgi-file ./main.py --processes 3

// 2개 동시 요청: http://localhost:18000/sleep1, http://localhost:18000/sleep2

22126 22124 /sleep1 called 13:51:20
22125 22124 /sleep2 called 13:51:21
22124 19712 /favicon.ico called 13:51:30
22126 22124 /favicon.ico called 13:51:41

// 프로세스 구조
├─init(19710)───init(19711)───bash(19712)───uwsgi(22124)─┬─uwsgi(22125)
│                                                        └─uwsgi(22126)

/sleep1과 /sleep2가 함께 처리되고 있는 것을 볼 수 있고, (웹 브라우저로 인해 부가적으로 발생한) favicon.ico 요청까지 처리하는 프로세스 ID까지 고려하면 3개의 uwsgi 프로세스가 요청을 협업해서 처리하고 있습니다.

--processes와 --threads의 또 다른 차이점은, --enable-threads의 활성 유무입니다. 단순히 --processes로만 fork를 한 경우에는 해당 옵션이 활성화되지 않습니다. 따라서 사용자 스레드의 활동이 필요하다면 --processes와 함께 --enable-threads도 명시해야 합니다.




아마도, uwsgi의 prefork와 worker가 사실상 fork 방식으로만 처리하는 데에는 GIL의 영향으로 인해 프로세스를 나누는 것이 최선의 방식이라고 생각했던 것 같습니다.

참고로, uwsgi로 호스팅하면 app framework에 따라 초기 프로세스의 상태가 다릅니다.

// 이 글의 예제를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22053)

// Django를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22067)───uwsgi(22068)

아마도 Django 내부에서 fork를 하는 프로세스가 하나 있는 듯한데 저 프로세스가 요청을 처리하는 uwsgi 프로세스 역할은 하지 않습니다. 또한, 이 상태에서 --py-autoreload=3 옵션을 넣으면 다시 이렇게 바뀝니다.

// 이 글의 예제를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22061)───uwsgi(22062)───{uwsgi}(22063) // --py-autoreload 옵션으로 자식 프로세스 1개와 그것에서 다시 스레드 1개

// Django를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22070)─┬─uwsgi(22071)───{uwsgi}(22072) // --py-autoreload 옵션으로 자식 프로세스 1개와 그것에서 다시 스레드 1개
│                                                        └─uwsgi(22073) // Django로 인한 1개의 자식 프로세스




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/9/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  [10]  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13341정성태5/8/20233332닷넷: 2114. C# 12 - 모든 형식의 별칭(Using aliases for any type)
13340정성태5/8/20233224오류 유형: 857. Microsoft.Data.SqlClient.SqlException - 0x80131904
13339정성태5/6/20233902닷넷: 2113. C# 12 - 기본 생성자(Primary Constructors)
13338정성태5/6/20233485닷넷: 2112. C# 12 - 기본 람다 매개 변수파일 다운로드1
13337정성태5/5/20233881Linux: 59. dockerfile - docker exec로 container에 접속 시 자동으로 실행되는 코드 적용
13336정성태5/4/20233631.NET Framework: 2111. C# - 바이너리 출력 디렉터리와 연관된 csproj 설정
13335정성태4/30/20233757.NET Framework: 2110. C# - FFmpeg.AutoGen 라이브러리를 이용한 기본 프로젝트 구성 - Windows Forms파일 다운로드1
13334정성태4/29/20233518Windows: 250. Win32 C/C++ - Modal 메시지 루프 내에서 SetWindowsHookEx를 이용한 Thread 메시지 처리 방법
13333정성태4/28/20232975Windows: 249. Win32 C/C++ - 대화창 템플릿을 런타임에 코딩해서 사용파일 다운로드1
13332정성태4/27/20233108Windows: 248. Win32 C/C++ - 대화창을 위한 메시지 루프 사용자 정의파일 다운로드1
13331정성태4/27/20233115오류 유형: 856. dockerfile - 구 버전의 .NET Core 이미지 사용 시 apt update 오류
13330정성태4/26/20232776Windows: 247. Win32 C/C++ - CS_GLOBALCLASS 설명
13329정성태4/24/20233071Windows: 246. Win32 C/C++ - 직접 띄운 대화창 템플릿을 위한 Modal 메시지 루프 생성파일 다운로드1
13328정성태4/19/20232685VS.NET IDE: 184. Visual Studio - Fine Code Coverage에서 동작하지 않는 Fake/Shim 테스트
13327정성태4/19/20233113VS.NET IDE: 183. C# - .NET Core/5+ 환경에서 Fakes를 이용한 단위 테스트 방법
13326정성태4/18/20234300.NET Framework: 2109. C# - 닷넷 응용 프로그램에서 SQLite 사용 (System.Data.SQLite) [1]파일 다운로드1
13325정성태4/18/20233750스크립트: 48. 파이썬 - PostgreSQL의 with 문을 사용한 경우 연결 개체 누수
13324정성태4/17/20233536.NET Framework: 2108. C# - Octave의 "save -binary ..."로 생성한 바이너리 파일 분석파일 다운로드1
13323정성태4/16/20233396개발 환경 구성: 677. Octave에서 Excel read/write를 위한 io 패키지 설치
13322정성태4/15/20234068VS.NET IDE: 182. Visual Studio - 32비트로만 빌드된 ActiveX와 작업해야 한다면?
13321정성태4/14/20233086개발 환경 구성: 676. WSL/Linux Octave - Python 스크립트 연동
13320정성태4/13/20233107개발 환경 구성: 675. Windows Octave 8.1.0 - Python 스크립트 연동
13319정성태4/12/20233492개발 환경 구성: 674. WSL 2 환경에서 GNU Octave 설치
13318정성태4/11/20233315개발 환경 구성: 673. JetBrains IDE에서 "Squash Commits..." 메뉴가 비활성화된 경우
13317정성태4/11/20233466오류 유형: 855. WSL 2 Ubuntu 20.04 - error: cannot communicate with server: Post http://localhost/v2/snaps/...
13316정성태4/10/20232850오류 유형: 854. docker-compose 시 "json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)" 오류 발생
1  2  3  4  5  6  7  8  9  [10]  11  12  13  14  15  ...