AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.12.2006, 19:15   #21  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от Wamr Посмотреть сообщение
а у вас там в join временная табличка не попала случайно
Нее, все постоянные
__________________
--
regards, Oleksandr
Старый 27.12.2006, 19:21   #22  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от glibs Посмотреть сообщение
Ни фига себе... Быстро вставка у вас работать на таком хозяйстве не будет.

Вариант оптимизации — писать в таблицу без индексов, потом копировать в таблицу с индексами. Здесь можно применить и прямой SQL (с RecId уже проблем не будет). Но это очень жесткий (я бы сказал экстремальный) метод.
Ну, зачем себя ограничивать в методах, лишь бы заработало. Универсальностью можно принебречь.

Цитата:
Сообщение от glibs Посмотреть сообщение
Это Аксаптовский то профайлер? Забейте на него, если вы запросы к SQL разбираете. Только время потеряете.
Ну я так и понял... Потому что закономерностей в резуьтатах никаких.
У вас тоже такой опыт был?

Цитата:
Сообщение от glibs Посмотреть сообщение
Так все-таки, если отказаться от вставки — т.е. прогнать скрипт вхолостую — сколько времени уйдет? Просто секундомером замерить нужно без профайлера.

Т.е. закоментарьте строчки
ttsbegin;
this.writePrognosisLines...
prognosisLineList.insertDatabase();
this.prognosisTotals();
ttscommit;

Если будет долго, то бросайте. Нужно будет разбирать сам select.
ОК, попробую.
Проблема четко определить самые тяжелые вещи, много факторов разных.
__________________
--
regards, Oleksandr
Старый 27.12.2006, 20:27   #23  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от Oleksandr
...
Ну я так и понял... Потому что закономерностей в резуьтатах никаких.
У вас тоже такой опыт был?
...
У меня много чего было такого :-)

Профайлер — вещь очень полезная, но для поиска недостатков в коде. Как правило, его имеет смысл начинать использовать, если с запросами уже все ОК, и за счет их ускорения не ожидается ощутимого прироста в производительности.

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

Профайлер больше всего подходит для того, чтобы, например, уменьшить время отклика на форме с 3000 миллисекунд до 500 миллисекунд. И для аналогичных задач. При умелом использовании он позволяет помочь обнаружить причину и долго играющего кода. Примером такого кода может быть цикл с очень большим количеством очень мелких обращений к базе (что затруднительно отловить мониторингом запросов с заданной аппертурой).
__________________
С уважением,
glibs®
Старый 28.12.2006, 07:20   #24  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Еще можно попробовать вставлять не целиком, а порциями по 500-1000 строк - иногда длинные транзакции тормозят
Старый 28.12.2006, 11:40   #25  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от belugin Посмотреть сообщение
Еще можно попробовать вставлять не целиком, а порциями по 500-1000 строк - иногда длинные транзакции тормозят
Да, это вариант. И предположително от большого объема рекординсертлист в памяти может быть своппинг.
__________________
--
regards, Oleksandr
Старый 28.12.2006, 13:06   #26  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от Oleksandr Посмотреть сообщение
Многие. Но в принципе может быть поиожет, таблички нелегкие, почему-то сразу не подумал об этом.
Помогло, практически в два раза уменшилось время, не подумал бы. Таблицы тяжелые. Сейчас еще в 3-тайере попробую
__________________
--
regards, Oleksandr
Старый 29.12.2006, 11:10   #27  
zelen is offline
zelen
Участник
 
64 / 13 (1) ++
Регистрация: 08.11.2004
Адрес: г.Москва
предлагаю такой вариант:
использовать класс Connection, соответственно делаете конекшны к двум БД типа
LoginProperty dbLoginProperty;
Statement statement;
ResultSet rs;
str _query;
;
// соединяемся с источником данных
dbLoginProperty = NEW LoginProperty();
dbLoginProperty.setDSN(parmODBC);
dbLoginProperty.setServer(parmServ);
dbLoginProperty.setDatabase(parmDBServ);
dbLoginProperty.setUsername(parmLogin);
dbLoginProperty.setPassword(parmPass);
dbConnection = new odbcConnection(dbLoginProperty);
и соответственно настраиваете 2-й конекшн
_query = ваш запрос но уже в сиквельной нотации
statement = DBConnection.createStatement();
rs = statement.executeUpdate(_query);
для ваших внутренних вычислений можно добавить еще такое:
while (resultSet.next())
{
тут че нить вычисляете и пишете в другую БД
strfmt("INSERT INTO () VALUES (%2,%3,%4,%5,%6,%7,%8,%9,%10,%11,%12) ",
rs.getString(1) ... и т.п.
}

еще для оптимизации можно всё это дело создать в пакетном классе на сервере, чтобы он отрабатывал в определенное время!
Старый 29.12.2006, 11:18   #28  
zelen is offline
zelen
Участник
 
64 / 13 (1) ++
Регистрация: 08.11.2004
Адрес: г.Москва
можно еще так же настроить ваши БД как линкед сервера, чтобы в одном сиквел запросе мона было сразу делать insert to server.db.table (select from linckedServer.db.table)
Старый 29.12.2006, 12:49   #29  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,241 / 978 (37) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от zelen Посмотреть сообщение
предлагаю такой вариант:
использовать класс Connection, соответственно делаете конекшны к двум БД типа
Зря предлагаете.
1. Если уж пользовать прямое обращение, то лучше использовать стандартные job-ы на SQL-сервере
2. Аксапта не любит когда со стороны лезут в ее базу, даже если на чтение
__________________
Isn't it nice when things just work?
Старый 30.12.2006, 00:52   #30  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от macklakov
...
Зря предлагаете.
...
С этим абсолютно согласен.
Цитата:
Сообщение от macklakov
...
Аксапта не любит когда со стороны лезут в ее базу, даже если на чтение
...
А вот это уже перебор.

Умеючи, можно и напрямую данные выковыривать. Особенно ОЛАПом.
__________________
С уважением,
glibs®
Старый 04.01.2007, 23:04   #31  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
А мне кажеться, что можно попробовать убрать лишние джойны. И hash и lookup по своему хороши, но все равно на таких длинных выборках не сравнятся с заточенными одиночными запросами. Попробуйте, условную табличку "факта" убрать из джойна и сделать плейсхолдер селект в тот момент, когда нужны данные в процедуре обработки. Под этот селект хорошо заточенный индекс.
Старый 06.01.2007, 23:25   #32  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от zelen Посмотреть сообщение
можно еще так же настроить ваши БД как линкед сервера, чтобы в одном сиквел запросе мона было сразу делать insert to server.db.table (select from linckedServer.db.table)
Ну соб-нно эо и была изначальная идея (тлько хотел все переписать на сиквеле). Так вот, сейчас оказывается что основной "боттлнек" - на sql сервере по время выполнения операций (жрет ЦПУ и память). Сам джойн выпоняется быстро, вставка - тоже.
__________________
--
regards, Oleksandr
Старый 06.01.2007, 23:27   #33  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от Torin Посмотреть сообщение
А мне кажеться, что можно попробовать убрать лишние джойны. И hash и lookup по своему хороши, но все равно на таких длинных выборках не сравнятся с заточенными одиночными запросами. Попробуйте, условную табличку "факта" убрать из джойна и сделать плейсхолдер селект в тот момент, когда нужны данные в процедуре обработки. Под этот селект хорошо заточенный индекс.
Проблема не в селекте, уже выяснил. Он исполняется буквадьно пару минут. Основная нагрузка - потом на сиквел вервере, при обработке.
__________________
--
regards, Oleksandr
Старый 06.01.2007, 23:30   #34  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от otkudao Посмотреть сообщение
елки-палки! так вы в 2-х звенке пытаетесь разогнаться? так быстро не будет работать никогда!

Выносите ВСЕ операции с БД
- в трехзвенку,
- на серверную часть,
- в методы с префиксом server (чтобы выполнялись исключительно на сервере.) Если класс (вот не помню, джоб, кажется, только клиентски по исполнению может быть, тогда перенесите методы в класс...) не позволяет своим методам выполняться на сервере, выносите эти методы в static (+ server).

Ускорение (был опыт с отчетами) может достигать десятков раз!
Весь функционал - в одном классе - наследнике RunBaseBatch. Запускается периодически на батч-сервере (только в 2-звенке можно, насколько помню ?).

С отчетами - да, они частично на клиенте исполняются вроде.
__________________
--
regards, Oleksandr
Старый 06.01.2007, 23:34   #35  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
По ссылке - поэксперементировал с buffer size в конфигурации. При значении 2048 было ускорение процентов на 5-10, видимо потому что записи из запроса весьма тяжелые. Не знаю, правда как это может сказатсья на прочей производительности.
__________________
--
regards, Oleksandr
Старый 07.01.2007, 00:20   #36  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
РЕЗЮМЕ НА ЭТОТ ЧАС
Решил немного подытожить, чтобы знания не поропали в дебрях треда .

1. Axapta code profiler нагло врет и жрет ресурсы при больших количествах вызовов/подвызовов и операций с БД . Потратил много времени пытаясь оптимизировать неоптимизируемое, и вообще, пошел по ложному пути. В таких случаях лучше:
  • Замерять ручками с помощью timenow() или gettickcount().
  • Смотреть кто (Client/AOS/SQL) больше берет ресурсов и в какое время.
  • Исползовать SQL trace или сиквельный профайлер для анализа реальных SQL запросов.

Более реальные результаты получились примерно такие:
select < 5% (в зависимости от условий)
операции - 80 %
insert ~ 10%
2. Основной боттлнек был в нагрузке на сиквел сервер при выполнении операций. Все три таблицы из селекта были достаточно тяжелыми (много стринговых полей, и т.д. - отдельное спасибо проектировщикам БД).
Таким образом, добавление field list-a в запросы ускорило обработку в несколько раз (sic) - отдельное спасибо Wamr! Предположительно, сиквелу было легче выделять память, разбивать страницы и т.д.
При этом он не занимал весь 1.25 гиг свободной памяти, хотя при бОльших количествах допускаю возможность своппинга.

3. Время исполнения нелинейно зависит от количества обрабатываемых записей, а выигрыш по времени - условно линейно.

Код:
количество зап.                неоптим.             оптим. 
______________________________________________________________
  1000                     15 сек.                  10 сек
  5000                     5 мин 30 сек             2 мин 10 сек
  ...                        ...                           ...
  80К                      > 10 ч                    3 ч 10 мин

4. Вставка занимала относительного немного времени, несмотря на наличие двух уникальных индексов на таблице, одного как кластерного.

-------------------
Еще раз всем спасибо за помощь
__________________
--
regards, Oleksandr
Старый 07.01.2007, 02:02   #37  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
А что там у вас внутри тогда такое?

Чтение из базы или запись? Или просто математика?

Индексы оптимально подобраны? Запросы оптимизированы? Обращений к базе много за один вызов writePrognosisLines() происходит? Запросы с джоинами или простые? Если с джоинами, то forceplaceholders стоит? Сортировка или группировка есть?

Попробуйте искусственно добавить условие в запрос с основным циклом, чтобы он отработал, например, 3 раза. И посмотрите профайлером, куда уходит время внутри writePrognosisLines().
__________________
С уважением,
glibs®
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
mazzy: Сравнительное тестирование производительности Microsoft Axapta v.3.0. CУБД Microsoft SQL Server 2005 и Microsoft SQL Server 2000 Blog bot DAX Blogs 0 28.10.2006 17:22
Fred Shen: Convert Axapta date type value to datetime type value in SQL Server Blog bot DAX Blogs 0 28.10.2006 16:40
Доступ к VIEW SQL SERVER из Axapta 111andrei DAX: Программирование 13 02.12.2005 11:19
AX-05-020 Axapta Database MS-SQL MadLight DAX: Администрирование 9 12.01.2005 14:52
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:35.