la doctrine semble prendre bien plus de 4 Mo de RAM pour exécuter une seule requête simple: ceci est sur une base de données de test avec très peu de données dedans - l'élément que je suis Interrogation ne contient aucune donnée autre que ce qui est affiché ici. existe-t-il potentiellement quelque chose qui ne va pas dans la manière dont j'ai le système mis en place ou cette utilisation de la mémoire standard pour la doctrine? < / p>
7 Réponses :
De ce que je peux voir, vous ne semble pas être faux ...
Voici le code correspondant: p>
En tant que test, j'ai mis en place un exemple rapide, avec une table très simple (seulement quatre champs) em>. P> string '1,316,424' (length=9)
string '2,107,128' (length=9)
Cela m'inquiète, comme je m'intègre la doctrine dans mon cadre.
Avant de vous inquiéter trop, vous voudrez peut-être effectuer des tests supplémentaires, avec de plus grandes tables, plus de données et tout cela - pour voir si l'augmentation de la mémoire est linéaire ou non. ;; BTW: J'ai vu la doctrine Utiliser dans des projets basés sur Zend Framework et Symfony, et cela n'a jamais été un problème ...
Pascal Martin: Peut-être que ces sites que vous savez n'ont pas de lourdes charges? J'aimerais savoir si des sites majeurs utilisent la doctrine.
Je verrouille généralement de nouveaux projets à une limite de mémoire définie de 16 Mo. À une exception près, je n'ai jamais épuisé cette limite avec la doctrine. En outre, il y a une tonne de variables et singletons intra-référencés qui sont lancés lorsque la doctrine est utilisée pour la première fois.
Le lien pour la documentation 1.2 peut désormais être trouvé à Readthedocs .Org / Docs / Doctrine / FR / DERNIER / EN / MANUEL / ...
Eh bien, d'où vient cette utilisation de la mémoire? Comme le soulignait Pascal Martin, l'hydratation du tableau ne fait pas une grande différence qui est logique concernant que nous ne parlons que de quelques archives ici.
La consommation de mémoire provient de toutes les classes chargées à la demande via l'autoloading.
Si vous n'avez pas d'APC configuré, alors oui, il y a quelque chose qui ne va pas dans la manière dont votre système est configuré. Ne commencez même pas à mesurer la performance et attendez-vous à de bons résultats avec une grande bibliothèque PHP sans cache d'opcode comme APC. Il ne accélérera pas seulement l'exécution, mais réduira également l'utilisation de la mémoire d'au moins 50% sur toutes les charges de la page, à l'exception de la toute première (où APC doit mettre en cache le byTecodes en premier).
et 4 Mo avec votre exemple simple sent vraiment le no-apc, sinon ce serait vraiment un peu élevé.
Je suis d'accord avec la réponse de Romanb - à l'aide d'un cache OPCODE est un must défini lors de l'utilisation de grandes libs / frameworks.
J'ai récemment adopté l'utilisation de la doctrine avec Zend Cadre et a été curieuse sur l'utilisation de la mémoire - Donc, comme l'OP, j'ai créé une méthode utilisant Des critères similaires au test OPS et le couragent comme un test global pour savoir ce que l'utilisation de la mémoire maximale de ZF + Doctrine serait. p> J'ai eu les résultats suivants: p> résultat sans APC: p> résultat avec APC: p> 3 megabytes
RV David
4.25 megabytes
Doctrine fournit une fonction gratuite () sur doctrine_record, doctrine_collection et doctrine_query, qui élimine les références circulaires de ces objets, libérant-les pour la collecte des ordures. Plus d'infos ..
Pour effectuer une utilisation de la mémoire un peu moins, vous pouvez essayer d'utiliser le code de follage:
Je devinerais que la majeure partie de cette mémoire est utilisée en chargement de classes de la doctrine, et non pour des objets associés à la requête elle-même.
Dans la doctrine 1.1, le comportement de l'autoload par défaut s'appelle «agressif», ce qui signifie qu'elle charge toutes vos classes de modèle, même si vous n'utilisez qu'un ou deux sur une requête particulière. Définir ce comportement à «conservateur» réduirait l'utilisation de la mémoire.
Je viens de faire un script "démonisé" avec symfony 1.4 et de régler les suivants ont arrêté la mémoire HOGGER:
sfConfig::set('sf_debug', false);
C'est bon à faire si vous utilisez Doctrine + Symfony, mais vous ne vous aiderez pas si vous utilisez simplement la doctrine.
Accepter avec Ikon, en symfony, le profileur Gobals Ram. Donc: sfconfig :: set ("sf_debug ', false); avant La connexion de la base de données est faite aidera considérablement espacilleusement si, comme moi, vous dévoilez de grandes tables de grande taille à CSV . Vous voudrez peut-être faire cela dans frontend_dev.php ou similaire (3ème param).
Attention avec Fetchone () sur la requête de la doctrine. Cet appel de fonction n'apportera pas "Limite 1" sur SQL
si vous devez simplement obtenir un enregistrement de DB, assurez-vous: P>
public function fetchOne($params = array(), $hydrationMode = null)
{
$collection = $this->execute($params, $hydrationMode);
if (is_scalar($collection)) {
return $collection;
}
if (count($collection) === 0) {
return false;
}
if ($collection instanceof Doctrine_Collection) {
return $collection->getFirst();
} else if (is_array($collection)) {
return array_shift($collection);
}
return false;
}