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개의 자식 프로세스
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]