Forum: Rails France Rails - Conservation de l'état des objets ?

Bonjour ;

J'ai une question à poser concernant Rails. En parcourant la classe
ActionController::Routing::RouteSet , j'ai vu que le fichier de
définition des routes 'config/routes.rb' n'est rechargé que si il est
modifié depuis son dernier chargement, ceci grâce à une conservation de
la date de dernière modification via la variable d'instance
'@routes_last_modified'.

Ma grande question est celle-ci : Comment est conservé l'état de cette
variable entre chaque requêtes ? L'objet est sérialisé et mis en session
? un système de cache existe t-il ?

Je demande ça car je suis développeur PHP à la base et je n'arrive pas
bien à cerner comment rails peut conserver l'état des objets entre
chaque requêtes.

Je vous remercie par avance pour vos éclaircissement.

Bonjour ;

Personne ne sais me répondre ?

Sinon, j'aimerais aussi savoir à quoi correspond la directive de 
configuration suivante :

config.cache_classes = false

J'avoue que je ne comprend pas bien le terme de cache. Il est stipulé :

[quote]
# In the development environment your application's code is reloaded on
# every request.  This slows down response time but is perfect for 
development
# since you don't have to restart the webserver when you make code 
changes.
[/quote]

Soit, si je traduit correctement :

Dans un environnement de développement, le code de votre application est 
rechargé à chaque requête. La réponse est plus lente mais c'est parfait 
pour le développement depuis que vous n'avez plus besoin de redémarrer 
le serveur Web quand vous opérez des modifications dans le code.

Ce que je ne comprend pas, c'est la notion de cache. Ou sont conservée 
les données ? S'agit t'il d'une compilation du code source ? d'objets 
sérialisé ? Bref, je comprends pas et malheureusement, je ne trouve pas 
de doc la dessus.

Je vous serais vivement reconnaissant de m'apporter un début de réponse.

Tu confonds tout. Développe un peu et tu comprendras par toi-même ce 
système de 'mise en cache' du code source.

Le 29 juin 09 à 15:37, Laurent Declercq a écrit :

> J'avoue que je ne comprend pas bien le terme de cache. Il est  
>
> sérialisé ? Bref, je comprends pas et malheureusement, je ne trouve  
> pas
> de doc la dessus.

Il n'est pas question des données, mais simplement du cache. En effet,
au lieu qu'à chaque requête ton code soit "modifié" par Rails, il est
"modifié" la première fois et ne bougera plus. Ce qui implique que si
tu modifies ton code il n'y aura aucune modification de celui-ci sans
redémarrage de ton serveur. De même, il y a un chargement de la classe
très tôt ce qui entraîne un démarrage de ton serveur plus lent.

--
Cyril Mougel
http://blog.shingara.fr

2009/6/29 Laurent Declercq <list-incoming@andreas-s.net>

> J'avoue que je ne comprend pas bien le terme de cache. Il est stipulé :
>
>
Chaque fichier est simplement lu et interprété. Les classes ainsi 
définies
sont stockées sous forme compilées au sein de l'interpreteur ruby.
Normalement et en production, Rails charge à la demande les fichiers (si 
un
bout de code référence la classe Toto, il va charger le fichier toto.rb,
mais pas avant). Une fois ce chargement fait, la version interprétée de
cette classe reste en mémoire dans le process ruby qui tourne.

Par contre, en dev, les routes sont recalculées et l'ensemble des 
classes
filles de ActiveRecord::Base sont reloadées : cela implique de retirer 
les
variables d'instances et de supprimer les méthodes d'instance. Les 2 
seront
alors ré-interprétées si un bout de code y fait référence.

--
http://fabien.jakimowicz.com

Je dirais même plus...

Si tu pose cette question c'est sans doute que tu n'a pas vraiment 
acquis la
notion de langage interprété.

Ruby te (se ?) permet des acrobaties du genre typage dynamique :
truc = 'machin'
> 'machin'
truc = 3
> 3
Ou méta-programmation :
class Toto
  3.times do |i|
    define_method "blah_#{i}" do
      i
    end
  end
end
Toto.new.blah_1
> 1
Toto.new.blah_2
> 2
Toto.new.blah_3
> 3
Du coup, les définitions de classe, les inclusions de modules, etc., 
tout ça
est fait "à la volée" par ton serveur, et à un coût en terme de
performances. Selon que tu lance ton serveur en environnement de :

   - développement => a chaque requête, on reconstruit les classes et 
les
   méthodes, ça coûte cher en performances, mais on s'en fout tu es chez 
toi
   sur ta machine de développement et il n'y a pas des centaines de 
pékins
   connectés
   - production => on le fait une fois pour toute une fois par instance 
du
   serveur, ça coûte juste à la première requête, après tes centaines de 
pékins
   utilisent tous les classes déjà faites de l'instance

Mais aussi, ça a des conséquences sur le fonctionnement de l'appli :

   - développement => a chaque requête, ton serveur utilise la toute
   dernière modification que tu as fait dans ton appli puisqu'il relit 
tout
   - production => si tu change quelque chose dans l'appli (dans le code 
de
   l'appli, pas dans les données de la base) tu dois redémarrer les 
instances
   si tu veux voir un changement cohérent

Voilà, j'espère que c'est plus clair comme ça.

Michel Belleville

[quote]
Tu confonds tout. Développe un peu et tu comprendras par toi-même ce
système de 'mise en cache' du code source.
[quote]

Non, il y a simplement que je viens du monde PHP et que dans PHP, ce qui 
est expliqué ci-dessous par les autres intervenants n'est pas possible 
par défaut.

[quote]
Chaque fichier est simplement lu et interprété. Les classes ainsi
définies sont stockées sous forme compilées au sein de l'interpreteur 
ruby.
[/quote]

En effet, si j'ai bien compris, les instances de classes (en mode 
production) sont donc conservée en mémoire (processus ruby). Sauf qu'en 
PHP, tu peux toujours courir pour obtenir un comportement similaire. Le 
code doit être ré-interprété et les classes reconstruites à chaque 
requêtes sauf à utiliser un module spécifique qui n'est pas disponible 
chez tous les hébergeurs.

Sinon, ce comportement est aussi valable quand on couple rails à apache 
via l'interface fcgi ?

Enfin, en ce qui concerne la notion de langage interprété, j'ai très 
bien compris. Sauf que sous PHP, rien n'est conservé en mémoire d'où mes 
questions...

Je vous remercie pour vos réponses.

> Sauf que sous PHP, rien n'est conservé en mémoire d'où mes
> questions...


Peut-etre existe-t-il des frameworks PHP permettant de mettre en cache 
les
objets et ainsi éviter de les recalculer à chaque nouvelle page ?

gUI

--
Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/

Guillaume Betous a écrit :
>
>     Sauf que sous PHP, rien n'est conservé en mémoire d'où mes
>     questions...
>
>
> Peut-etre existe-t-il des frameworks PHP permettant de mettre en cache
> les objets et ainsi éviter de les recalculer à chaque nouvelle page ?
>
> gUI
>
Il y a bien des modules pour faire cela comme APC, mais qui sont bien
malheureusement peu présent sur les installations standards ou les
serveurs mutualisés.