Méretezés

Alapértelmezés szerint az IntraCord API-tároló egyetlen uvicorn-munkavégzőt futtat. Éles forgalom esetén – különösen sok egyidejű hanghívás (hosszú élettartamú WebSocket) esetén – több dolgozóra lesz szüksége. Az IntraCord ehhez beépített támogatással érkezik: az nginx terheléselosztja N független uvicorn folyamatot a least_conn stratégia használatával.

Ez az oldal bemutatja, hogyan működik a több dolgozós beállítás, hogyan válasszuk ki a dolgozók számát a telepítéskor, és hogyan módosítsuk azt futó stackben.

!

A több munkás támogatásához IntraCord v1.29.0 vagy újabb szükséges. A korábbi kiadások uvicorn --workers-t és más távoli üzembe helyezési elrendezést használtak. Ha a stack régebbi, először frissítse, majd térjen vissza erre az oldalra.

Hogyan működik

Az API konténer FASTAPI_WORKERS különálló uvicorn folyamatokat indít el, amelyek mindegyike a saját portjához van kötve (8000, 8001, 8002, …). Az nginx egyetlen upstream IntraCord_api-t tesz közzé, amely magában foglalja az összes dolgozói portot, és arra irányítja az új kéréseket, amelyik jelenleg a legkevesebb aktív kapcsolattal rendelkezik.

                       ┌───────────────────────────────────┐
                       │ api container                     │
                       │  uvicorn worker 0  → :8000        │
 browser ──► nginx ──► │  uvicorn worker 1  → :8001        │
   (443)    (least_conn)  uvicorn worker 2  → :8002        │
                       │  uvicorn worker 3  → :8003        │
                       └───────────────────────────────────┘

i

Ez szándékosan nem uvicorn --workers N (a beépített pre-fork mód). A pre-fork segítségével a Linux kernel a accept()-n keresztül osztja el az új TCP-kapcsolatokat a dolgozók között – ez jó a rövid HTTP-kéréseknél, de a hosszú élettartamú WebSocket-ek ragaszkodnak ahhoz a munkához, amelyik először elfogadta őket. Egy maroknyi szerencsétlen dolgozó kezeli a streaming forgalom nagy részét, míg a többiek tétlenül állnak. Az nginx rétegben a least_conn-vel végzett útválasztás ismeri a dolgozónkénti kapcsolatok tényleges számát, és egyenletesen osztja el a WebSocketeket.

Az API-tárolón belüli ari_manager és campaign_orchestrator folyamatok egyesek maradnak, függetlenül a FASTAPI_WORKERS-től – koordinálják a globális állapotot (Csillag csatornák, kampányütemezés), és nem szabad duplikálni őket. Az ARQ háttérmunkásait külön a ARQ_WORKERS vezérli.

A dolgozók számának kiválasztása

A biztonságos kiindulási pont egy dolgozó minden rendelkezésre álló vCPU-nként, legfeljebb 8, hacsak nem profilozta a munkaterhelését. A Remote Server Deployment előfeltételei legalább 4 vCPU-t igényel, tehát:

vCPU-k	Javasolt FASTAPI_WORKERS
4	4
8	6–8
16+	profil első

Minden dolgozó saját Python-folyamattal és memóriával rendelkezik – a költségvetés körülbelül 300–500 MB RAM dolgozónként a postgres/redis/minio többletköltségen felül. Ha közel jár a 8 GB RAM minimumához, és OOM-okat lát, csökkentse a dolgozók számát, mielőtt továbbiakat adna hozzá.

A dolgozók számának beállítása a telepítéskor

A setup_remote.sh kéri a dolgozók számát a másik konfiguráció mellett:

Number of FastAPI workers (uvicorn processes nginx will load-balance):
[4]:

Nyomja meg az Entert az alapértelmezett értékhez (4), vagy írjon be egy másik pozitív egész számot. A nem interaktív hívók (cloud-init, CI, Terraform) ehelyett környezeti változón keresztül állíthatják be az értéket:

sudo SERVER_IP=... TURN_SECRET=... FASTAPI_WORKERS=8 ./setup_remote.sh

A szkript az értéket .env (FASTAPI_WORKERS=N) formában tárolja. A támogatott indítási útvonal (./remote_up.sh) minden távoli indítás előtt előfutja a IntraCord-init renderelést ettől az értéktől, így az nginx és az API-munkások száma összhangban marad.

A dolgozók számának módosítása futó stackben

Ha az IntraCord fut, a dolgozók számának növelése vagy csökkentése egy fájl szerkesztése és újraindítása. Módosítsa a .env elemet, majd kezdje el a ./remote_up.sh-vel, így a IntraCord-init újragenerálja az nginx futásidejű konfigurációját, mielőtt a Docker elindítja a stacket.

Lépések

Minden parancs a IntraCord/ könyvtárából fut (a docker-compose.yaml-vel rendelkező könyvtárból).

1. A .env szerkesztése és a FASTAPI_WORKERS sor módosítása:

# Before
FASTAPI_WORKERS=4

# After
FASTAPI_WORKERS=8

2. Hozza létre újra a stacket az ellenőrzött wrapper scripttel. A legegyszerűbb út – rövid állásidő, meglepetések nélkül:

./remote_up.sh

Ha el szeretné kerülni az állásidőt, és a stack egészséges, csak a api és nginx konténereket hozhatja újra:

./remote_up.sh -- api nginx

A remote_up.sh ellenőrzi a .env-t, ugyanazt a IntraCord-init renderelést futtatja, amelyet a Compose az indításkor használ, futtatja a docker compose config -q fájlt, majd elindítja a kért szolgáltatásokat.

3. Ellenőrizze. Győződjön meg arról, hogy a megfelelő számú uvicorn folyamat fut. Az API-kép vékony, és nem tartalmazza a ps-t, ezért használja inkább a Docker gazdagépoldali nézetét:

sudo docker compose --profile remote top api | grep uvicorn

Dolgozónként egy sort kell látnia. A kötött portok megerősítéséhez ellenőrizze az indítási naplókat – minden dolgozó naplóz egy Uvicorn running on http://0.0.0.0:800X sort a rendszerindításkor:

sudo docker compose --profile remote logs api | grep "Uvicorn running"

Ezután nyomja meg az API-t az nginx-en keresztül, hogy megbizonyosodjon arról, hogy a kérések továbbra is folynak:

curl -k https://YOUR_SERVER_IP/api/v1/health

Miért nem futja újra a setup_remote.sh-t?

A setup_remote.sh nem hajlandó felülírni egy meglévő telepítést – az újbóli futtatása újragenerálja a OSS_JWT_SECRET-t (mindenki kijelentkezése), visszaállítja a TURN megosztott titkát (megtöri a WebRTC hitelesítést a csatlakoztatott klienseken), és újragenerálja az SSL-tanúsítványokat. A fenti kétfájlos szerkesztés a támogatott módja a dolgozók számának telepítés utáni módosításának.

Ha valóban tiszta újratelepítést szeretne, tekintse meg a szkriptben dokumentált IntraCord_FORCE_OVERWRITE=1 menekülési nyílást.

Amit ez nem skáláz

A többmunkás mód méretezi a HTTP/WebSocket API felületet. nem skálázza:

• ARQ háttérmunkások — a ARQ_WORKERS vezérli (alapértelmezett: 1). Növelje ezt az API-tároló környezetében, ha a háttérfeladatsor biztonsági másolatot készít.
• ari_manager / campaign_orchestrator — egyszemélyes kivitel; nem profitálnak az extra folyamatokból.
• Postgres, Redis, MinIO – mindegyik egyetlen tárolóként fut a stackben. A termelési léptékű Postgres esetében egy felügyelt szolgáltatást kell futtatnia, és rá kell mutatnia a DATABASE_URL-re; ugyanez vonatkozik a Redis és S3-kompatibilis tárolókra is.

A többgépes vízszintes skálázáshoz — amikor külön API-konténerek futnak több gépen — lásd az Egyéni domain útmutató több gép elé helyezett terheléselosztó mintáját. Ez ugyanaz az elv, mint a konténeren belüli least_conn upstream, csak egy réteggel feljebb.