https://blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1/
글을 읽고 WSGI에 대해, 그리고 WSGI(위스키 혹은 위~지~) 가 왜 필요한지 알아보았다.
왜 WSGI가 필요한가?
-> 가장 기본에 충실한 대답. "많은 요청을 동시에 처리하기 위해서!"
우리가 사용하는 프레임워크는 웹 애플리케이션으로서의 처리만 Concern할 뿐 다수의 요청이나 핸들링 등은 고려하지 않았다.
종류는 다양하다.
다양한 언어와 플랫폼, 프레임워크등과의 호환을 자랑하며 계속적으로 성장하는 uWSGI,
단 18KB의 코드만으로 성능도 끝내주는 Bjoern,
내가 사용 중인 mod_wsgi (사실은 개발자 한명이 handle한다고 한다),
greenlet을 기반으로 하며 비동기 I/O를 빠르고 가볍게 해주는 오픈소스 Meinheld,
아주 간편한 세팅으로 빠르게 사용할 수 있으며 파이썬 가이드라인도 따르는 CherryPy (원래 파이썬 프레임워크다 - 다음 번에 써 봐야지)
Unix용 Green Unicorn의 합성어인 Gunicorn. 원래는 루비 프로젝트였으나 파이썬으로 넘어오게 되었고 가볍고 빠르며 설정도 쉬운 편이다.
자 그럼 어떤 WSGI가 좋을까?
가볍게 추려서 얘기하면,
Bjoern은 빠르고 C로 만들어졌다, 얘는 비동기 방식을 지원하지만 HTTP 1.1을 지원하지는 않는다. Meinheld는 C로 만들어져서 가볍고 빠르다.
uWSGI는 확장할 수 있는 범위나 방법이 많고 강력하며 다양한 언어를 처리한다. (그러나 일부 개발자들은 풀스택 솔루션을 목표로 하는 이 프레임워크가 쓸데없이 비대해지고 있다고도 한다.)
Mod_wsgi는 작동은하지만.. 좀 구식이다.
Gunicorn은 속도가 적당하고 리소스 소모가 크지 않은편이며 장고랑 자동으로 쿵딱쿵딱 한다.
CherryPy의 built-in Web server는 가볍고 안정적이며 좋다! (어떤 개발자는 갖고 놀기 아주 좋네! 라고 했다고 한다. )
글을 읽고 WSGI에 대해, 그리고 WSGI(위스키 혹은 위~지~) 가 왜 필요한지 알아보았다.
왜 WSGI가 필요한가?
-> 가장 기본에 충실한 대답. "많은 요청을 동시에 처리하기 위해서!"
우리가 사용하는 프레임워크는 웹 애플리케이션으로서의 처리만 Concern할 뿐 다수의 요청이나 핸들링 등은 고려하지 않았다.
종류는 다양하다.
다양한 언어와 플랫폼, 프레임워크등과의 호환을 자랑하며 계속적으로 성장하는 uWSGI,
단 18KB의 코드만으로 성능도 끝내주는 Bjoern,
내가 사용 중인 mod_wsgi (사실은 개발자 한명이 handle한다고 한다),
greenlet을 기반으로 하며 비동기 I/O를 빠르고 가볍게 해주는 오픈소스 Meinheld,
아주 간편한 세팅으로 빠르게 사용할 수 있으며 파이썬 가이드라인도 따르는 CherryPy (원래 파이썬 프레임워크다 - 다음 번에 써 봐야지)
Unix용 Green Unicorn의 합성어인 Gunicorn. 원래는 루비 프로젝트였으나 파이썬으로 넘어오게 되었고 가볍고 빠르며 설정도 쉬운 편이다.
자 그럼 어떤 WSGI가 좋을까?
가볍게 추려서 얘기하면,
Bjoern은 빠르고 C로 만들어졌다, 얘는 비동기 방식을 지원하지만 HTTP 1.1을 지원하지는 않는다. Meinheld는 C로 만들어져서 가볍고 빠르다.
uWSGI는 확장할 수 있는 범위나 방법이 많고 강력하며 다양한 언어를 처리한다. (그러나 일부 개발자들은 풀스택 솔루션을 목표로 하는 이 프레임워크가 쓸데없이 비대해지고 있다고도 한다.)
Mod_wsgi는 작동은하지만.. 좀 구식이다.
Gunicorn은 속도가 적당하고 리소스 소모가 크지 않은편이며 장고랑 자동으로 쿵딱쿵딱 한다.
CherryPy의 built-in Web server는 가볍고 안정적이며 좋다! (어떤 개발자는 갖고 놀기 아주 좋네! 라고 했다고 한다. )
댓글
댓글 쓰기