Kun je een rooktest doen met de eenvoudige vraag die mogelijk is, zoals:
SELECT current_timestamp()
of
SELECT 1 + 1
Dit zal u vertellen wat de werkelijke overhead van het JDBC-stuurprogramma is. Het is ook niet duidelijk of beide tests vanaf dezelfde machine zijn uitgevoerd.
Voer dezelfde query duizenden keren uit in Java. JVM heeft wat tijd nodig om op te warmen (class-loading, JIT). Ik neem ook aan dat SimpleJDBC.getConnection() maakt gebruik van C3P0-verbindingspooling - de kosten voor het tot stand brengen van een verbinding zijn behoorlijk hoog, dus de eerste paar uitvoeringen kunnen traag zijn.
Geef ook de voorkeur aan benoemde zoekopdrachten boven ad-hocquery's of criteriaquery's.
Hibernate is een zeer complex framework. Zoals u kunt zien, verbruikt het 75% van de totale uitvoeringstijd in vergelijking met onbewerkte JDBC. Als je onbewerkte ORM nodig hebt (geen lazy-loading, vuile controle, geavanceerde caching), overweeg dan mybatis
. Of misschien zelfs JdbcTemplate
met RowMapper
abstractie.
Niet echt. Bekijk de hoofdstuk 19. Prestaties verbeteren in de Hibernate-documentatie. Er is veel van reflectie die daar plaatsvindt + klassengeneratie. Nogmaals, Hibernate is misschien niet de beste oplossing als je elke milliseconde uit je database wilt persen.
Echter het is een goede keuze als u de algehele gebruikerservaring wilt vergroten vanwege uitgebreide caching-ondersteuning. Bekijk de prestaties doc weer. Het gaat vooral over caching. Er is een cache op het eerste niveau, een cache op het tweede niveau, een query-cache... Dit is de plaats waar Hibernate misschien beter presteert dan eenvoudige JDBC - het kan veel cachen op een manier die je je niet eens kunt voorstellen. Aan de andere kant zou een slechte cacheconfiguratie leiden tot een nog langzamere installatie.
Bekijk:Caching met Hibernate + Spring - enkele vragen!
JVM (vooral in server configuratie) is vrij snel. Het maken van objecten op de heap gaat net zo snel als op de stapel in b.v. C, garbage collection is sterk geoptimaliseerd. Ik denk niet dat de Java-versie met gewone JDBC veel langzamer zou zijn in vergelijking met een meer native verbinding. Daarom heb ik enkele verbeteringen in uw benchmark voorgesteld.
Ik geloof dat JDBC een goede keuze is als prestaties je grootste probleem zijn. Java is met succes gebruikt in veel database-zware applicaties.