07.07.2010, 09:39 | #1 |
Участник
|
Местами тормозит DAX2009
DAX2009, ROLLUP5
Хочу узнать, только у меня местами тормозит DAX2009 или это общая проблема? Готовимся к переходу на нее месяца два, заметил: 1.Очень долго (14 секунд) открывается форма Сервис\Параметры. 2.Форма для сравнения кода открывается за 3 сек (в 3.0 меньше секунды), сравнение тоже дольше чем в трешке. Причем, заметил, что чем дольше работаешь без перезапуска клиента, тем медленнее это сравнение работает. 3.Если одновременно и программируешь и работаешь с функционалом, замедляется работа форм (журналов, заказов на продажу и закупку). Клиентский комп с XP, двухядерный с 4Гб, АОС 4 ядра, 4 Гб. |
|
07.07.2010, 10:01 | #2 |
Участник
|
Пункт 1 - в полный рост ((
По остальным сравнение специально не проводил, но работать достаточно комфортно.
__________________
Ivanhoe as is.. |
|
07.07.2010, 10:38 | #3 |
Участник
|
По п.1 - тормоза из-за дисплейника для цифровой подписи (особенно, если пользователь входит в множество групп пользователей). Если отключить конфиг. ключ, то форма ведет себя адекватно.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: Bega (1). |
07.07.2010, 10:44 | #4 |
Участник
|
Сервис\Параметры у меня открывается за 1 секунду. Клиентский комп с 2 Гб оперативки.
Заметил что иногда после долгого программирования клиент выедает всю оперативную память в системе, приходится его перезапускать. Сравнение кода в слоях работает долго, согласен с этим.
__________________
Дмитрий |
|
07.07.2010, 10:45 | #5 |
Участник
|
|
|
07.07.2010, 11:25 | #6 |
Участник
|
Тестовую базу поставили на один сервер (База, АОС, Приложение) - форма Параметры открывалась минут по 5. Рабочий вариант раскидали по трем серверам - форма стала открываться практически мгновенно.
По поводу общих тормозов - помогли переиндексация и обновление статистики на SQL - быстрее стало в несколько раз. |
|
07.07.2010, 12:22 | #7 |
Moderator
|
По поводу торможения формы с параметрами: На самом деле тормозит метод SecuritykeySet.loadUserRights(_ui.Id); Я долго изучал как и когда он тормозит. Тормозит не всегда. Чаще всего тормозит при первом запуске для данного пользователя или когда долго не вызывались никакие операции по данному пользователю. В рекорде - у меня тормозило порядка 5-6 минут (но это при наличии 430 групп). В среднем - подтормаживание занимает порядка 15-30 секунд. Тормозит все это независимо от rollup5. У меня тормозило на самом первой версии 2009ой, даже без SP1.
Самое важное: К сожалению, форма параметров это самое безобидное место в системе, в котором вызов loadUserRights может нагадить. Я видел workflow, в котором цепочка из 4-5 утвеждений не могла отработать быстрее чем за 6-7 часов. События WF застревали в очереди на обработку, поскольку обработчик постоянно вызывал эту функцию чтобы проверить право пользователя на доступ к форме ассоциированной с событием. Еще я видел таблицу eventCUD разросшуюся до 30 Гигабайт, потому что обработчик алертов вызывал эту функцию чтобы проверить имеет ли данный пользователь право на форму ассоциированную с данным табличным алертом... В общем - если у вас тормозит, то отключение цифровой подписи просто скрывает проблему, но не лечит. Если вы не смогли (а я не смог) побороть торможение loadUserRights() готовьтесь к проблемам. Я их смог обойти просто тупо закоментив вызовы проблемной функции и очень надеюсь что никто из пользователей не полезет куда не положено Последний раз редактировалось fed; 07.07.2010 в 12:35. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
07.07.2010, 13:32 | #8 |
Участник
|
Тоже уже думали про комментирование этого метода. Для Workflow и оповещений я вообще не понимаю зачем его использовать - даже если консультант криво их настроит, пользователь получит оповещение на закрытую для него форму и попробует ее открыть - отработают стандартные права доступа. Зачем было огород городить в этих местах?
__________________
Ivanhoe as is.. |
|
07.07.2010, 14:14 | #9 |
Участник
|
А не пробовали кешировать где-нить результат ?
|
|
23.07.2010, 12:02 | #10 |
Участник
|
Если посмотреть, как внутри устроено сравнение, и сопоставить с трешкой, то станет видно, что раньше, к примеру, в те же combobox'ы выбора слоев данные заливались после обработки пары TreeNode'ов и на основании выбора брались эти же либо другие два TreeNode'а, которые уже и сравнивались, а теперь, прежде чем просто появится форма сравнения, в списках на клиенте кэшируются экземпляры объекта со всех слоев. Кроем того, в Performance Monitor от w2k8 r2 очень хорошо видно, как в момент открытия и особенно сравнения на клиента идет очень большой сетевой трафик от АОСа - в течение нескольких секунд передаются данные со скоростью 200-900 kb/s, да еще и отдаются со скоростью 30-150 kb/s. Так что, вероятно, дело в дополнительных накладных расходах из-за изменившейся обработки сравниваемых объектов, а также в том, что 2009-я работает с юникодом (в т.ч. в юникоде хранится исходный текст и т.п.), так что передаваемых данных стало объективно больше.
|
|
|
За это сообщение автора поблагодарили: Bega (1). |
Теги |
ax2009, производительность |
|
Похожие темы | ||||
Тема | Ответов | |||
DAX2009 не дружит с VS2010 | 2 | |||
fed: Cost Explorer in DAX2009 | 3 | |||
Отходы по закупке в DAX2009 | 14 | |||
Вопросы по OLAP в DAX2009 | 9 | |||
Апгрейд существующего приложения на DAX2009 | 3 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|