파이썬 서버 성능 튜닝, 커넥션 풀부터 HTTP/2 멀티플렉싱과 Zero-copy까지 완전 정리

🔄 커넥션 재사용과 커넥션 풀 크기 튜닝

파이썬으로 API 서버나 마이크로서비스를 돌리다 보면, 눈에 잘 안 보이지만 비용이 크게 드는 작업이 있다.
바로 “매 요청마다 TCP 커넥션을 새로 여는 것”이다.
TCP 핸드셰이크, TLS 네고, 커널 레벨 소켓 확보까지 모두 반복되기 때문에, 짧은 호출을 많이 하는 서비스일수록 이 오버헤드가 그대로 지연시간이 된다.
그래서 흔히 하는 첫 번째 최적화가 커넥션 재사용(keep-alive)이다.
이미 열린 커넥션을 끊지 않고 다음 요청에도 재사용하면 RTT 손실이 줄고, 외부 API 호출당 평균 레이턴시가 안정된다.
이건 단순히 “빨라진다” 수준이 아니라, 피크 트래픽에서 타임아웃을 덜 낸다는 점이 더 크다.

HTTP 클라이언트 입장에서 보면 커넥션 재사용은 ‘세션’ 단위로 관리된다.
예를 들어 requests 라이브러리의 Session, httpx의 Client, aiohttp의 ClientSession 등이 모두 같은 철학을 따른다.
이 객체들은 내부적으로 keep-alive된 커넥션 풀을 갖고 있고 필요할 때 기존 소켓을 빌려 쓴다.
즉, 매번 requests.get()을 날리는 대신 세션/클라이언트를 하나 만들고 재사용하는 구조가 되어야 한다.
이 차이만으로도 외부 의존 서비스 호출 TPS가 올라가고 에러율이 내려간 사례는 정말 많다.

그다음으로 중요한 게 풀 크기(max pool size)다.
풀 크기를 너무 작게 두면 동시 요청이 몰렸을 때 커넥션을 빌리려고 대기열이 생긴다.
반대로 너무 크게 두면 외부 서비스나 DB 쪽에서 너를 DoS 비슷하게 받아들이게 된다.
즉, 병목이 상대 서버로 넘어가 버리는 것.
그래서 적절한 풀 크기는 “애플리케이션에서 동시에 발생 가능한 I/O 바운드 호출 수”와 “상대 서버가 허용할 수 있는 동시 연결 수” 사이에서 결정해야 한다.
보통은 CPU 코어 수보다 약간 큰 단위에서 시작해서, 피크 타임의 p95, p99 레이턴시를 기준으로 조정하는 방식이 안전하다.
단순 평균 응답시간만 보고 튜닝하면 안 되는 이유다.
꼭 꼬리는 같이 본다.

🔐 커넥션 풀을 제대로 안 쓰면 생기는 문제

풀 없이 매번 새 연결을 맺는 방식은 낮은 트래픽일 땐 티가 안 난다.
하지만 특정 시점에 burst가 오면 증상이 한꺼번에 올라온다.
CPU는 TLS 협상 때문에 순간적으로 치솟고, SYN/ACK 수가 짧은 구간에 몰리다 보니 방화벽이나 LB 레벨에서 rate limit에 걸리는 경우도 생긴다.
그렇게 되면 애플리케이션 로그에는 단순히 “timeout”이나 “connection reset”으로만 남아서 원인을 헷갈리게 만든다.
반대로 커넥션 풀을 과하게 키워 놓으면 외부 리소스(예: DB나 인증 서버)에 동시 연결이 과다하게 유지된다.
이때는 네트워크는 멀쩡한데 상대방이 429나 503을 뿜기 시작한다.
즉 겉으로 보기엔 ‘우리 쪽 서버는 괜찮아 보이는데 전체 요청은 실패율이 올라가는’ 이상한 상황이 생긴다.

🧪 커넥션 풀 크기 초기값은 어떻게 잡을까

완벽한 공식은 없지만, 실무에서 많이 쓰는 출발선은 이런 식이다.

여기서 중요한 건 “최대 동시 연결 수”를 무조건 높게 잡는 게 아니라, 큐잉 없이 돌아갈 만큼만 확보하고 그 이상은 요청 자체를 조절(백프레셔)한다는 마인드다.
풀 튜닝은 결국 안정성 튜닝이다.
폭발적 성능을 내는 게 아니라, 폭발을 막는 쪽이라고 보면 딱 맞다.

📡 aiohttp, httpx 같은 비동기 클라이언트에서 주의할 점

비동기 환경(asyncio)에서는 커넥션 풀은 더 민감해진다.
동일 이벤트 루프 안에서 수십, 수백 개의 코루틴이 동시에 외부 요청을 날릴 수 있기 때문이다.
이 경우 풀의 최대 동시 연결 수와, 동시에 빌려갈 수 있는 소켓 수, 그리고 대기열 정책까지 확인해야 한다.
풀에 남는 소켓이 없으면 새 소켓을 만들지 기다릴지, 기다린다면 몇 초까지 기다릴지를 결정할 수 있는지 꼭 체크해야 한다.
대기열이 무제한이면 결국 “레이지 폭탄”처럼 요청이 쌓였다가 한꺼번에 터진다.

이런 이유로 실제 운영에서는 “엔드포인트별 풀” 전략도 쓴다.
외부 결제 API처럼 SLA가 중요한 곳은 별도의 세션/클라이언트를 두고, 덜 중요한 로깅/통계 전송 계열은 다른 풀을 쓴다.
이렇게 나누면 중요한 경로가 부하에 끌려 같이 죽는 걸 막을 수 있다.
즉, 커넥션 풀은 단순히 성능용이 아니라 장애 격리용 도구이기도 하다.

• 🔁HTTP keep-alive를 끄지 않고 유지되는지 확인한다. (프록시, LB에서 강제로 끊지 않는지 포함)
• 📊풀 점유율과 대기열 길이 메트릭을 별도로 본다. 평균 응답속도만 보지 않는다.
• 🚫풀을 무제한으로 키우는 식으로 타임아웃을 가리려고 하지 않는다. 그건 외부 리소스를 과부하시키는 방법일 뿐이다.
• 🧩중요 외부 API는 별도 세션(별도 풀)로 분리해 장애 전파를 막는다.

💬 커넥션 풀은 ‘얼마나 빨리 처리하느냐’보다 ‘얼마나 꾸준히 무너지지 않느냐’에 가깝다.
지속 가능한 처리량을 확보했다면 이미 반은 성공이라고 보면 된다.

# aiohttp 예시: 세션 재사용과 풀 크기 제한
import aiohttp
import asyncio

async def main():
    connector = aiohttp.TCPConnector(limit=100)  # 커넥션 풀 최대 동시 연결 수
    async with aiohttp.ClientSession(connector=connector) as session:
        # 이 세션을 반복 재사용
        async with session.get("https://api.example.com/data") as resp:
            data = await resp.json()
            print(data)

asyncio.run(main())

🌐 HTTP/2 멀티플렉싱으로 동시성 높이기

HTTP/2는 단순히 “새 버전 프로토콜”이 아니다.
파이썬 네트워크 성능을 튜닝할 때 HTTP/2는 한 번의 TCP 연결로 여러 요청을 동시에 병렬 처리할 수 있게 해주는 핵심 기술이다.
기존 HTTP/1.1에서는 한 커넥션이 하나의 요청만 처리할 수 있었기 때문에, 여러 요청을 처리하려면 커넥션을 여러 개 열어야 했다.
반면 HTTP/2는 “멀티플렉싱(multiplexing)” 기능을 통해 하나의 커넥션에서 여러 스트림을 독립적으로 주고받을 수 있다.
이 덕분에 같은 서버에 여러 리소스를 요청하는 웹 애플리케이션의 성능이 크게 향상된다.

즉, HTTP/1.1에서 10개의 연결을 열던 일을 HTTP/2에서는 1개의 연결로 가능하다.
네트워크 레벨에서는 커넥션 관리 비용이 줄고, 커널 소켓 자원 점유도 낮아지며, 지연시간도 줄어든다.
이건 특히 API 게이트웨이나 마이크로서비스 간 통신처럼 짧고 빈번한 요청이 많은 환경에서 체감이 크다.
요청이 쏟아져도 커넥션 수는 일정하게 유지되기 때문에, CPU 사용량과 스레드 오버헤드도 함께 줄어든다.

🚀 파이썬에서 HTTP/2를 활성화하는 방법

HTTP/2는 단순히 ‘서버에서 지원한다’고 끝나는 게 아니다.
파이썬 클라이언트나 프레임워크에서도 명시적으로 설정해야 한다.
예를 들어 httpx나 aiohttp에서는 별도 의존성을 설치해야 하고, FastAPI, Starlette 같은 비동기 프레임워크에서는 ASGI 서버(예: uvicorn, hypercorn)가 이를 지원해야 한다.
아래 예시는 httpx로 HTTP/2를 켜는 가장 단순한 방법이다.

import httpx

with httpx.Client(http2=True) as client:
    r = client.get("https://api.example.com/data")
    print(r.http_version)  # 'HTTP/2' 출력됨

이처럼 httpx는 HTTP/2를 옵션 하나로 쉽게 켤 수 있지만, 서버가 HTTP/2를 지원해야 실제로 활성화된다.
만약 서버가 HTTP/2를 지원하지 않으면 자동으로 1.1로 폴백된다.
따라서 반드시 curl 명령어로 실제 프로토콜 버전을 확인하는 게 좋다.

💬 curl -I –http2 https://api.example.com
명령으로 HTTP/2가 활성화되어 있는지 확인할 수 있다.

📶 멀티플렉싱의 장점과 주의점

HTTP/2의 가장 큰 장점은 ‘한 커넥션에서 여러 스트림을 처리’한다는 점이다.
이는 네트워크 효율성 면에서 탁월하지만, 반대로 모든 요청이 같은 TCP 커넥션을 공유하기 때문에 단일 커넥션 병목이 전체 요청 병목으로 이어질 수 있다는 단점도 있다.
예를 들어 대용량 응답 하나가 네트워크 버퍼를 가득 채우면, 같은 커넥션에서 나머지 요청들도 함께 지연된다.
이 문제는 ‘스트림 우선순위’ 설정으로 완화할 수 있다.

FastAPI나 Quart 같은 비동기 프레임워크에서는 hypercorn을 ASGI 서버로 설정해 HTTP/2를 쉽게 지원할 수 있다.
특히 HTTPS와 ALPN을 함께 구성하면 클라이언트가 자동으로 2.0 프로토콜을 협상한다.
실제 운영환경에서는 Nginx나 Envoy 같은 리버스 프록시를 통해 TLS 종료와 함께 HTTP/2를 처리하는 방식이 일반적이다.
이 경우 백엔드 애플리케이션은 HTTP/1.1로 통신하되, 외부 요청은 HTTP/2로 수용하는 형태로도 충분히 이점이 있다.

• 🔎curl –http2 또는 브라우저 네트워크 탭에서 실제 프로토콜 버전을 확인한다.
• 🧩FastAPI, Starlette는 hypercorn, aiohttp.web은 자체 HTTP/2 모드를 지원한다.
• ⚙️HTTP/2에서도 keep-alive, timeout 등 기본 설정은 그대로 적용된다.
• 🚫멀티플렉싱이라도 응답 크기가 큰 작업은 비동기 큐나 별도 엔드포인트로 분리한다.

🚀 Zero-copy 전송과 sendfile, uvloop

네트워크 전송에서 가장 큰 병목은 종종 코드가 아니라 메모리 복사(copy)다.
파이썬에서 파일을 클라이언트로 전송할 때 일반적인 방법은 유저 공간에서 파일을 읽고, 다시 커널로 데이터를 보낸다.
이 과정에서 CPU는 단순한 데이터 복사에 불필요하게 소모된다.
여기서 등장하는 개념이 바로 Zero-copy다.
Zero-copy는 파일 데이터를 커널 공간 내에서 바로 소켓 버퍼로 전달하기 때문에, 유저 공간으로 복사하지 않는다.
즉, 파일을 “읽지도 않고 보내는” 것처럼 동작한다.

파이썬에서는 이 기능을 sendfile() 시스템 콜을 통해 직접 사용할 수 있다.
aiohttp, FastAPI, Django 등 주요 웹 프레임워크는 내부적으로 파일 응답 시 sendfile을 자동으로 사용한다.
그 결과, 대형 파일을 서빙할 때 CPU 부하가 현저히 낮아지고, I/O 대기 시간도 줄어든다.
특히 동영상, 이미지, 로그 파일 다운로드 서비스 등에서 큰 효과를 볼 수 있다.

💡 sendfile로 CPU 복사 비용 줄이기

일반적인 파일 전송 코드는 다음과 같이 유저 공간을 거친다.

# 전통적인 파일 전송 방식
with open("video.mp4", "rb") as f:
    while chunk := f.read(8192):
        sock.send(chunk)

위 방식은 파일을 읽고(`read`), 다시 보내며(`send`), 유저 공간을 계속 거친다.
반면 sendfile()을 사용하면 커널이 직접 파일을 소켓으로 보낸다.

import os

fd = os.open("video.mp4", os.O_RDONLY)
out_fd = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
out_fd.connect(("127.0.0.1", 9000))
os.sendfile(out_fd.fileno(), fd, 0, os.path.getsize("video.mp4"))

이 방식은 파일을 읽지 않고도 그대로 커널에서 네트워크로 복사된다.
CPU 사용량은 40~70%까지 줄고, 고속 네트워크 환경에서도 병목이 사라진다.
sendfile은 Nginx, HAProxy, Node.js 등 고성능 서버가 공통적으로 사용하는 메커니즘이기도 하다.

⚡ uvloop으로 이벤트 루프 가속

비동기 서버에서는 I/O 루프가 전체 성능의 절반 이상을 좌우한다.
파이썬의 기본 이벤트 루프는 안정적이지만, 순수 파이썬 구현이기 때문에 속도가 느리다.
이 부분을 획기적으로 개선하는 게 바로 uvloop이다.
uvloop은 C 기반의 libuv를 사용해 asyncio 루프를 대체하며, 실제로 네이티브 언어 수준의 속도를 낸다.
Benchmarks에 따르면 기본 asyncio보다 2~4배 빠르며, Go나 Node.js와 맞먹는 수준이다.

import asyncio
import uvloop

asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())

async def main():
    await asyncio.sleep(1)
    print("uvloop에서 동작 중")

asyncio.run(main())

uvloop은 aiohttp, FastAPI, Sanic 등과 자연스럽게 호환된다.
특히 CPU 사용률이 높은 상황에서 레이턴시 안정화가 탁월하다.
단, 일부 플랫폼(특히 Windows)에서는 아직 완전 호환이 아니기 때문에 리눅스 환경에서 사용하는 것이 권장된다.

• 🧠sendfile은 파일 서버, 로그 스트리밍, CDN 프록시 등에서 큰 효과를 낸다.
• 🚀uvloop은 asyncio 기반 애플리케이션에서 즉시 적용 가능하다. 단 두 줄이면 된다.
• ⚙️sendfile은 커널 기능이므로, Docker 컨테이너 내에서도 기본 활성화되어 있다.
• 📉Zero-copy는 CPU 부하를 줄이는 대신 커널 버퍼 메모리 사용량이 약간 늘어난다. 균형이 필요하다.

🧠 CPU 프로파일링으로 병목 찾기

파이썬 네트워크 서버가 느려졌을 때, 대부분의 개발자는 먼저 로직이나 DB 쿼리를 의심한다.
하지만 진짜 원인은 코드보다 CPU 사이클이 어디에 쓰이고 있는지에 있는 경우가 많다.
즉, 프로그램이 CPU를 ‘열심히’ 쓰는 게 아니라 ‘헛되이’ 쓰고 있는 것이다.
이때 필요한 게 바로 CPU 프로파일링이다.
단순히 성능이 느리다는 감각 대신, 어떤 함수가 얼마나 CPU를 점유하고 있는지를 수치로 보여준다.

프로파일링은 “무엇이 병목인지”를 찾는 데 목적이 있다.
예를 들어 CPU 100%를 찍고 있는 서버가 있다고 해서 무조건 나쁜 건 아니다.
CPU를 쓸 곳에 잘 쓰고 있다면 정상이다.
문제는 I/O 대기 상태에서 CPU가 놀고 있는 경우나, 불필요한 객체 생성, 문자열 처리, GC 오버헤드 등에 시간을 낭비하고 있는 경우다.
이걸 눈으로 보게 해주는 게 프로파일러다.

⚙️ cProfile과 snakeviz로 시각화하기

파이썬 표준 라이브러리에는 cProfile이라는 프로파일러가 내장되어 있다.
이 도구는 각 함수가 실행된 횟수와 실행에 소요된 총 시간, 누적 시간을 기록한다.
단순히 한두 줄 추가만 해도 전체 코드의 CPU 사용 패턴을 분석할 수 있다.

import cProfile
import pstats

def process_data():
    total = 0
    for i in range(1000000):
        total += i ** 2
    return total

with cProfile.Profile() as pr:
    process_data()

stats = pstats.Stats(pr)
stats.sort_stats(pstats.SortKey.TIME)
stats.print_stats(10)

출력 결과를 보면 어떤 함수가 CPU를 가장 오래 점유했는지 확인할 수 있다.
이 결과를 좀 더 시각적으로 보고 싶다면 snakeviz를 사용하면 된다.
단 한 줄로 브라우저에서 프로파일 결과를 플레임 그래프로 볼 수 있다.

# 설치
pip install snakeviz

# 사용
python -m cProfile -o result.prof app.py
snakeviz result.prof

💬 snakeviz를 이용하면 함수별 실행 시간을 인터랙티브한 그래프로 볼 수 있다.
CPU 사용량이 높은 부분을 직관적으로 찾는 데 큰 도움이 된다.

🧩 실서비스에서 프로파일링을 적용하는 팁

운영 서버에서 직접 프로파일링을 돌리는 건 조심해야 한다.
cProfile은 모든 함수 호출을 추적하기 때문에 성능 오버헤드가 크다.
그래서 실서비스에서는 주로 샘플링 기반 프로파일러를 사용한다.
대표적으로 py-spy와 scalene이 있다.

이런 도구들은 애플리케이션을 재시작하지 않고도 병목을 찾을 수 있어 매우 유용하다.
특히 py-spy는 Docker 컨테이너나 Kubernetes 환경에서도 쉽게 붙일 수 있다.
운영 중인 서버에서 갑자기 지연이 발생할 때, py-spy record -o profile.svg –pid PID 한 줄이면, 병목 지점을 시각적으로 확인할 수 있다.

• 📈먼저 cProfile로 전체 구조를 보고, 병목 구간을 찾는다.
• 💻운영 서버에서는 py-spy나 scalene처럼 비침습형 프로파일러를 사용한다.
• 🔍CPU 사용률뿐 아니라 ‘함수 호출 횟수’도 함께 분석해야 한다.
• 🧮프로파일링은 “최적화 전-후”를 비교할 때 가장 강력하다. 절대 한 번만 실행하지 말 것.

🧹 파이썬 GC 튜닝으로 레이턴시 줄이기

파이썬 애플리케이션을 운영하다 보면 이상하게 주기적으로 응답이 끊기거나, 레이턴시가 갑자기 치솟는 순간이 있다.
코드는 그대로인데, 일정 간격으로 지연이 생긴다면 의심해야 할 대상이 바로 Garbage Collector (GC)다.
GC는 불필요한 객체를 자동으로 정리해주는 매우 편리한 기능이지만, 실행 순간에는 모든 스레드를 멈추는 ‘Stop-the-world’ 동작을 한다.
즉, GC가 동작하는 동안 네트워크 요청 처리도 잠시 멈춘다는 뜻이다.

이런 현상을 완화하려면 단순히 “GC를 끈다”가 아니라, GC의 트리거 타이밍과 빈도를 조정해야 한다.
파이썬은 세대별(Generational) GC를 사용하며, 각 세대의 객체 수가 특정 임계값을 초과할 때만 수집을 실행한다.
즉, 임계값을 높이면 GC 호출이 줄고, 낮추면 더 자주 정리하지만 레이턴시가 자주 튄다.

⚙️ gc 모듈로 세대별 임계값 조정하기

파이썬의 gc 모듈을 사용하면, 현재 GC 설정을 확인하고 튜닝할 수 있다.
아래 예시는 기본 임계값을 조정해 GC 빈도를 줄이는 방법이다.

import gc

print("기존 GC 임계값:", gc.get_threshold())
# 기본값은 (700, 10, 10)

gc.set_threshold(1500, 15, 15)
print("조정 후 GC 임계값:", gc.get_threshold())

위 설정은 객체 생성이 많은 애플리케이션에서 GC 호출을 줄여준다.
단, 메모리 점유율이 늘어날 수 있으므로 모니터링이 필수다.
일반적으로 웹서버에서는 1세대 임계값을 1000~2000 수준으로 높여두는 것이 안정적이다.

🧩 async 환경에서는 GC 타이밍이 더 중요하다

비동기 서버(asyncio, uvloop 등)에서는 GC가 한 번 돌 때 모든 코루틴이 일시 중단된다.
즉, CPU 프로파일 상에는 “짧은 멈춤”처럼 보이지만, 실제로는 모든 요청 응답이 끊기는 순간이 존재한다.
그래서 고성능 비동기 서버에서는 명시적으로 주기적 수집을 넣거나, 특정 시점(예: 요청 처리 완료 후)에만 GC를 수행하도록 조정한다.

import asyncio, gc

async def request_handler():
    await asyncio.sleep(0.05)
    # 요청 처리 후 수동으로 GC 실행
    gc.collect()

async def main():
    for _ in range(100):
        await request_handler()

asyncio.run(main())

이처럼 명시적으로 GC를 제어하면, 비동기 루프의 레이턴시 안정성이 눈에 띄게 향상된다.
다만, 지나치게 자주 실행하면 오히려 역효과가 나므로 트래픽 패턴에 따라 간격을 조정하는 것이 좋다.

🧭 운영 환경에서의 GC 모니터링 팁

프로덕션 환경에서는 GC가 언제 얼마나 자주 도는지를 모니터링해야 한다.
이를 위해 gc.callbacks를 등록하면 GC 실행 시점마다 로깅할 수 있다.

import gc, time

def log_gc(phase, info):
    print(f"[{time.strftime('%H:%M:%S')}] GC 실행: {phase}, 수집 객체 = {info.get('collected', 0)}")

gc.callbacks.append(log_gc)

이렇게 하면 GC 주기와 수집량을 실시간으로 확인할 수 있다.
만약 특정 시점에 GC가 몰려 있다면, 메모리 할당 패턴을 다시 점검해야 한다.
특히 ORM, 캐시, 큐 라이브러리 등에서 객체가 너무 자주 생성되고 버려지는 경우가 많다.

• 📊gc.get_stats()로 세대별 수집 횟수와 소요 시간 확인
• 🔄임계값(gc.set_threshold)을 적절히 높여 빈도 줄이기
• 🧠Stop-the-world 시간은 수십 ms라도 누적되면 체감된다
• 🚀비동기 서버에서는 요청 완료 시점에 명시적으로 gc.collect() 호출

❓ 자주 묻는 질문 FAQ

🧩 실무형 파이썬 네트워킹 튜닝 정리

파이썬 서버 성능은 단순히 코드 최적화만으로 해결되지 않는다.
실제 운영 환경에서는 네트워크와 런타임 레벨의 세밀한 조정이 더 큰 영향을 미친다.
이 글에서 다룬 커넥션 재사용, HTTP/2 멀티플렉싱, Zero-copy 전송(sendfile, uvloop), CPU 프로파일링, GC 튜닝은 각각 독립적인 기술 같지만, 사실상 서로 긴밀히 연결되어 있다.

커넥션 풀을 올바르게 관리하면 네트워크 병목이 줄고, HTTP/2 멀티플렉싱은 커넥션 효율을 극대화한다.
Zero-copy는 CPU 부하를 줄이며, uvloop은 비동기 루프를 하드웨어 수준으로 가속한다.
이후 CPU 프로파일링으로 병목을 찾아 제거하고, GC 튜닝으로 예측 불가능한 지연을 제어하면 비로소 완성형 서버가 된다.
이 모든 과정은 “더 많은 요청을 처리하기 위해 서버를 늘린다” 대신 “기존 자원으로 더 효율적으로 처리한다”는 철학을 기반으로 한다.

즉, 파이썬은 느리다는 고정관념은 이제 옛말이다.
네트워크 레이어를 이해하고 튜닝한다면, 파이썬으로도 수천 TPS의 트래픽을 거뜬히 처리할 수 있다.
핵심은 올바른 설정과 측정, 그리고 꾸준한 개선이다.
성능은 ‘운’이 아니라 ‘관찰’에서 나온다.

🏷️ 관련 태그 : 파이썬성능튜닝, 네트워크최적화, 커넥션풀, HTTP2, ZeroCopy, uvloop, CPU프로파일, GC튜닝, FastAPI, aiohttp