Le même process lancé plusieurs fois ne consomme qu'une fois la mémoire du code et des RODATA. Seules les variables modifiées après le fork provoquent une duplication (copy on write). Et je ne pense pas que tu aies 50 MB de contexte par session.
De plus la gestion de sessions parallèles se fait facilement dans le même process unithread, donc tu dois juste lancer autant de process que tu as de cores pour profiter de tes quad core.

Pour MySQL, je ne vois pas en quoi il te handicape, c'est déjà un process séparé avec lequel on communique par messages, il faut juste utiliser un API asynchrone plutôt que l'API de la lib mysql.

Mais de façon générale, il est vrai que pour utiliser de façon asynchrone une librairie synchrone, on peut (doit) se permettre de lancer un thread pour exécuter la requête et renvoyer le résultat par un message vers la boucle principale. Ou de trouver/réécrire un API asynchrone de remplacement. Exemple typique: l'API POSIX de résolution DNS (gethostbyname/getaddrinfo) est synchrone. Ares, et adns sont des équivalents asynchrones indispensables seulement si on veut éviter les threads à tout prix.

Mais je ne te demande nullement de réécrire ton appli en asynchrone, donc pas besoin de chercher des arguments techniques pour ne pas le faire (car je continuerai à les démonter ).

L'asynchrone est bien trop méconnu, je continue ma propagande, mais je peux te dire qu'au boulot, tous les développeurs qui ont eu le déclic ne jurent plus que par ça.