Czy możesz wykonać test dymu za pomocą prostego zapytania, takiego jak:
SELECT current_timestamp()
lub
SELECT 1 + 1
Dzięki temu dowiesz się, jakie jest rzeczywiste obciążenie sterownika JDBC. Nie jest również jasne, czy oba testy są wykonywane na tej samej maszynie.
Uruchom to samo zapytanie kilka tysięcy razy w Javie. JVM potrzebuje trochę czasu na rozgrzanie (ładowanie klas, JIT). Zakładam również, że SimpleJDBC.getConnection() używa puli połączeń C3P0 - koszt nawiązania połączenia jest dość wysoki, więc kilka pierwszych uruchomień może być powolne.
Preferuj również nazwane zapytania niż zapytania ad hoc lub zapytania kryterialne.
Hibernate to bardzo złożony framework. Jak widać, zajmuje 75% całkowitego czasu wykonania w porównaniu do surowego JDBC. Jeśli potrzebujesz surowego ORM (bez leniwego ładowania, brudnego sprawdzania, zaawansowanego buforowania), rozważ mybatis
. A może nawet JdbcTemplate
z RowMapper
abstrakcja.
Nie bardzo. Zapoznaj się z rozdziałem 19. Poprawa wydajności w dokumentacji Hibernate. Jest dużo refleksji, która się tam dzieje + generowanie klas. Po raz kolejny Hibernate może nie być najlepszym rozwiązaniem, gdy chcesz wycisnąć każdą milisekundę z bazy danych.
Jednak jest to dobry wybór, gdy chcesz zwiększyć ogólne wrażenia użytkownika ze względu na obszerną obsługę pamięci podręcznej. Sprawdź wydajność doktor ponownie. Mówi głównie o buforowaniu. Jest pamięć podręczna pierwszego poziomu, pamięć podręczna drugiego poziomu, pamięć podręczna zapytań... To jest miejsce, w którym Hibernate może faktycznie przewyższyć zwykłe JDBC - może buforować dużo w sposób, którego nawet nie możesz sobie wyobrazić. Z drugiej strony - słaba konfiguracja pamięci podręcznej doprowadziłaby do jeszcze wolniejszej konfiguracji.
Sprawdź:Buforowanie z Hibernate + Spring – kilka pytań!
JVM (zwłaszcza na serwerze) konfiguracja) jest dość szybki. Tworzenie obiektów na stosie jest tak samo szybkie jak na stosie np. C, zbieranie śmieci zostało znacznie zoptymalizowane. Nie sądzę, aby wersja Javy działająca na zwykłym JDBC była znacznie wolniejsza w porównaniu z bardziej natywnym połączeniem. Dlatego zasugerowałem kilka ulepszeń w twoim benchmarku.
Uważam, że JDBC to dobry wybór, jeśli największym problemem jest wydajność. Java jest z powodzeniem używana w wielu aplikacjach z dużą ilością baz danych.
