( XMI | 2022. 01. 24., h – 14:00 )

Persze workaround-ok vannak, csak mindennek megvan a maga hatulutoje is. Eleve ott kezdodik, hogy az egesz architekturadat az alapoktol kezdve WSGI kore kell tervezned. Persze megvannak a design patternek ra (kulon api service, kulon dispatcher, kulon worker service, mindezeket rabbitmq-val osszedrotozni, majd keruloutak beepitese a get-ek gyors kiszolgalasara, majd az igy fellepo konkurenciaproblemakra tovabbi hack-ek beepitese stb). Alapbol egy workaroundra fejlesztesz.

WSGI is addig jo, amig max 10-20 szimultan kerest kell kiszolgalnod. 100+ kornyeken meg csak pislogunk mint macska a padon, hogy miert kell 128GB ram...

Memoria a py-nal nem szokott gond lenni - ha folyton ujrainditgatod a kiszolgalo processzeket. Tud mar esetleg valamelyik python runtime vissza is adni felszabaditott memoriat az oprendszernek?

JIT - a standard cpython ilyet nem tud. Van 1-2 alternativ python runtime (pyston, pypy), ami mondjuk 2x gyorsabb a cpython-nal. Amivel ki vagy segitve...  Raadasul 3-4 eve mikor ezzel foglalkoztam, sajnos nem minden python lib mukodott siman alternativ futtattokkal, ugyhogy nem igazan volt a cpython-nak valodi alternativaja.