|
|
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Имеем в наличии систему Tomcat+Hibernate+Oracle. Все запросы вроде используют связанные переменные. При этом имеем для наших запросов в V$SQLAREA кол-во parse_calls=executions. Трассирование показало, что в основном parse_calls идут в soft parse. Классический Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. дает parse_calls+1 и executions+200. Если закрывать коннект, имеем одинаковый прирост по обеим переменным. Соответственно вопрос: Можно как-то настроить hibernet на такой же результат? Как-то удерживать коннект между запросами в сервлете? Насколько стоит обращать внимание на soft parse? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2012, 18:00:52 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Так и soft parse, вроде, как раз и есть показатель того что квери не парсятся полностью, а используются те что парсились раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2012, 18:08:25 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
из простор интернетаIf an SQL statement is parsed in a cursor and then executed repeatedly without closing the cursor or parsing another statement in it, then the V$SQLAREA statistics will show many more EXECUTIONS than PARSE_CALLS for that statement. If statements are never reused, then EXECUTIONS and PARSE_CALLS are normally identical. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2012, 18:10:41 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Я так понимаю, что PARSE_CALLS, это все запросы на парс стейтмента. Дальше начинаются варианты. Если в кэше есть аналогичный разобранный стейтмент, идет софт парс. Если нет, идет хард парс. Если мы держим готовый ПрепередСтейтмент и только дергаем экзекьют, запрос на парс приходит только один, остальное идет в счетчик экзекьюшнс. Но, т.к. приходится использовать пул коннектов, готовый ПрепередСтейтмент не сохраняется и получается в итоге parse_calls=executions. Возникает вопрос, есть ли возможность как-то сохранять готовый ПрепередСтейтмент? Или может софт парс не та вещь на которой стоит заморачиваться? Стоит овчинка выделки, убрать даже софт парс? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 10:06:51 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
stateistat, а ты замерял тормоза без данного кэша? Размер запросов небольшой, задержки по сети минимальные, оракл на такой запрос даст ответ из своего кэша. ? ______________________________________________ "Сделай настолько просто, насколько это возможно, но не проще". © А. Эйнштейн. AutoPOI.ru — ГИС-технологии для Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 10:34:45 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
stateistatЯ так понимаю, что PARSE_CALLS, это все запросы на парс стейтмента. Дальше начинаются варианты. Если в кэше есть аналогичный разобранный стейтмент, идет софт парс. Если нет, идет хард парс. Если мы держим готовый ПрепередСтейтмент и только дергаем экзекьют, запрос на парс приходит только один, остальное идет в счетчик экзекьюшнс. Но, т.к. приходится использовать пул коннектов, готовый ПрепередСтейтмент не сохраняется и получается в итоге parse_calls=executions. Возникает вопрос, есть ли возможность как-то сохранять готовый ПрепередСтейтмент? Или может софт парс не та вещь на которой стоит заморачиваться? Стоит овчинка выделки, убрать даже софт парс? У вас реально есть причины предполагать, что soft parse является источником серьезных тормозов на проекте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 12:16:40 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Нет. Просто попытки за что-то зацепиться. Рассматриваю варианты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 14:47:41 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
stateistatНет. Просто попытки за что-то зацепиться. Рассматриваю варианты. В трех-звенке, обычно, не задарживают курсоры и prepared statement на долго, потому что это сильно снижает масштабируемость. Получил свободное соединение, создал statement - отправил запрос. По окончании транзакции, всё это барахло закрыл. Чем дольше транзакция, тем больше вероятность взаимных блокировок и других неприятностей при высоких нагрузках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 14:59:46 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
stateistatРассматриваю варианты. вариантов вроде не так много, ровно полтора Чаще чем коннект-транзакция на реквест (веб) нет смысла. Длиннее (на view) экзотика и надо обосновать. Ещё вариант оптимизации - транзакцию открывать только на пишущие. На читающие не надо. Т.е. работать только с сессией хибера. imho ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 15:05:49 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Petro123Длиннее (на view) экзотика и надо обосновать. Да-да. Надо запустить на тестах. Отследить все запросы хибера и конвертнуть их в хранимки. Petro123Ещё вариант оптимизации - транзакцию открывать только на пишущие. На читающие не надо. Т.е. работать только с сессией хибера. imho А это как должно помочь? Чтение "без транзакции", приведет к тому же soft parse. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 15:18:48 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, ты меня не понял. 1. Я нашёл только один способ в вебе - все рессурсы ведут к HibernateFilter. Есть другие - напиши. 2. На чтении это просто лишнее действие - оверхед. (делать start transaction на SELECT). Просто на это никто внимания не обращает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 15:27:34 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Petro1231. Я нашёл только один способ в вебе - все рессурсы ведут к HibernateFilter. Есть другие - напиши. ОК. Объясни идею плз. Что в нем делать-то? Petro1232. На чтении это просто лишнее действие - оверхед. (делать start transaction на SELECT). Просто на это никто внимания не обращает. Почему не обращает? @Transactional(readOnly=true) и готово. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 15:34:23 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, типа такого - сам пока не проверял. Идея проста как 3 рубля - на несколько реквестов - одна сессия хибера (а-ля десктоп) Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 2. я говорил о hibernateSession.beginTransaction(); Если от аннотации тот же эффект, то ОК ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 15:44:22 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, по поводу п.2 Тут надо автора спросить, каким методом он их там стартует. Если JPA-аннотации то там "такие камни есть" Проблемы с флагом read-only аннотации @Transactional http://www.k-press.ru/cs/2009/1/ts/ts.asp#ID0ESG хотя может и "боян". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 15:58:14 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Petro123 Проблемы с флагом read-only аннотации @Transactional http://www.k-press.ru/cs/2009/1/ts/ts.asp#ID0ESG Спасибо! Эта статья как-то прошла мимо меня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 16:19:38 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 16:30:18 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
автор http://www.k-press.ru/cs/2009/1/ts/ts.asp#ID0ESG О, спасибо я боюсь, что она разочарует любителей аннотаций-транзакций. Слишком много там тонкостей и частностей в данном методе. Ничего личного (с), я все модели транзакций люблю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 16:36:23 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Petro123я боюсь, что она разочарует любителей аннотаций-транзакций. Слишком много там тонкостей и частностей в данном методе. Ничего личного (с), я все модели транзакций люблю :) Во-первых всё сильно зависит от того как реализован менеджер транзакций. Во-вторых статья показывает очевидное превосходство Spring над JEE. В спринг, я всегда могу пойти и посмотреть что делает менеджер. :) Но дефолтное поведение, действительно, не тривиальное. Надо бы на новых версиях потестить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 16:42:48 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
авторВо-первых всё сильно зависит от того как реализован менеджер транзакций. Во-вторых статья показывает очевидное превосходство Spring над JEE. В спринг, я всегда могу пойти и посмотреть что делает менеджер. :) Но дефолтное поведение, действительно, не тривиальное. Надо бы на новых версиях потестить. Ну я особых преимуществ у Spring не заметил, почти все описанные проблемы тривиально отлавливаются при помощи тестирования, что меня реально удивило так это поведение флага readonly, на практике редко встречался с ним, и скорее всего наткнулся бы на грабли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 16:50:35 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Во-вторых статья показывает очевидное превосходство Spring над JEE. А в каких местах функциональность спринга пересекается с функциональностью JEE? Spring transactions это же просто обертка над JTA. Соотношение как между Ubuntu и Bolgenos. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 18:13:49 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪSpring transactions это же просто обертка над JTA. http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/support/AbstractPlatformTransactionManager.html Direct Known Subclasses: CciLocalTransactionManager, DataSourceTransactionManager, HibernateTransactionManager, JdoTransactionManager, JmsTransactionManager, JpaTransactionManager, JtaTransactionManager, TopLinkTransactionManager ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 18:19:43 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Во-первых, мне очень не нравится использование слова TransactionManager в этих классах. Термин Transaction Manager определен в стандарте http://en.wikipedia.org/wiki/X/Open_XA за 20 лет до появления спринга и имеет четкое значение. Зачем надо было переопределять термин внутри спринга, мне неясно. Во-вторых, что на самом деле делают эти классы? 1)Заменяют try/finally лапшу на transactionTemplate.execute(new TransactionCallback(){public void doInTransaction()...} лапшу. 2)Использует для передачи переменной, в которой хранится текущая транзакция, динамический скоупинг вместо лексического ( http://en.wikipedia.org/wiki/Scope_%28computer_science%29). Можно считать, что это удобно, можно считать, что нет. В любом случае, это не технология, а простейшая обертка над API. Любой программист напишет такую без проблем за минимальное время. Скорее всего, получится даже лучше(проще и понятнее). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 21:38:51 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪМожно считать, что это удобно, можно считать, что нет. В любом случае, это не технология, а простейшая обертка над API. Любой программист напишет такую без проблем за минимальное время. Скорее всего, получится даже лучше(проще и понятнее).Старая песня - "лушче написать свое". Вы там случаем свой аппликейшн сервер не написали еще? А то, мало ли - вдруг вам какая-нибудь аббревиатура или имя класса в существующих не нравятся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 21:56:13 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, ну, тут тебя в сторону повело :). На критику декларативного управления транзакций :) Это же оффтоп. А многословность многочисленных обёрток в Java действительно есть. Мне вот, 3 буквы у спрингMVC не нравятся. Но ведь одно другому не мешает? ;) С помощью Хибер-утилиту пожно писать одной строкой. ЗЫ Понятие менеджер или хелпер можно натянуть на что угодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 22:19:43 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Да я в этом треде не собирался ничего критиковать. Просто не понимаю, как можно сравнивать Spring и JEE. В JEE есть очередь сообщений, вебсервер, менеджер транзакций - в Spring нет ничего из этого. Пересечение есть только по JSF и Spring MVC. WebSphereMQ уходит корнями в 70-е. Технология существует 40 лет и будет существовать еще столько же без проблем. Цикл жизни какого-нибудь спринга - несколько лет. Откройте гитхаб - там этих спрингов тысячи. Завтра какой-нибудь Вася наведет хайп вокруг своего поделия, и все бросятся его внедрять в свои проекты. Ну например, сейчас json обороты набирает. В новом DI контейнере можно будет делать конфигурацию через json, это так современно и круто! Был EJB CMP, стал гибернейт. Были container-managed transactions, стали spring declarative transactions. И т.д. При этом программист ставится в положение идиота. Все время надо изучать какие-то новые дебильные апи, которые делают то же что и старые, только с учетом тараканов в голове их создателя. Это на фоне того что ключевые технологии не меняются по 30 лет. Когда крупный вендор объявляет смену технологии, то да, тут ничего не поделаешь, придется переучиваться. Но добровольно самим раз в несколько лет находить какую-нибудь новую волшебную библиотеку, внедрять ее, потом через несколько лет опять все переписывать - это выше моего понимания. Еще, кстати, из-за того что надо изучать какой-нибудь новый хибернейт, нет времени изучить фундаментальные технологии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 23:22:42 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Пример: человек изучил все тонкости спринга и хибернейта, но при этом не знает, как устроена хэш-таблица или чем read commited отличается от serializable. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2012, 23:29:09 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, Так и знал что на 2 страницу перейдешь.:) . . . Это неизбежное деление интересов на системщиков и прикладников. Их нельзя противопоставлять. Слишком объемная Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2012, 07:27:01 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪПример: человек изучил все тонкости спринга и хибернейта, но при этом не знает, как устроена хэш-таблица или чем read commited отличается от serializable. Чего-то я сомневаюсь, что не зная как работает хэш-таблица можно изучить тонкости хибернейта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2012, 10:49:44 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪДа я в этом треде не собирался ничего критиковать. Просто не понимаю, как можно сравнивать Spring и JEE. В JEE есть очередь сообщений, вебсервер, менеджер транзакций - в Spring нет ничего из этого. Их сравнивают преимущественно по части EJB vs SpringIoC, так как именно через EJB или контекст спринга приложение собирается в кучу через Dependency Injection. И в этом плане Spring вздрючивает EJB на порядки в плане гибкости и простоты использования/тестирования. Йуный джавистЪПересечение есть только по JSF и Spring MVC.Никакого пересечения нету. JSF - это компонентный фреймворк, в SpringMVC никаких компонентов нет. Йуный джавистЪWebSphereMQ уходит корнями в 70-е. Технология существует 40 лет и будет существовать еще столько же без проблем. Цикл жизни какого-нибудь спринга - несколько лет. Откройте гитхаб - там этих спрингов тысячи. Завтра какой-нибудь Вася наведет хайп вокруг своего поделия, и все бросятся его внедрять в свои проекты.Полное незнание истории. 1995 - Появление Java 1998 - Появление EJB 2001 - Появление более-менее вменяемых EJB (2.0) 2001 - Появление Hibernate 2002 - Появление Spring Итого, возраст Хибера - 11 лет, лидер в ORM. Spring - 10 лет, лидер в DI. Так что про какие мимолетные технологии вы говорите - непонятно. Йуный джавистЪНу например, сейчас json обороты набирает. В новом DI контейнере можно будет делать конфигурацию через json, это так современно и круто!Ну, во-первых, JSON это в первую очередь формат коммуникации. Ну а во-вторых, он настолько простой, что даже если кому-то ударит в голову моча писать конфигурацию на JSON, разобраться в нем займет ровно 10 минут времени. Йуный джавистЪБыл EJB CMP, стал гибернейт.Неверно. Хибернейт - это один из провайдеров современной инкарнации EJB CMP - JPA. Они дополняют друг друга, а не конкурируют. Йуный джавистЪБыли container-managed transactions, стали spring declarative transactions.Contrainer-managed transaction никуда не делись, просто нынче именуются JTA. А цель менеджера транзакций Спринга - абстрагироваться от того, кто реально управляет в приложении транзакциями - хоть это апп. сервер (JTA), хоть "руками" через JDBC, хоть еще как - разработчику не нужно париться по этому поводу. Ему достаточно либо выучить JTA аннотации (а Spring использует именно их), либо же разобраться с синтаксисом описания транзакций в Spring, что займет максимум полчаса. Йуный джавистЪПри этом программист ставится в положение идиота. Все время надо изучать какие-то новые дебильные апи, которые делают то же что и старые, только с учетом тараканов в голове их создателя. Это на фоне того что ключевые технологии не меняются по 30 лет.Безусловно, не меняются. Вот только Java и понятие "виртуальная машина" существует всего 17 лет, соответственно все существующие сервера приложений и все JSR существуют еще меньше Йуный джавистЪКогда крупный вендор объявляет смену технологии, то да, тут ничего не поделаешь, придется переучиваться. Но добровольно самим раз в несколько лет находить какую-нибудь новую волшебную библиотеку, внедрять ее, потом через несколько лет опять все переписывать - это выше моего понимания.Выше моего понимания то же, так как: а) принципиально новые вещи появляются крайне редко б) если даже они и появляются, вас никто не заставляет что-то переписывать Йуный джавистЪЕще, кстати, из-за того что надо изучать какой-нибудь новый хибернейт, нет времени изучить фундаментальные технологии.Интересный подход. То есть оказывается наличие некоего абстрактоного "Хибернейта" не дает вам учить фундаментальные вещи. Хорошая отмазка, чо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2012, 11:25:27 |
|
||
|
Hibernate+Oracle=много soft parse
|
|||
|---|---|---|---|
|
#18+
svenom +1 svenomПолное незнание истории. 1995 - Появление Java 1998 - Появление EJB 2001 - Появление более-менее вменяемых EJB (2.0) 2001 - Появление Hibernate 2002 - Появление Spring Итого, возраст Хибера - 11 лет, а продолжить после 02 слабо? Правда это оффтоп. svenomлидер в ORM. Spring - 10 лет, лидер в DI. Так что про какие мимолетные технологии вы говорите - непонятно. Вот это верно - они лидеры в данных _областях_ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2012, 11:36:51 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2132602]: |
0ms |
get settings: |
11ms |
get forum list: |
22ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
45ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 331ms |
| total: | 495ms |

| 0 / 0 |
