2010-02-16 7 views
4

Ceci est fait en utilisant Fluent NHibernateNHibernate prend beaucoup de temps pour exécuter la requête

J'ai une recherche NHibernate qui est en train de récupérer des données d'une table. Si je prends le sql généré et l'exécute à travers l'analyseur de requête, cela prend ~ 18ms pour fonctionner. En utilisant NHProfiler, j'obtiens la durée de cette requête comme ~ 1800ms - 100 fois plus long que sql!

Query duration 
- Database only:1800ms 
- Total: 1806ms 

L'objet qui est peuplé contient une classe enfant, mais cet enfant est chargé à partir du cache de niveau 2 NHibernate

Les données qui est retourné est paginée (50 par requête), bien que dans la mesure comme je peux le dire, cela ne devrait pas faire de différence

J'ai aussi un compte en cours d'exécution, et encore une fois, cela prend ~ 4ms dans l'analyseur de requête et ~ 1800ms selon NHProfiler.

NH Profiler affiche la requête temps d'exécution, ou le temps complet pour récupérer, la carte des classes et construire le graphe d'objet? Et si c'est le premier - pourquoi cela prend-il tellement plus de temps que d'exécuter la requête directement?

EDIT: Juste trouvé ce post par Ayende sur la valeur Durée requête donnée dans NH Profiler: http://ayende.com/Blog/archive/2009/06/28/nh-prof-query-duration.aspx - il est donc certainement la requête de la base de données qui prend beaucoup de temps

+0

Combien de temps cela prend-il avec ADO.NET? –

+0

Quel est le principal goulot d'étranglement lorsque vous profilez le code avec un profileur comme les fourmis ou les dottraces? – Paco

+0

L'utilisation d'ADO.NET prend une fraction du temps que fait NHibernate. Je n'ai pas de logiciel de profilage installé pour le moment, donc je vais juste obtenir ce tri et voir ce qu'il dit –

Répondre

8

Enfin réussi à localiser le problème.

La clé primaire de l'objet est un varchar dans la base de données. NHibernate convertissait la valeur en nvarchar lors de l'exécution de la requête. Malheureusement, ce n'était pas évident en regardant le sql généré dans NH Profiler. Le ralentissement a été causé par sql conversion du nvarchar retour à un varchar

J'ai spécifié le mappage d'utiliser un type personnalisé

map.Id(x => x.Id).CustomType("AnsiString"); 

et le problème est résolu

Vive toute l'aide des personnes :)

+0

Cela m'a aidé beaucoup de temps aujourd'hui. –

+0

J'ai rencontré le même problème, cela m'a beaucoup aidé. –

1

En général, ces problèmes résoudre au réseau entre vous et votre base de données. QA se connecte généralement directement à la base de données et tout ce qu'il a à envoyer est les données brutes à l'endroit où il est formaté. Votre application convertit probablement votre ensemble de résultats en un ensemble de données ou une construction similaire. Pour le prouver, changez un peu de code (pas toute la couche de données) pour utiliser un lecteur de données SQL pour lire vos données. Il suffit de lire tous les enregistrements sans essayer d'analyser toutes les colonnes et enregistrer les données. Il fonctionnera probablement aussi vite que votre réseau le laissera.

+0

Je viens d'exécuter la requête exacte que NHibernate génère en utilisant un lecteur de données, et le temps d'exécution total est juste supérieur à 1ms, donc, malheureusement, il ne semble pas être un problème de latence réseau –

+0

c'est mon point ... maintenant, essayez de lire vos données et d'extraire chaque colonne dans votre "conteneur de ligne" quel que soit ce. Vous verrez probablement un ralentissement. –

+0

Je viens de ré-exécuter ceci pour vérifier, et créer la connexion, exécuter la requête (je fais cela par rapport au simple compte pour le rendre aussi facile que possible) et lire les données prend un peu plus d'une milliseconde. –

Questions connexes