Cyril M. wrote:
Le 25 juin 09 � 10:49, Sylvain D. a �crit :
Le select * de la table se fait au bout de 4s
le select / update user + groupe se fait 2s apr�s
Puis il ne se passe ‘rien’ (rien dans les logs) pendant 9s jusqu’�
l’affichage dans les logs de “Processing
AspenTopoFilesController#index”
qui me dit
“Completed in 1140ms (View: 131, DB: 2071)”
Vu le temps de r�ponse de ta requ�te, il doit y avoir un nombre de
ligne incroyable. Sachant que pour chaque ligne 1 objet est cr�er. Ca
peux expliquer le temps de cr�ation des objets apr�s lecture de ta BDD.
–
Cyril M.
http://blog.shingara.fr
“DB: 2071” veut dire 2071 objets récupérés ?
parce qu’il y en a 11 objets à récupérer dans le select * et un objet Ã
chaque fois…
Fabien J. wrote:
Pas vraiment concluant, essaie rack-bug. C’est moins complexe Ã
utiliser et ca devrait tourner sur ton env de dev.
Super ton outil !
Je crois avoir trouvé mon problème :
Active Scaffold stocke pas mal de chose dans les sessions et et donc je
mets 3,5s à remonter les sessions (je les stocke dans la base)
Je vais voir comment améliorer ça
Salut,
Ben j’aimerais bien mais je la vois pas la boucle 
Ca existe pas un outil qui donne le chemin par ou on passe ?
TuneUp peut aider à comprendre ce qui se passe dans ce genre de cas:
http://www.fiveruns.com/products/tuneup
Très simple à utiliser et bien intégré à Rails. Supporte Merb
également.
Thibaut
http://www.blog.logeek.fr
Sylvain D. wrote:
Fabien J. wrote:
Pas vraiment concluant, essaie rack-bug. C’est moins complexe Ã
utiliser et ca devrait tourner sur ton env de dev.
Super ton outil !
Je crois avoir trouvé mon problème :
Active Scaffold stocke pas mal de chose dans les sessions et et donc je
mets 3,5s à remonter les sessions (je les stocke dans la base)
Je vais voir comment améliorer ça
Je suis passé à mem_cache pour la sauvegarde des sessions et ça a bien
amélioré les choses (je consomme 10x moins de mémoire…) !
Merci à tous pour votre aide et vos commentaires !
2009/6/26 Sylvain D. [email protected]:
Je vais voir comment améliorer ça
Je suis passé à mem_cache pour la sauvegarde des sessions et ça a bien
amélioré les choses (je consomme 10x moins de mémoire…) !
Merci à tous pour votre aide et vos commentaires !
Petite note: si tu utilise des tests fonctionnels ou d’intégration, tu
risques d’avoir des erreurs si tes sessions sont trop chargées. Par
défaut, ces tests vont utiliser les sessions en cookie.
–
http://fabien.jakimowicz.com
2009/6/25 Sylvain D. [email protected]
%self total self wait child calls name
Pathname#initialize
Pas vraiment concluant, essaie rack-bug. C’est moins complexe Ã
utiliser et ca devrait tourner sur ton env de dev.
–
http://fabien.jakimowicz.com
Fabien J. wrote:
2009/6/26 Sylvain D. [email protected]:
Je vais voir comment am�liorer �a
Je suis pass� � mem_cache pour la sauvegarde des sessions et �a a bien
am�lior� les choses (je consomme 10x moins de m�moire…) !
Merci � tous pour votre aide et vos commentaires !
Petite note: si tu utilise des tests fonctionnels ou d’int�gration, tu
risques d’avoir des erreurs si tes sessions sont trop charg�es. Par
d�faut, ces tests vont utiliser les sessions en cookie.
–
http://fabien.jakimowicz.com
Ah tiens merci,
j’avoue que j’ai pas fait de tests d’intégration (oui je sais c’est pas
bien) car ce programme n’est pas destiné à être pérenne