제가 느껴보고 조사한 장고와 스프링의 차이점입니다.
잘못된 정보가 있다면 댓글로 알려주시면 정말 감사하겠습니다.

리퀘스트 처리 방식

web application(framework)

장고: 단일 스레드 동기처리(single thread-synchronous)

스프링: 멀티 스레드 비동기처리 가능(@Async 어노테이션으로 JAVA 비동기 처리 구현)

--장고 + 파이썬 --

장고의 경우 celery라이브러리 없이 비동기 작업은 구현이 까다롭고 performance에 영향을 미친다고 한다.

하지만 아래와 같이 비동기 작업을 곧 지원할 예정이고, 현재도 performance의 tradeoff는 있지만 ASGI로 구동시 가능하다.

장고가 단일 스레드로 구동되는 이유는 파이썬의 garbage collector가 구동되는 원리인 reference count의 안정성을 다중 스레드로 인한 race condition이 초래할 문제를 방지하는 GIL mutex로 인하여 호스트가 여러 코어를 가지고 있다하더라도 특정한 시점에 byte코드를 실행하는 스레드가 하나로 제한되기 때문이다.

하지만 cpu bound task가 아닌 I/O bound task에서는 GIL이 적용되지 않아 멀티스레드를 사용할 수 있고, 비동기 작업의 경우도 python 3.5 버전 이후로 async/await의 표준을 도입하여 지원하고 있다.

--스프링+java--

멀티 쓰레드 지원:
하나의 프로세스 내에서 자원을 공유{코드 영역, 데이터 영역(전역 변수-정적,힙 영역-동적)}하는 자원이 그렇지 못한 자원(레지스터, 스택영역-정적)보다 많아 context switching의 비용이 훨씬 적고 실행되는 코드 영역도 멀티 프로세스에 비하여 구체적이다(스레드에서 실행할 함수를 정함으로).

메인스레드로 부터 호출하여 각각 독립적인 작업이 가능하다.
또한 스레드 풀을 이용하여 매 작업 마다 스레드를 만들어 내지 않음으로써 더 효율성을 높일수 있다고 한다.(단 너무 많은 thread를 미리 생성시 메모리 낭비가 있다고한다).

비동기 지원:
스레드 풀을 이용하여 @Async어노테이션으로 함수 작성후 사용가능 하다고 한다.

WAS(web application server)

스프링, 장고등은 각각 java와 python으로 작성된 프로그램으로
HTTP 프로토콜로 받아 들인 request line을 분석하는 기능은 없다.
이와 같이 HTTP요청을 분석하고 request line의 target url에 맞는 함수를 호출하는 작업을 하는 소프트웨어를 WAS가 담당한다.
또한 많은 요청이 들어 오는 경우

gunicorn(장고 WAS)

master process로 부터 fork된 정해진 수의 worker process가 동시적으로
요청을 처리한다. 정해진 worker process가 처리할 수있는 양보다 많은 request가 있는 경우 연결을 유지 시킨다.
이 때 worker process가 실행하는 django는 단일 스레드로 동작한다.

Tomcat(Spring WAS)

thread pool의 스레드를 할당하여 요청을 처리하며
thread pool의 스레드가 처리할 수있는 양보다 많은 리퀘스트가 주어질때
Tomcat내부의 request queue로 관리한다.
tomcat의 request thread가 일반적으로 모든 reponse까지의 작업을 처리하지만,
장고와 다르게 TaskExecutor와 ParallelStreamUtils등으로 병렬처리가 가능하다고 한다.👍🏻

로직 처리 방식

장고:

request를 처리 할때 마다 새로운 instance를 생성하여 처리한다.

장점:

1. 독립성:
   각 리퀘스트를 처리하는데 필요한 데이터의 공유 가능성이 없다.

단점:

1. 오버헤드 증가: 매 요청마다 새로운 인스턴스를 생성하므로 초기화 등의 부가 작업과 추가로 소모되는 메모리등의 시간,공간적 자원을 많이 소모한다.
2. 무상태: 세션 스토리지나 다른 캐시의 도움 없이 모든 요청간 상태를 유지하기가 힘들다.

스프링:

싱글톤 패턴으로 한 번 생성한 빈(인스턴스)을 계속해서 재사용한다.

장점:

1. 자원, 성능 효율성:
   장고와 달리 한 번 생성한 인스턴스를 재사용하므로 인스턴스 초기화, 추가 생
   성에 필요한 시간,공간적 자원의 소모가 없고, 주어진 시간에 더 많은 작업을
   처리할 수 있다.
2. 전역 상태:
   스프링 어플리케이션이 실행되는 동안 공유 자원, 어플리케이션 구성 등의 상태
   를 관리 할 수있다?
3. DI:
   스프링 어플리케이션이 실행되는 동안 의존성을 유지하고,
   어플리케이션의 구성을 바꿀때 의존성을 바꾸어 줌으로 달성할 수 있다?

단점:

1. 전역 상태 훼손:
   다양한 다른 인스턴스들이 전역 변수, 클래스의 필드 등을 바꿀 수 있다.
   혹은 논리적으로는 변경이 없을 지라도 thread safety를 보장할 수 없다.
   따라서 클라이언트 측에서 인스턴스의 필드에 접근 할 수 없도록 조치해야하고
   이로 인하여 투명성이 낮아진다.