NHibernate très lent [Résolu]

[diplomegalo]

Bonjour à tous

Le context : je voudrais créer un DLL spécialiser dans l'accés aux données d'une DB Oracle :

DBConnectionManager :

• ConnectionManager : Class qui se charge de créer une connection vers la base oracle (DbConnection)
• FluentConfiguration : Class qui configure NHibernate (via Fluent NHibernate) et Singleton qui me renvoie une Session NHibernate (ISession)
• Class de mapping + entités (via Fluent NHibernate).

DataAccessLayer :

• Repository : fait appel à la session de la class que me configure NHibernate
• ContactDAO : Class spécialisé dans les transactions que je dois exécuter avec un Contact

Pour chacune des classes j'ai un projet test (NUnit) et c'est MEGA LENT quand je fais appel a une donnée... ma question est : qqu'un a t'il une idée du pourquoi ?

Si vous voyez qque chose de pas logique dans l'architecture ou que je peux mieux faire n'hésitez pas à faire des remarques. Je ne suis pas vraiment à l'aise.

Diplomegalo

[Nathanael Marchand]

Y'a des milliers de raisons pour lesquelles NHibernate peut être lent... Sans le code qui est lent, c'est dur de deviner

[diplomegalo]

Bonjour

Ok j'avais tellement de doutes que je pensais que le problème aurait pour origine l'architecture.

Etape 2 : le code. Un tout grand merci pour votre aide et bonne journée.

DBConnectionManager :

Connection + gestion de session

Code C# :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
public class FluentConfiguration
    {
        private static ISessionFactory _sessionFactory;
 
        public static ISession Session {
            get {
                if (FluentConfiguration._sessionFactory == null){
                    _sessionFactory = CreateSessionFactory();
                }
 
                return _sessionFactory.OpenSession();
            }
        }
 
        private static ISessionFactory CreateSessionFactory() {
            var cfg = OracleClientConfiguration.Oracle10
                .ConnectionString( c => c.Is(Properties.ConnectionStrings.Default.Test.ToString()));
 
            return Fluently.Configure()
                .Database(cfg)
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<Contact>())
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<Person>())
                .BuildSessionFactory();
        }
    }

Entité

Code C# :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
    public class Contact
    {
        public virtual string Id { get; private set; }
        public virtual string Firstname { get; set; }
        public virtual string Lastname { get; set; }
 
        public virtual IList<Person> Person { get; private set; }
 
 
        public Contact() {
            Person = new List<Person>();
        }        
    }

Mapping

Code C# :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class ContactMap : ClassMap<Contact>
    {
        public ContactMap()
        {
            Table("CONTACT");
 
            Id(x => x.Id, "contactid");
            Map(x => x.Firstname, "firstname");
            Map(x => x.Lastname, "lastname");
 
            HasMany(x => x.Person)
                .Not.LazyLoad()
                .KeyColumn("contactid")
                .Inverse();
        }
    }

DataAccessLayer

Repository

Code C# :

1
2
3
4
5
6
7
8
9
10
11
 
public class Repository
    {
        public static T GetById<T>(object id)
        {
            using (ISession session = DBConnectionManager.FluentConfiguration.Session)
            {
                return session.Get<T>(id);
            }
        }
    }

Test

Code C# :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
[TestFixture]
    public class RepositoryTest
    {   
        [Test]
        public void GetById_Test1() {
            Contact contact = Repository.GetById<Contact>("CCxxxxxxxx51");
            Assert.AreEqual(contact.Id, "CCxxxxxxxx51");
        }
 
        [Test]
        public void GetById_Test2() {
            Contact contact = Repository.GetById<Contact>("CCxxxxxxxx51");
            Assert.AreEqual(contact.Person[0].ContactName, "NOM, PRENOM");
            Assert.AreEqual(contact.Person[0].Contact.Id, "CCxxxxxxxx51");
        }
    }

Un tout grand merci pour votre aide et bonne journée.

[diplomegalo]

Je viens de débuger mon code. C'est le Get qui prend vraiment beaucoup de temps (plus de 10 sec).

Code C# :

return session.Get<T>(id);

Si vous avez des remarques, elles sont les bienvenues

++

[mermich]

Salut,

Tout d'abord je n'utilise pas Fluent, donc il possible/probable que je dise n'importe quoi...

Une question, dans ton code:

Code :

1
2
3
4
5
6
 
            return Fluently.Configure()
                .Database(cfg)
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<Contact>())
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<Person>())
                .BuildSessionFactory();

Tu ne spécifies pas de lifecycle ou autre chose, du coup je me pose la question, dans :

Code :

if (FluentConfiguration._sessionFactory == null){

Ce test renvoie-t-il une seule fois false ?

Car parmi les choses couteuses en nhibernate il y a le buildSessionFactory...

Bonne chance.

[diplomegalo]

Bonjour à tous

Tout d'abord merci pour votre aide et vos réponses.

En ce qui concerne la création du ISessionFactory, en effet ce test renvoie une seul fois false. J'ai pu lire dans certains articles que le ISessionFactory était très lourd lors de la création et que le ISession était utilisé comme UOW. J'articule donc mon développement autour de ces concepts.

J'ai effectué plusieurs tests à la suite l'un de l'autre et je n'économise pas vraiment de temps.

Cependant je viens de faire une découverte : lorsque j'utilise l'ICriteria pour cibler mon information dans la base, j'économise du temps. Vous me direz : "bien vu l'aveugle ! ". Oui mais quand même je passe du simple au... 60 fois plus longtemps .

Voici l'exemple :

Code C# :

1
2
3
4
 
public static int GetScoring(string contactId) {
    return Repository.GetById<Contact>(contactId).Screening.Score;
}

et avec criteria

Code C# :

1
2
3
4
5
6
7
8
 
public static int GetScoring_Criteria(string contactid) {
    using (ISession session = FluentConfiguration.Session) {
        ICriteria criteria = session.CreateCriteria<Screening>();
        IList<Screening> sc = criteria.Add(Expression.Eq("Id", contactid)).List<Screening>();
        return sc[0].Score;
    }
}

Je me dis donc que la faute doit venir du nombre d'information que je fais remonter. Je vais donc essayer de jouer avec le LazyLoad.

Je clôturerai ce topic si les résultats sont concluant avec le LazyLoad.

Encore merci pour votre aide

Bien à vous

[diplomegalo]

Bonjour à tous

Bien... je n'ai toujours pas trouvé les raisons de ces lenteurs. J'utilise le LazyLoad par défaut pour chacune de mes entités mais ça ne change rien.

Ce que je fais donc, c'est d'utiliser les criteria au lieu de la fonction GetBy. C'est pas vraiment une solution mais ça fonctionne.

Bien à vous

[iberserk]

Avez vous regardé la différence au niveau des requetes SQL qui passent sur le serveur?

[iberserk]

J'ai l'impression que vous faites deux choses différentes:

Sauf erreur de ma part( je ne connais pas super bien NH...) avec le getBy vous interrogez la base contact puis vous faites contact.screening.

Avec les criteria vous interrogez directement la table screening... cela peut faire une enorme différence...

JE vous engage à regarder les deux requêtes SQL générées

[WOLO Laurent]

Envoyé par diplomegalo

Bonjour à tous

Bien... je n'ai toujours pas trouvé les raisons de ces lenteurs. J'utilise le LazyLoad par défaut pour chacune de mes entités mais ça ne change rien.
Bien à vous

Qu'est ce que ce mode était sensé apporté ? un chargement assynchrone ?

Envoyé par diplomegalo

Bonjour à tous
Ce que je fais donc, c'est d'utiliser les criteria au lieu de la fonction GetBy. C'est pas vraiment une solution mais ça fonctionne.
Bien à vous

C'est normal, c'est l'équivalent d'un select * from sans where qui est fortement déconseillé.
Mais je soutiens la position de iberserk qui demande la comparaison des requêtes renvoyées par l'ORM.

Cordialement;

[iberserk]

un chargement assynchrone ?

Non, un chargement différé (lazy: tardif)en fait...un des quelques gros pièges des orm...

[WOLO Laurent]

Envoyé par iberserk

Non, un chargement différé (lazy: tardif)en fait...un des quelques gros pièges des orm...

De toutes les façons tu connais ma position quand à l'utilisation des ORM et le seul conseil que je peux donner ici, c'est d'essayer de filtrer au maximum les données et de faire du paging si possible. Généralement nous n'avons pas besoins de remonter plus de 1000 lignes par exemple, mais c'est vraiment à titre indicatif.

[B.AF]

La personne est un contact, qui lui même a des personnes qui sont des contacts....

C'est une erreur systèmatique !

La seule chose à faire systèmatiquement c'est de regarder le code SQL généré.

Ensuite quand on doit travailler sur des filtres et des requêtes de se poser la question des indexes et tris.

L'exemple sur le screening en est la preuvre :
Le criteria n'est pas fait sur la même entité...
Dans le cas 1; il faut initialiser le contact (et donc toutes les associations mappées)
Dans le cas 2, c'est sur l'entité recherchée avec le bon filtre.
Heureusement que 2 est plus performante que 1...

La morale de l'histoire c'est :

Code :

1
2
3
4
5
private static ISessionFactory CreateSessionFactory() {
            var cfg = OracleClientConfiguration.Oracle10
                .ConnectionString( c => c.Is(Properties.ConnectionStrings.Default.Test.ToString()))
                .ShowSql();

et d'utiliser aussi les statistiques de session pour comprendre ce qu'il se passe.

[diplomegalo]

Bonjour

Merci de vos réponses.

Envoyé par B.AF

La personne est un contact, qui lui même a des personnes qui sont des contacts....

Je voudrais juste préciser la définition d'un contact et d'une personne : Un contact est une fiche signalétique (nom, prénom, etc.). Un personne est un contact lié "qualifié". Sans vouloir rentrer dans les détails, personne est en faite une jointure entre contact et une autre entité. Chaque jointure posséde un degré de liaison, exemple : contact -> person <- site <=> pierre -> membre <- site 1234.

Ceci étant dit, pouvez préciser la remarque suivante ?

Envoyé par B.AF

C'est une erreur systèmatique !

Merci !

Envoyé par B.AF

La seule chose à faire systèmatiquement c'est de regarder le code SQL généré.

En effet ça aide. Je n'avais pas vu la formule magique tout de suite, mais quand j'ai vu ça, je me suis dit que j'allais enfin trouver la raison. C'était sans compter sur mon manque de bol...

En effet ceci :

Code SQL :

1
2
3
4
5
6
7
8
 
SELECT contact0_.contactid AS contactid2_0_, 
contact0_.firstname AS firstname2_0_, 
contact0_.lastname AS lastname2_0_, 
contact0_.Numcli AS Numcli2_0_, 
contact0_.Birthday AS Birthday2_0_ 
FROM CONTACT contact0_ 
WHERE contact0_.contactid=:p0;:p0 = 'xxxxxxxxxx18' [Type: String (12)]

n'est pas vraiment différent de cela :

Code SQL :

1
2
3
4
5
6
7
8
 
SELECT this_.contactid AS contactid2_0_, 
this_.firstname AS firstname2_0_, 
this_.lastname AS lastname2_0_, 
this_.Numcli AS Numcli2_0_, 
this_.Birthday AS Birthday2_0_ 
FROM CONTACT this_ 
WHERE this_.contactid = :p0;:p0 = 'xxxxxxxxxx18' [Type: String (12)]

Mais aujourd'hui j'ai découvert que NHibernate gérer ses log avec log4net. J'ai donc ajouter un petit App.config qui ouvre toutes les vannes des log ainsi que le code suivant dans le SetUp de mon projet NUnit

Code C# :

1
2
3
4
5
6
 
[SetUp]
public void Init() {
            (...)
            XmlConfigurator.Configure();
}

Le résultat est incroyable... plein (*10E1000) de log . Je peux donc mieux me rendre compte d'où viennent les pertes.

Premier test : Session.GetBy(string id); => sans criteria

Code :

1
2
3
4
5
6
7
NHibernate: SELECT contact0_.contactid as contactid2_0_, contact0_.firstname as firstname2_0_, contact0_.lastname as lastname2_0_, contact0_.Numcli as Numcli2_0_, contact0_.Birthday as Birthday2_0_ FROM CONTACT contact0_ WHERE contact0_.contactid=:p0;:p0 = 'CC0000151218' [Type: String (12)]
3984 [TestRunnerThread] DEBUG NHibernate.Connection.DriverConnectionProvider (null) - Obtaining IDbConnection from Driver
4025 [TestRunnerThread] DEBUG NHibernate.AdoNet.AbstractBatcher (null) - ExecuteReader took 37 ms
4025 [TestRunnerThread] DEBUG NHibernate.AdoNet.AbstractBatcher (null) - Opened IDataReader, open IDataReaders: 1
4027 [TestRunnerThread] DEBUG NHibernate.Loader.Loader (null) - processing result set
10509 [TestRunnerThread] DEBUG NHibernate.Loader.Loader (null) - result set row: 0
10518 [TestRunnerThread] DEBUG NHibernate.Loader.Loader (null) - result row: EntityKey[Megabyte.Slx.Data.Entity.Implementor.Contact#CC0000151218]

Deuxième test : Utilise les criteria

Code :

1
2
3
4
5
6
7
 
NHibernate: SELECT this_.contactid as contactid2_0_, this_.firstname as firstname2_0_, this_.lastname as lastname2_0_, this_.Numcli as Numcli2_0_, this_.Birthday as Birthday2_0_ FROM CONTACT this_ WHERE this_.contactid = :p0;:p0 = 'CC0000151218' [Type: String (12)]
10879 [TestRunnerThread] DEBUG NHibernate.Connection.DriverConnectionProvider (null) - Obtaining IDbConnection from Driver
10880 [TestRunnerThread] DEBUG NHibernate.AdoNet.AbstractBatcher (null) - ExecuteReader took 1 ms
10880 [TestRunnerThread] DEBUG NHibernate.AdoNet.AbstractBatcher (null) - Opened IDataReader, open IDataReaders: 1
10881 [TestRunnerThread] DEBUG NHibernate.Loader.Loader (null) - processing result set
17562 [TestRunnerThread] DEBUG NHibernate.Loader.Loader (null) - result set row: 0

On peut même remarquer que la différence entre les timestamp des deux lignes NHibernate.Loader.Loader (null) - processing result set et NHibernate.Loader.Loader (null) - result set row: 0 sont de 6482 et 6681. Ce n'est finalement pas une différence fondamentale.

Je crois donc que mes premiers tests ont été très mal réalisés (my bad ) et que finalement il n'y a pas vraiment de différence. Mais que surtout il n'y a pas de solution à mon problème de lenteur... c'est lent et puis c'est tout !

Mais avant de totalement baisser les bras pourriez vous me donner quelques indices sur la manière :

Envoyé par B.AF

d'utiliser aussi les statistiques de session pour comprendre ce qu'il se passe

Merci de votre suivi et de vos idées.

Bien à vous

[Nathanael Marchand]

Et le plan d'execution de cette requete, il donne quoi?

[SQLpro]

Hibernate est l'un des pire ORM au monde. Lisez les deux articles suivants et abandonnez l'idée d'avoir des performances avec hibernate ou bien abandonnez hibernate pour avoir des performances :
1) Hibernate 24 fois plus lent qu'une requête UPDATE SQL équivalente :
http://ormeter.net/images/stories/re...erformance.png
Dans la ligne UpdateInstance, en 1 minute SQL à fait 16 738 UPDATE tandis que NHibernate en à fait 683 !!!
2) Le danger de ORM : http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

A +

[WOLO Laurent]

Et si la requête SQL n'était pas la cause ?
Pouvez-vous nous donner le nombre de requête/s ?

[B.AF]

Envoyé par SQLpro

Hibernate est l'un des pire ORM au monde.
A +

Encore une intervention à forte valeur ajoutée avec des références écrites par des personnes qui n'y comprennent pas grand chose...Bref... passons, et mettons les mains dans le camboui : il y a moyen de voir le code dans son intégralité ?

C'est à dire tous les mappings avec toutes les associations et les configs ?

Même avec le log, il faudrait voir toute la matérialisation des objets. A vue de nez, ça ne peut pas venir de nhibernate, le cas semble trop standard. Donc à investiguer.

[WOLO Laurent]

Je commence vraiment à croire que beaucoup de gens utilisent les outils en se basant sur la pub sans bien les comprendre. Un ORM, ca fait de la traduction entre le SQL et Le monde Object, comment voulez-vous qu'il soit si performant que ça, c'est un traducteur .., il vaut mieux comprendre la langue maternelle, c'est aussi simple que ca.

[iberserk]

Hum...
Le problème est qu'ils sont utilisés... c'est un fait...
A nous de jouer notre rôle et de minimiser l'impact sur les performances...

Le problème et que déjà qu'on ne peut pas demander à 10% des développeurs de soigner leur accès aux données... les ORM n'arrangent rien car ils sont nativement plus lents... en apportant des lourdeurs qui ne sont pour moi pas de leur responsabilité...c'est un fait.

Donc oui on ne percevra pas la différence dans 75% des petites applications de gestion mais le problème se posera sur de 'vrai' applications ou quand ces applications seront déployées dans des environnement à forte sollicitations...

J'ai recemment vu sur ce forum un développeur extremement content d'avoir baissé de 50 secondes(il redémarrais le service SQL SERVER dans un foreach ou quoi)à ... 3 secondes pour l'ouverture d'un node de treeview!!!

Vous savez ce qu'il me dit mon client s'il attends deux secondes sur son site d'ebusiness???
Tiens ben je préfère pas vous le dire...

On a pas la même conception de la performance.