Pouvez-vous faire un test de fumée avec la requête simple possible comme :
SELECT current_timestamp()
ou
SELECT 1 + 1
Cela vous indiquera quelle est la surcharge réelle du pilote JDBC. De plus, il n'est pas clair si les deux tests sont effectués à partir de la même machine.
Exécutez la même requête plusieurs milliers de fois en Java. La JVM a besoin d'un certain temps pour s'échauffer (chargement de classe, JIT). Aussi je suppose SimpleJDBC.getConnection() utilise le regroupement de connexions C3P0 - le coût d'établissement d'une connexion est assez élevé, de sorte que les premières exécutions peuvent être lentes.
Préférez également les requêtes nommées aux requêtes ad-hoc ou aux requêtes par critères.
Hibernate est un framework très complexe. Comme vous pouvez le constater, il consomme 75 % du temps d'exécution global par rapport à JDBC brut. Si vous avez besoin d'ORM brut (pas de chargement paresseux, de vérification sale, de mise en cache avancée), pensez à mybatis
. Ou peut-être même JdbcTemplate
avec RowMapper
abstraction.
Pas vraiment. Consultez le Chapitre 19. Amélioration des performances dans la documentation Hibernate. Il y a beaucoup de réflexion qui se passe là-bas + génération de classe. Encore une fois, Hibernate n'est peut-être pas la meilleure solution lorsque vous souhaitez extraire chaque milliseconde de votre base de données.
Cependant c'est un bon choix lorsque vous souhaitez améliorer l'expérience utilisateur globale grâce à une prise en charge étendue de la mise en cache. Découvrez les performances doc à nouveau. Il parle principalement de mise en cache. Il y a un cache de premier niveau, un cache de deuxième niveau, un cache de requête... C'est l'endroit où Hibernate pourrait en fait surpasser JDBC simple - il peut mettre en cache beaucoup d'une manière que vous ne pourriez même pas imaginer. D'autre part, une mauvaise configuration du cache entraînerait une configuration encore plus lente.
Consultez :Mise en cache avec Hibernate + Spring - quelques questions !
JVM (en particulier dans serveur configuration) est assez rapide. La création d'objets sur le tas est aussi rapide que sur la pile, par exemple. C, la collecte des ordures a été grandement optimisée. Je ne pense pas que la version Java exécutant simplement JDBC serait beaucoup plus lente par rapport à une connexion plus native. C'est pourquoi j'ai suggéré quelques améliorations à votre benchmark.
Je pense que JDBC est un bon choix si les performances sont votre plus gros problème. Java a été utilisé avec succès dans de nombreuses applications gourmandes en bases de données.
