Странная производительность с использованием JPA, я что-то упустил?

Question

У нас есть JPA -> Hibernate -> Oracle, где мы можем запустить только 22 транзакции в секунду (две операции чтения и одна запись в транзакции).Процессор, диск и сеть не являются узким местом.

Что-то мне не хватает?Интересно, может ли быть какое-то ограничение, наложенное оракулом, которое применяли администраторы базы данных?

• Сеть - это не проблема, так как когда я выполняю необработанные чтения в таблицеможет сделать 2000 операций чтения в секунду.Проблема четко записывается.
• ЦП не проблема на сервере приложений, ЦП в основном работает на холостом ходу.
• Диск непроблема на сервере приложений, данные полностью загружаются в память перед началом обработки

Answer 1

Похоже, что приложение выполняет транзакцию чуть менее, чем за 0,05 секунды.Если операторы SELECT и UPDATE извлекаются из приложения и запускаются ими самостоятельно, с использованием SQL * Plus или какого-либо другого инструмента, сколько времени они занимают, и если вы сложите время для операторов, они приблизятся почти к 0,05?Откуда поступают данные, которые используются в запросах, а какие в конечном итоге используются в ОБНОВЛЕНИИ?Вполне возможно, что замедление не в базе данных, а где-то еще в приложении, например, на этапе сбора данных.Возможно, что-то вроде профилировщика можно использовать, чтобы узнать, где приложение тратит свое время.

Делитесь и наслаждайтесь.

Answer 2

Возможно, стоит сравнить производительность с другой клиентской технологией (или даже простым тестом с использованием SQL * Plus), чтобы увидеть, можно ли в любом случае побить эту производительность - это может быть просто база данных с ограниченными ресурсами или неправильно настроенная база данных.

Я бы также сравнил результаты для SQL Plus, работающего непосредственно на сервере d / b, и локально на том компьютере, на котором работает ваш код Java (где он взаимодействует через SQL Net),Это подтвердит, если проблема ниже вашего уровня Java.

Если честно, между вашим JPA-кодом и самой базой данных очень много уровней, диагностика причины будет интересной.,,Я помню, что одна загадочная проблема с производительностью d / b решилась как неправильно настроенная сетевая карта - администраторы баз данных справедливо настаивали на том, что в базе данных не было узких мест.