JeuWeb - Crée ton jeu par navigateur
Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Travailler uniquement en RAM avec php et/ou ruby, c'est possible? (/showthread.php?tid=6723)

Pages : 1 2


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Xenos - 20-03-2013

En RAM ou en pas RAM, ce sera alors pareil, les effets seront cumulés aussi.

En RAM, l'équivalent de sélect, c'est une ligne de type
Code :
$objet->getvaleur()
Le select serait
Code :
$objet->setvaleur(...)
Le update
Code :
$objet.valeur+=tru

En BDD, tu as le problème de collision si tu fais:
Code :
SELECT ...
<actions sur la valeur sélectionnée>
UPDATE...

En RAM, tu auras exactement le même problème si tu fais
Code :
var $valeur=$objet.getValeur();
<actions sur la valeur>
$objet.setvaleur($resultat);

Pour ne pas avoir ce soucis, en RAM, il te faudra faire des opérations atomiques:

Code :
$objet.valeur+=50; ///Ca, ok

Ce qui revient au même que faire une opération atomique en BDD.

Le seul avantage de la RAM, c'est que les calculs sont plus rapides, donc tu vas réduire les risques de collision, mais pas supprimer ce risque. C'zest ennuyeux de faire attendre les autres scripts par exclusion mutuelle, c'est vrai, mais c'est la seule solution fiable.


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - niahoo - 20-03-2013

C'est pas ennuyeux du tout. Si tu travailles en mémoire et que tu ne sauvegardes pas à chaque fois, ton programme ira 10 fois plus vite que s'il s'appuyait sur la DB comme unique stockage. Donc en fait tu gagnes un temps considérable.


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Xenos - 20-03-2013

Je n'ai jamais dit que c'était un problème de vitesse.
Oui, en RAM, ca va vite, c'est un atout, ca j'ai rien à dire là dessus, et la question est pertinente si on souhaite "faire plus vite".
Non, la RAM ne permet pas d'assurer que deux programmes concurrents (ou processus) vont travailler avec la même donnée synchrone.


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - niahoo - 20-03-2013




RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Argorate - 20-03-2013

Xenos: Oui, c'est pour ça que j'ai dis dans mon premier post que ça ne règle pas vraiment le problème, mais c'est comme ci car bcp mieux qu'avec une bdd, puisque modifier des valeurs sur un objets direct en RAM prend extrêmement moins de temps qu'un accès en écriture au disque (bdd), et donc réduit les collisions de manière drastique, même si dans l'absolue ça ne règle pas le problème et que ça peut tjs arrivé, mais réduire la fréquence du problème de manière aussi efficace est déjà un très bon point...

niahoo: pourquoi les scripts gagnent du temps à attendre qu'un autre est fini? j'ai un peu de mal avec cette logique^^


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - niahoo - 20-03-2013

Je l'ai dit : parce que en contrepartie tu ne fais pas d'IPC et donc ton script va bien plus vite. Si tu économises le temps de faire 1 SELECT et 1 UPDATE, soit X millisecondes, tu peux, avec ces X millisecondes, mettre à jour ta variable plein de fois. (tu viens de le dire en plus : pas d'accès disque, pas d'IPC, ça va bcp + vite)

Oui parce que la base de données n'est pas concurrente : tu ne peux pas écrire simultanément plusieurs informations différentes dans la même ligne de la même table. En fait, actuellement tes scripts font déjà la queue. Le seul problème vient de leur SELECT.


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Xenos - 20-03-2013

Alors, dans ce cas d'accord, Argorate.
Si tu avais voulu faire au meilleur compromis, je t'aurai plutôt conseillé BDD avec une table "MEMORY", sur laquelle tu utilises des COMMIT.
Mais effectivement, si tu veux que "faire vite" pour essayer d'éviter le problème, la RAM est adaptée, mais pas PHP.


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - niahoo - 20-03-2013

Je comprends pas trop votre discussion, les deux là. Les tables "MEMORY" c'est justement de la RAM donc bon c'est déjà pas mal .. (mais ça reste de l'IPC).


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Xenos - 20-03-2013

(20-03-2013, 03:39 PM)niahoo a écrit : Je comprends pas trop votre discussion, les deux là. Les tables "MEMORY" c'est justement de la RAM donc bon c'est déjà pas mal .. (mais ça reste de l'IPC).

Justement, c'est un bon compromis performances/exclusion mutuelle:
- MEMORY est rapide, car en mémoire RAM (donc, "c'est pas mal mais ca reste de l'IPC")
- MySQL permet les commits, ce qui assurent l'exclusion mutuelle

Mais si argorate cherche la parf' pure de la RAM, il faut lâcher PHP, car je ne crois pas qu'il soit adapté à ce genre de demande.


RE: Travailler uniquement en RAM avec php et/ou ruby, c'est possible? - Argorate - 21-03-2013

pour le php tant pis, je pense que je vais tenter des vérifs pour éviter les pb de concurrence avant le save() et voilà...