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

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)
13296정성태3/25/202348Windows: 234. IsDialogMessage와 협업하는 WM_GETDLGCODE Win32 메시지파일 다운로드1
13295정성태3/24/202353Windows: 233. Win32 - modeless 대화창을 modal처럼 동작하게 만드는 방법파일 다운로드1
13294정성태3/22/202394.NET Framework: 2105. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 - 두 번째
13293정성태3/22/202383오류 유형: 853. dumpbin - warning LNK4048: Invalid format file; ignored
13292정성태3/21/2023101Windows: 232. C/C++ - 일반 창에도 사용 가능한 IsDialogMessage파일 다운로드1
13291정성태3/20/2023117.NET Framework: 2104. C# Windows Forms - WndProc 재정의와 IMessageFilter 사용 시의 차이점
13290정성태3/19/2023169.NET Framework: 2103. C# - 윈도우에서 기본 제공하는 FindText 대화창 사용법파일 다운로드1
13289정성태3/18/202379Windows: 231. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 자식 윈도우를 생성하는 방법파일 다운로드1
13288정성태3/17/202388Windows: 230. Win32 - 대화창의 DLU 단위를 pixel로 변경하는 방법파일 다운로드1
13287정성태3/16/202387Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법파일 다운로드1
13286정성태3/15/2023133Windows: 228. Win32 - 리소스에 포함된 대화창 Template의 2진 코드 해석 방법
13285정성태3/14/2023128Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법파일 다운로드1
13284정성태3/13/2023131Windows: 226. Win32 C/C++ - Dialog에서 값을 반환하는 방법파일 다운로드1
13283정성태3/12/202389오류 유형: 852. 파이썬 - TypeError: coercing to Unicode: need string or buffer, NoneType found
13282정성태3/12/2023111Linux: 58. WSL - nohup 옵션이 필요한 경우
13281정성태3/12/2023151Windows: 225. 윈도우 바탕화면의 아이콘들이 넓게 퍼지는 경우 [2]
13280정성태3/9/2023159개발 환경 구성: 670. WSL 2에서 호스팅 중인 TCP 서버를 외부에서 접근하는 방법
13279정성태3/9/202398오류 유형: 851. 파이썬 ModuleNotFoundError: No module named '_cffi_backend'
13278정성태3/8/2023132개발 환경 구성: 669. WSL 2의 (init이 아닌) systemd 지원
13277정성태3/6/2023153개발 환경 구성: 668. 코드 사인용 인증서 신청 및 적용 방법(예: Digicert)
13276정성태3/5/2023215.NET Framework: 2102. C# 11 - ref struct/ref field를 위해 새롭게 도입된 scoped 예약어
13275정성태3/3/2023211.NET Framework: 2101. C# 11의 ref 필드 설명
13274정성태3/2/2023220.NET Framework: 2100. C# - ref 필드로 ref struct 타입을 허용하지 않는 이유
13273정성태2/28/2023249.NET Framework: 2099. C# - 관리 포인터로서의 ref 예약어 의미
13272정성태2/27/2023174오류 유형: 850. SSMS - mdf 파일을 Attach 시킬 때 Operating system error 5: "5(Access is denied.)" 에러
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...