|
|
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
ъа откуда он был, такой набор параметров? юзер не находит что искал и начинает долбить по 2тыс страницам? нахрен нужен такой сервис. с какой вероятностью попадаете в кеш? Вы о чем это сейчас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:08 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaЯ к тому, что рассуждать о вреде рефлексии при таких выборках, по крайней мере-нелогично. Накладные расходы на нее в таких случаях ничтожны. Специальный тест писать было лень, поэтому опробовал на том, что есть в текущем проекте. При отключенном Хибернейтовском Reflection Optimizer'е (по сути -- генератор сборок, отвечающих за наполнение объектов данными и их обратный разбор) запрос на 8000+ объектов занимал на 3 секунды больше, чем при включенном оптимизаторе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:11 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Роман ДынникКак она будет плакать? кешированный HQL можно сравнивать с кешированнием вызовов хп (в CSLA). Так что тут либо никакой разницы, либо CSLA быстрее на этом этапе. Что такое "кешированние вызовов хп"? Кеширование результатов запросов или чего? Нахлобуч А кеширование MethodInfo (кеширование нескольких делегатов) по механизму быстрее чем разбор и кеширование HQL - выражений. Вот дался вам HQL. Вы думаете, что они при каждом запросе заново парсятся что ли? Роман Дынник Это спорное филосовское утверждение. Делаем POCO/POJO - получаем слабосвязанный и легко переносимый (что плюсы), но плохо инкапсулированный код (что несомненно минус) с недостаточным функционалом. ...который легким движением руки выносится в service layer. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:15 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
НахлобучЧто такое "кешированние вызовов хп"? Кеширование результатов запросов или чего? кеширование планов запроса. Нахлобуч Вот дался вам HQL. Вы думаете, что они при каждом запросе заново парсятся что ли? Думаю что сначала ищется в хеш-таблице уже распарсенный. Но в целом, думаю что парсинг достаточно частый из-за множества весьма разношерстных HQL-запросов. Нахлобуч...который легким движением руки выносится в service layer. без разницы для service layer чем пользоваться rich или POCO. Легким движением руки выносится и тот и другой тип. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:34 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
250 Мб/120мил = 2,5байта на запись!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 13:19 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVa250 Мб/120мил = 2,5байта на запись!!! Вы большой оригинал :) Вот именно эти 120 миллионов в памяти и не хранятся? Там куча справочных данных, профили пользователей и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 13:26 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобучхранятся? Вопросительный знак лишний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 13:29 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Да, нет, Нахлобуч,это Вы большой путанник.Теперь выясняется, что кэшируются только справочники и прочая мелкая лобуда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 14:21 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
мне кажется всем должно быть очевидно, что вся база в кеш не падает, подразумевать это по крайней мере глупо, не так ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 14:23 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaДа, нет, Нахлобуч,это Вы большой путанник.Теперь выясняется, что кэшируются только справочники и прочая мелкая лобуда. Ну посудите сами -- зачем кэшировать результаты запросов (представляющие из себя россыпь идентификаторов), которые заведомо не будут повторяться? А в кэше лежит отнюдь не мелкая лабуда, поверьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 14:28 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобуч зыхм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша? У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю Нахлобуч зы В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать? Не Хибернейт, а сам сиквель. Он с ума сходит -- в поисковых таблицах меньше 120 миллионов записей редко бывает. НахлобучВы о чем это сейчас? Так в чем фишка не использовать пейджинг скуль сервера? НахлобучТам куча справочных данных, профили пользователей и т.д. У всех к кеше куча справочных данных и профили пользователей. "и т.д." показывай? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 16:01 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
ъТак в чем фишка не использовать пейджинг скуль сервера? В том, что он захлебывается. Пробовали уже. ъ У всех к кеше куча справочных данных и профили пользователей. "и т.д." показывай? Охх... Туристический сервер. Поиск и бронирование туров. Загружаем данные, кладем в свою БД. Денормализуем на отдельный сервер, на нем ищем. При выводе из основного сервера читается информация о городах (несколько тысяч), странах (около 200 штук, по-моему), отелях (30+ тысяч, с фотографиями и прочим барахлом), типах питания, звезностях, категориях номеров (все от десятков до сотен единиц). При бронировании вытягиваются данные о туристах, сервисах бронирования, транспортах и прочем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 16:08 |
|
||
|
|
start [/forum/topic.php?fid=17&gotonew=1&tid=1352448]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
13ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
2ms |
| others: | 213ms |
| total: | 392ms |
| 0 / 0 |
