Puoi fare un test del fumo con la query semplice possibile come:
SELECT current_timestamp()
o
SELECT 1 + 1
Questo ti dirà qual è l'effettivo sovraccarico del driver JDBC. Inoltre non è chiaro se entrambi i test vengano eseguiti dalla stessa macchina.
Esegui la stessa query diverse migliaia di volte in Java. JVM ha bisogno di un po' di tempo per il riscaldamento (caricamento della classe, JIT). Inoltre presumo SimpleJDBC.getConnection() utilizza il pool di connessioni C3P0:il costo per stabilire una connessione è piuttosto elevato, quindi le prime esecuzioni potrebbero essere lente.
Preferisci anche le query con nome alle query ad hoc o alle query con criteri.
Hibernate è un framework molto complesso. Come puoi vedere, consuma il 75% del tempo di esecuzione complessivo rispetto al JDBC grezzo. Se hai bisogno di ORM grezzo (nessun caricamento lento, controllo sporco, cache avanzata), prendi in considerazione mybatis
. O forse anche JdbcTemplate
con RowMapper
astrazione.
Non proprio. Consulta il Capitolo 19. Miglioramento delle prestazioni nella documentazione di Hibernate. C'è molto di riflessione che accade là fuori + generazione di classe. Ancora una volta, Hibernate potrebbe non essere la soluzione migliore quando vuoi spremere ogni millisecondo dal tuo database.
Tuttavia è una buona scelta quando si desidera aumentare l'esperienza utente complessiva grazie all'ampio supporto per la memorizzazione nella cache. Dai un'occhiata alle performance doc di nuovo. Si parla principalmente di memorizzazione nella cache. C'è una cache di primo livello, una cache di secondo livello, una cache di query... Questo è il luogo in cui Hibernate potrebbe effettivamente superare il semplice JDBC:può memorizzare nella cache molto in modi che non potresti nemmeno immaginare. D'altra parte, una configurazione scadente della cache porterebbe a un'installazione ancora più lenta.
Dai un'occhiata a:Memorizzazione nella cache con Hibernate + Spring:alcune domande!
JVM (soprattutto nel server configurazione) è abbastanza veloce. La creazione di oggetti nell'heap è veloce come nello stack, ad es. C, la raccolta dei rifiuti è stata notevolmente ottimizzata. Non penso che la versione Java che esegue JDBC normale sarebbe molto più lenta rispetto a una connessione più nativa. Ecco perché ho suggerito alcuni miglioramenti nel tuo benchmark.
Credo che JDBC sia una buona scelta se le prestazioni sono il tuo problema più grande. Java è stato utilizzato con successo in molte applicazioni pesanti per database.
