Ça veut quand même dire que les données ne seront pas partagées entre les différentes instances du serveur. Du coup, je me suis rarement servi de cette technique. Est-ce que tu pourrais expliquer quelle genre de données tu stockes en RAM ?
Je m'en suis justement servis dans des cas ou je n'avais a coup sur qu'une seule instance du serveur (dans mon cas, serveur de jeu ou 1 partie = 1 instance de node.js).
Le jeu était pour téléphone portable, une partie durait environ 10 / 15 minutes, était multijoueurs (jusqu'à une vingtaine de joueurs par partie). Un joueur met a jour sa position environ toutes les 1 a 2 secondes. La communication entre le client et le serveur se faisait par une API HTTP plus ou moins REST, en JSON.
Au début on utilisait Django avec PostgreSQL. Ça faisait qu'a chaque fois qu'on arrivait dans une méthode qui traitait une requête d'un client, il fallait charger l'état du jeu depuis la SGDB, appliquer les changements suivant la logique de jeu sur les objets en RAM, re-sauvegarder l'état du jeu en SGDB (ce qui peut être une ou plusieurs entrée dans une ou plusieurs tables, suivant ce qui s'est passée dans le jeu).
C'était particulièrement moche et gourmand en CPU et en RAM. On aurait éventuellement pu intercaler en plus un memcache entre Django et la SGDB, mais ca n'aurait fait qu'ajouter du bordel dans l'usine a gaz.
Quand on a rationalisé le truc, on s'est rendu compte que finalement, la persistance d'une partie qui dure 15 minutes, on s'en balance. On est passe a Node.js, on fait tourner le jeu "en ram" au lieu de le faire tourner "en DB", avec une instance Node.js = une partie, et depuis on est très content. Tellement qu'on a laisse tombe l'API de polling HTTP et qu'on est passe en Websockets.
Mais donc, comme je le dis dans mon premier message, c'est pas du tout un cas de site web classique. Si je dois faire un site web, je prends Django et je suis très content, je vais plus vite qu'avec Node.js.
Mon expérience me dirait justement le contraire. Sous de fortes charges, j'avais plutôt constaté que nodejs avait tendance à leaker de la mémoire et à avoir des connexions en erreur. Est-ce que tu pourrais partager ton expérience à ce sujet ?
J'avoue je recrachais un peu la plaquette commerciale de Node.js, j'ai pas d'expérience a taille réelle sur le terrain de ce cas d'usage, mais ca me semble quand même étrange que ca leak…
[^] # Re: Mon expérience
Posté par case42 . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 4.
Je m'en suis justement servis dans des cas ou je n'avais a coup sur qu'une seule instance du serveur (dans mon cas, serveur de jeu ou 1 partie = 1 instance de node.js).
Le jeu était pour téléphone portable, une partie durait environ 10 / 15 minutes, était multijoueurs (jusqu'à une vingtaine de joueurs par partie). Un joueur met a jour sa position environ toutes les 1 a 2 secondes. La communication entre le client et le serveur se faisait par une API HTTP plus ou moins REST, en JSON.
Au début on utilisait Django avec PostgreSQL. Ça faisait qu'a chaque fois qu'on arrivait dans une méthode qui traitait une requête d'un client, il fallait charger l'état du jeu depuis la SGDB, appliquer les changements suivant la logique de jeu sur les objets en RAM, re-sauvegarder l'état du jeu en SGDB (ce qui peut être une ou plusieurs entrée dans une ou plusieurs tables, suivant ce qui s'est passée dans le jeu).
C'était particulièrement moche et gourmand en CPU et en RAM. On aurait éventuellement pu intercaler en plus un memcache entre Django et la SGDB, mais ca n'aurait fait qu'ajouter du bordel dans l'usine a gaz.
Quand on a rationalisé le truc, on s'est rendu compte que finalement, la persistance d'une partie qui dure 15 minutes, on s'en balance. On est passe a Node.js, on fait tourner le jeu "en ram" au lieu de le faire tourner "en DB", avec une instance Node.js = une partie, et depuis on est très content. Tellement qu'on a laisse tombe l'API de polling HTTP et qu'on est passe en Websockets.
Mais donc, comme je le dis dans mon premier message, c'est pas du tout un cas de site web classique. Si je dois faire un site web, je prends Django et je suis très content, je vais plus vite qu'avec Node.js.
J'avoue je recrachais un peu la plaquette commerciale de Node.js, j'ai pas d'expérience a taille réelle sur le terrain de ce cas d'usage, mais ca me semble quand même étrange que ca leak…