Вопрос перфоманса

[Omh]

Добрый день, господа присяжные заседатели.
Пока пил колу на обеде, возник вопрос к многоуважаемому сообществу.

Есть значит у меня база.
При заходе в неё, шерстятся другие базы и генерятся линки на документы.
При выходе эти линки вычищаются (все айтемы удаляются и присваивается спец. форма) и используются при след. заходе.
Так сделано ,что бы не создавать лишние стабы, а использовать одни и те же документы.


Ну так к чему это?

Сейчас эти линки генерятся и в них штампуется READERS поле, что бы человек видел тока свои линки.
Для все пользоватлей отображается один view с формулой что -то вроде {Form = "Link"}

Насколько я помню из школьной программы, использование READERS полей нормально стукает по перфомансу, особенно если человек видит малую часть всех документов.
Похоже это как раз мой случай.
Не скажу, что всё плохо, но есть куда стремиться.

У меня возникла идея, вообще не использовать READERS поля, а для каждого пользователя создать view из шаблона, с формулой что-то вроде {Form = "Link" & Owner = "SOME_USERNAME"}
Инфа в линках не особо важная, так что вполне можно не прятать по ридерам.

Внимание вопрос: как думаете, будет выхлоп со стороны перфоманса?

Один плюс я уже вижу: смогу использовать стандартные totals, ибо с ридер полями это невозможно.
Про подвовдные камни, типа необходимости переоткрыть базу для того, что бы увидеть view после CreateView, я знаю

Ани айдиас аре аппришиэйтед!
Ну и заранее спасибо за внимание!

 

[divankin]

>>При заходе в неё, шерстятся другие базы и генерятся линки на документы.

А можно поподробнее? Как часто будут туда заходить пользователи? Много ли планируется пользователей? Сложный ли код "шерстения"? Большие ли эти самые другие базы?
Мне почему-то кажется, что исполнение этой операции будет занимать куда большее время, чем потери производительности при использовании Readers полей.

>>У меня возникла идея, вообще не использовать READERS поля, а для каждого пользователя создать view из шаблона, с формулой что-то вроде {Form = "Link" & Owner = "SOME_USERNAME"}
А почему не собственную базу для каждого пользователя? Чужие документы никому не нужны. А индекс будет строиться гораздо быстрее

 

[morpheus]

Интересно, а сыграет ли на улучшение перформанса использование эмбетед вьюхи ?! с забиванием на ридерс

 

[ToxaRat]

У меня возникла идея, вообще не использовать READERS поля

тру

для каждого пользователя создать view из шаблона

фалсе

почему нельзя один категоризированный по юзернейму вид?

 

[Medevic]

Интересно, а сыграет ли на улучшение перформанса использование эмбетед вьюхи ?! с забиванием на ридерс

Сыграет.
Вообще, всё уже давно

Ссылка скрыта от гостей

.

 

[Omh]

Отписываю:
базы могут быть самые разные, шерстящая база не заточена под что-то конкретное, это больше движок, нежели приложение.

Ну для начала скажем так: 20 баз
от 200 документов/нескольких мегабайт до 100000 доков/15 гигов (это обычно к концу года)

Шерстится перимущественно через db.Search. Есть возможность заюзать db.FTSearch, но в реальной жизни до него руки не дошли.

Пользователей, скажем, тоже пока 20, для каждого думаю от 10 до 200-300 документов.
Открывают по началу дня, потом по желанию могут запустить рефреш, т.е. прошерстить ещё раз.

Да, код шерстения (конкретно search) занимает львинную долю, но потом не очень комфортно лазить по view, что-то там помиргивает, подтормаживает. Не радует вообщем.

Почему низзя embedded view? Нужно оставить возможность пересортировки данных по клику на хидере.

Почему не тру вьюшки для пользователей + хардкодед формула?

 

[Klido]

занимает львинную долю

а нашерстить на всех за полчаса до начала дня и потом показать сразу?

 

[Omh]

А почему не собственную базу для каждого пользователя?

Ну тогда реплику + селективная репликация, потому что часть документов (настроечные) у всех должна быть одинаковыа.
Мне что-то эта идея не очень нравиться, откину её на потом, хочу обойтись одной общей базой пока что...

Добавлено:

а нашерстить на всех за полчаса до начала дня и потом показать сразу?

Я подумывал подготавливать данные ночью и юзеру по утро выдавать на сковородке.
Даже реализую это.

Но это не решает того, что человек видит малую часть доков из базы и вместе с этим получает тормоза при открытии главного view.

 

[turumbay]

Ну тогда реплику + селективная репликация, потому что часть документов (настроечные) у всех должна быть одинаковыа.
Мне что-то эта идея не очень нравиться, откину её на потом, хочу обойтись одной общей базой пока что...

А вроде нормальная идея. Для домино - родная архитектура, по аналогии с почтовыми ящиками.
Общие документы( настроечные ) можно из общей базы тащить(аналог АК). Базы в отдельный каталог, создавать их можно программно, дизайн наследовать с общего шаблона. Вопщем все как в почте. Если что, можно даже дизайнера юзеру дать относительно безопасно.
А вот селективную репликацию баз в пределах одного сервера - я бы поостерегся.

 

[akat]

А если не городить огород, а попытаться оптимизировать ридерс-поля?

Мне как-то досталось унаследованное приложение, перфоманс был ниже плинтуса. Оказалось, что по ходу жизненного цикла документа в его ридерс-поле было 30-40 уникалиных лотус-имен сотрудников.

Выполнил оптимизацию: перешли на ролевые группы + лотус-имя автора. В результате в ридерс-полях было до десяти лотус-имен. Перфоманс улучшился кардинально!

 

[divankin]

Ну тогда реплику + селективная репликация, потому что часть документов (настроечные) у всех должна быть одинаковыа.
Мне что-то эта идея не очень нравиться, откину её на потом, хочу обойтись одной общей базой пока что...

Настроечные документы можно объявить элементами дизайна, например, навигаторами. Тогда они тоже будут наследоваться из шаблона. А чтобы их можно было легко доставать, делается вьюшка с нужным $FormulaClass

Почему низзя embedded view? Нужно оставить возможность пересортировки данных по клику на хидере.

Для пересортировки по другому столбцу можно дать кнопку, которая переоткрывает окно и показывает другую embedded view. В результате есть бонус, что можно иметь категоризованные вьюшки.
У меня эти кнопки типа checkbox, плюс в названии отсортированного столбца есть жирная точка. Я надеюсь, что моим пользователям понятно, какой столбец отсортирован: )

 

[Omh]

Бек ту ворк!

а попытаться оптимизировать ридерс-поля?

Там, на самом деле, нечего оптимизировать: в каждом линк документе есть только одно поле ридерс из 2-х записей: человек, из-под которого сгенерен этот линк и роль для экстренных случаев (что-то типа [FullAccess])

Я понимаю, что системы
1. из одной настроечной базы + шерстящая каждому юзеру отдельно
2. одна база + селективная репликация (ну например на локал) каждому
кагбэ и лишены этих недостатков.

Но пока что я хочу обойтись одной общей базой для всех пользователей.

Пока что идея с view для каждого пользователя меня всё-ещё привлекает.

А да, вот про использование бекграунд агентов: это как раз тот случай, когда их целесообразно использовать:
юзер открыл базу, бекграунд агента начал шерстить и потихоньку подготавливать для пользователя данные, а тот в это время может поработать в других базах

 

[Klido]

это не решает того, что человек видит малую часть доков из базы и вместе с этим получает тормоза при открытии главного view

почему малую часть? и если индекс отстроен - тормозов быть не должно...

Для пересортировки по другому столбцу можно дать кнопку, которая переоткрывает окно и показывает другую embedded view. В результате есть бонус, что можно иметь категоризованные вьюшки.

Добавлено:

юзер открыл базу, бекграунд агента начал шерстить

и так шерстение при каждом входе/выходе юзера, умножим на кол-во юзеров - сколько шерстения.... все кааак вцепятся в шерстимые базу - ух....

если моментальной динамики все равно нет - запускаем шерстение раз в 1-2 часа на серваке по всем юзерам, а они просто открывают... да если с линками без ридерсов - прекрасно выйдет...

 

[Darker]

Может лучше использовать профили? И кидать туда линки?
При открытии базы автоматом будет открываться профиль юзера с DocLink-ми

 

[ToxaRat]

Почему не тру вьюшки для пользователей + хардкодед формула?

идем дальше
почему не сделать для каждого пользователя отдельную базу и ембедедь вью будет вести каждого в свою базу?
всего-то нужно сделать вычисляемую подформу с ембедедом и агентом через DXML наштамповать эти подформы

а вообще подсовывать пользователю уже вычисленные заранее данные - есть оно самое

 

[Klido]

сделать для каждого пользователя отдельную базу

я был бы против этого по чисто админским причинам много баз - не есть хорошо... а вдруг надо будет ещё линки обрабатывать, например.... да и суппорт - ползать по базам не есть айс....

 

[ToxaRat]

я был бы против этого по чисто админским причинам много баз - не есть хорошо... а вдруг надо будет ещё линки обрабатывать, например.... да и суппорт - ползать по базам не есть айс....

а чего плохого?
агент будет всем этим рулить, создастся спец папочка, там всё это кодло лежит
причем обрабатываться по скорости будет сумашедшим

 

[Omh]

Дополнительные условия есть, о которых я умолчал, и сейчас вижу, что блин, не коррелирует. :mellow:

Условие такое:
view из этой базы будет эмбеднуто в welkome page у всех пользователей через политики.
Т.е. юзер открывает лотус, и один из фреймов в его welcome page - view из шерстящей базы.

Это одна из причин, поэтому не охота связываться с многими базами.

Но мазафака, с несколькоими view тоже возникает проблема:
допустим у меня есть view для пятии юзеров и name|alisas примерно такими:
Default|Default_User1
Default|Default_User2
Default|Default_User3
Default|Default_User4
Default|Default_User5

В велкомпейдж я дефайню view с именем Default.
Если в базе только одно (ну или видимо только одно) view с таким именем, то всё отображается нормально.

Получается, что каждый пользователь должен видеть только своё view c именем Default, что бы коректно отобразить его в велкомпейдже.
А это значит начинается разделение view по видимости (по READERS полям)
Мне это начинает не нравиться: усложнять просто, упрощать сложно.

Похоже придётся оставаться на readers полях и без нормальных тоталов.
Не радует.

Можка кто что подскажет?

 

[divankin]

Есть два неплохих способа указать, что открывать во фрейме: профайлы и environment. А если для пользователя ничего не указано, то открывать страничку с кодом, который все заполнит и попросит пользователя перезайти в Лотус.

Если для вас это слишком сложно, то можно сделать, чтобы путь к базе или название вьюшки вычислялось из имени пользователя.

 

[Omh]

В том то и соль, что там указвается не фрейм :mellow:
А конкретное view
Вычислить, что отображать во фрейме не проблема, но в welcomepage эмбеддится именно view, а не фрейм

А в лотусе для меня сложного мало что осталось, я на этой мазафаке уже 8 лет батрачу

Можно смело на "ты", мне стремует обращение на "Вы" в интеренетах.

Похоже, похерю я пока эту идею, тем более осталось работать 2 дня и оооотпуск