2010-11-10 33 views

Répondre

8

Il existe des différences significatives entre les modes de fonctionnement "développement" et "production" même si les deux semblent superficiellement similaires. En mode développement, tout fichier app/ et config/routes.rb est rechargé à chaque requête. Cela peut prendre beaucoup de temps à traiter, mais présente l'avantage de produire une réponse à jour basée sur les modifications apportées à votre base de code, ce qui est probablement en cours dans un environnement de développement. Étant donné que l'environnement de production ne doit pas changer entre les déploiements, Rails mettra en cache vos contrôleurs, vues, itinéraires, aides et modèles pour optimiser les performances. Toute modification de la source nécessitera un redémarrage de l'application.

Une autre caractéristique du développement est que le niveau de journalisation Rails est défini sur debug qui est aussi détaillé que possible. Non seulement vous obtenez une ventilation détaillée de tous les appels SQL, mais vous obtenez également des avertissements mineurs et d'autres messages informatifs qui seraient sinon omis en production. Cette journalisation ralentit considérablement les performances et ne doit pas être utilisée dans un environnement de production, sauf si vous tentez de diagnostiquer un problème. Ces fichiers journaux deviennent très volumineux très rapidement et il peut être difficile de les faire pivoter sans redémarrer les processus de votre serveur Web.

Il existe également une méthode dans l'environnement de développement pour récupérer des exceptions et les rendre sous la forme d'un rapport d'erreur lisible par un humain. Ceci est utile pour le débogage, mais dans un environnement de production, il peut exposer des détails sensibles concernant votre application, car il contient souvent de nombreuses informations sur le système de fichiers, les paramètres clés, etc. Cela ne devrait jamais être activé sur un site de production.

Ces différences peuvent ne pas être évidentes, mais vous devez simplement comparer les paramètres de configuration dans config/environments/development.rb et config/environments/production.rb. Malheureusement, il n'est pas évident de savoir quelles sont les valeurs par défaut, car elles ne sont pas clairement exprimées dans ces fichiers, mais les bases sont généralement là.

+0

Parfait! Maintenant, si je voulais activer le mode de débogage pendant la production, puis-je toujours le définir sur DEBUG? – user385948

+1

Vous pouvez ajuster le niveau de journalisation dans 'production.rb' mais veillez à le désactiver lorsque vous avez terminé. Il n'est pas rare qu'il croisse à plusieurs Go par heure. – tadman

2

Mise en cache & Gestion des erreurs.

+0

Avec la mise en cache, y a-t-il une augmentation substantielle des performances? Disons que mes pages ne sont pas statiques, mais plutôt très dynamiques dans un sens, cela serait-il toujours bénéfique? – user385948

+1

Tout le code de l'application sera mis en cache entre les requêtes, il n'est donc pas nécessaire de les analyser pour chaque requête. C'est pourquoi vous pouvez apporter des modifications à un fichier et obtenir des modifications instantanées dans l'environnement de développement mais pas dans la production. Chargez l'application dans les deux environnements et comparez la sortie brique Web pour des demandes identiques, vous verrez la différence dans le temps d'exécution. –

5

Dans l'environnement de production Rails, le code de votre application est mis en cache, de sorte que l'interpréteur n'a pas besoin de recharger vos classes chaque fois qu'il appelle une méthode. Votre application est essentiellement stockée en mémoire. Cela donne des améliorations de vitesse définies.

De plus, la journalisation est beaucoup moins importante; Par exemple, les journaux de production ne contiennent pas tous les appels SQL, comme le font les journaux de développement.