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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.10.2017, 16:11   #1  
Blog bot is offline
Blog bot
Участник
 
19,717 / 666 (62) +++++++
Регистрация: 28.10.2006
dennis365foroperations: Performance test tool in Dynamics 365 for Finance and Operations
Источник: https://dennis365foroperations.blog/...nd-operations/
==============

With the release of Platform Update 5 a small feature called ‘Performance test’ was introduced as part of the System Administration module. To date, I have not found any official documentation that provides any information on this feature. That’s why I thought it could be helpful to write a blog about this feature.



So, hidden in plain sight in the System Administration module, you will find two menu items. One is the ‘Run performance tool’, under the Periodic tasks section, and the other is the ‘Configure performance tool’ under the Setup section. I believe the menu item to set the configuration was introduced in a later update, but have no older environment available to validate this.

Wow, a performance test feature!

At first glance, you would expect a lot of a feature called ‘Performance test’. However, this feature only allows you to perform a quick performance check on all of the common database actions, such as inserting, updating, deleting or querying records, and should therefore just be regarded as another tool in the toolbox of the (technical) consultant or system administrator. The functionality does not allow you to test specific parts of the application or test custom code but can be used just to do a quick check on an environment.

Configure performance tool

The ‘Configure performance tool’ menu option allows you to set the server and database name and optionally enter user credentials. The ‘Validate’ option allows you to validate the database connection, of which the output is shown in this form allowing you to validate if the connection can be made. Nothing more.



Running the performance tool

When navigating to the ‘Run performance test’ menu item, you will find the following form. It gives you a lot of options to set test options, most of them to either include or exclude a specific test scenario, such as inserting, updating or deleting records as part of the data manipulation tests, or querying cluster indexes or non-unique indexes as part of the query test. You are also able to turn on or off the use of TempDB or InMemory tables.



As per standard, all options are enabled and there is a standard value of 1000 in the ‘Record count to test’ field. You can manipulate this value anywhere from 1 to 100.000, which is the maximum. Mind you that the average running time of 1000 record in the test will be around one minute, so testing with a record count of 100.000 records could take up around 100 minutes, which is over 1 1/2 hour.

After having changed any of the values, or not, you can start the performance test. The results of each of the test steps will be appended to the results section in the same form. After the performance test run has been completed, it will look somewhat like this:



For each of the test option a single line will be appended to the results log, showing the test result information.




Источник: https://dennis365foroperations.blog/...nd-operations/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 13.10.2017, 04:15   #2  
trud is offline
trud
Участник
Лучший по профессии 2017
 
486 / 362 (13) ++++++
Регистрация: 07.06.2003
Занятно.
а есть у кого-нибудь доступ к АХ, где база расположена не на обычном SQL, а на SQL Azure(т.е. это как я понимаю будет прод или сандбокс). можете там запустить это и сравнить
только к кол-ву записей прибавить нолик(чтобы было 10к, а не 1к)
у меня на локальной дев машине такие результаты(core i7, SSD Samsung)

Цитата:
********* Large buffer read **************
LargeBufferReads: Selected 1000 records in 230ms.
********* Test run with 10000 Records **************
Insert : 2361
Select on ClusteredIndex : 730
Select on Unique index with cache hit: 177
Select on Unique index without cache hit : 4951
Select on Non-unique index : 5327
Tempdb Temp table Inserts : 795, Selects : 97
inMemory Temp table (AOS) Inserts : 793, Selects : 109
SGOC Inserts : 4942, SGOC Lookups (25) times each entry : 571
Update : 7632
Inserts thru recordInsertList : 2650
Insert RecordSet : 646
Update RecordSet : 474
Delete From : 430
Старый 13.10.2017, 09:53   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,181 / 4007 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Запустил в нашем UAT Sandbox с базой в Azure SQL:
Код:
********* Large buffer read **************
LargeBufferReads: Selected 1000 records in 1169ms.
********* Test run with 10000 Records **************
Insert : 16811
Select on ClusteredIndex : 6521
Select on Unique index with cache hit: 141
Select on Unique index without cache hit : 59388
Select on Non-unique index : 59859
Tempdb Temp table Inserts : 986,  Selects : 64
inMemory Temp table (AOS) Inserts : 881,  Selects : 75
SGOC Inserts : 54834,  SGOC Lookups (25) times each entry : 471
Update  : 76000
Inserts thru recordInsertList : 17995
Insert RecordSet : 1416
Update RecordSet : 1066
Delete From : 1007
P.S. Сравнил результаты уже после того как запостил. Хотел прокомментировать - но приличных слов не хватило.

Последний раз редактировалось fed; 13.10.2017 в 09:56.
За это сообщение автора поблагодарили: Logger (3).
Старый 13.10.2017, 10:00   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,181 / 4007 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Вообще задержки в операциях с большим сетевым обменом - ожидаемые. Но задержки в операциях типа insert_recordset или update_recordset - это сюрприз. Предположу что наш конкретный Sandbox (на 20 пользователей) крутится на чем-то типа Intel Atom в блейде...
Старый 13.10.2017, 10:27   #5  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,577 / 1792 (67) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Так в соглашении MS нигде не сказан SLA по производительности только по доступности.

Очень интересна практика решения проблем по скорости. Неужели будет ответ "вот сча дискетку доформатирую, тьфу, подождите еще пару дней пока закроется склад и продолжайте работу"?
__________________
Ivanhoe as is..
Старый 13.10.2017, 10:56   #6  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,011 / 2151 (80) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Я знаю что в prod и UAT - 3box - там SQL сервер на отдельной машине. Это может влиять (даже то, что локально named pipes а в другую машину tcp/ip)
Старый 13.10.2017, 11:21   #7  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,181 / 4007 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от belugin Посмотреть сообщение
Я знаю что в prod и UAT - 3box - там SQL сервер на отдельной машине. Это может влиять (даже то, что локально named pipes а в другую машину tcp/ip)
Я в принципе согласен что при работе с сетевой машиной, операции массовой вставки/обновления/чтения должны больше времени занимать. Но мне все-таки кажется что пятикратная разница - это перебор. Надо бы посмотреть, какой там размер записи, но если предположить что, например, 100 байтов, то тогда отправка 10000 записей - это с накладняком - мегабайта полтора. Даже на 10 мегабитной сети допотопной, такой объем пересылался секунд за 5, а не за 15. Так что похоже что у них там стоит между AOS и SQL канал с большими задержками и пропускной способностью мегабита в два.
Кроме того - удивляет время на recordset-based operation и на RecordInsertList(). Первые должны выполняться вообще за одно сетевое обращение к серверу, вторая должна приводить к отсылке десятка-полутора крупных пакетов, к тому же асинхронно передаваемых.
Старый 13.10.2017, 15:34   #8  
trud is offline
trud
Участник
Лучший по профессии 2017
 
486 / 362 (13) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от belugin Посмотреть сообщение
Я знаю что в prod и UAT - 3box - там SQL сервер на отдельной машине. Это может влиять (даже то, что локально named pipes а в другую машину tcp/ip)
по идее если другая машина подключена гигабитным кабелем напрямую к АОСу, это не должно особо влиять. другое дело, если АОС пытается обратиться к SQL Azure который может быть расположен в другом сегменте сети и сигнал проходит через кучу роутеров а то и вообще через интернет(и плюс обрабатывается еще и сервисом до ухода запроса в SQL)

был подкаст если не ошибаюсь брали интерьвю у Integen, где они рассказывали что у первого клиента было все совсем плохо, потом кто-то что-то из MS подкрутил и стало на порядок лучше. интерестно конечно что, возможно как раз и перевели с SQL Azure на обычный SQL

еще на тренинге для разработчиков решений(2 года назад) выступал товарищ ответственный за переход с SQL на SQL Azure и по его словам ваша эта АХ вообще неправильно работает, типа выбирает данные в процессе разносок, посылая даже при разноске небольшого заказа миллионы запросов. а надо выбрать все что надо, потом разнести и отправить результат
Старый 13.10.2017, 15:36   #9  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,311 / 1339 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
Я в принципе согласен что при работе с сетевой машиной, операции массовой вставки/обновления/чтения должны больше времени занимать. Но мне все-таки кажется что пятикратная разница - это перебор
У тебя есть в продуктиве инстансы "все-в-одном" - AOS, SQL Server, TS ? Если нет, то сравнивать "нормальные" топологии с T1 - бессмысленно. Ты развернул таки on-prem ? Вот с его с sandbox-ом и сравнивай

У меня:

DEV
********* Large buffer read **************
LargeBufferReads: Selected 1000 records in 780ms.
********* Test run with 1000 Records **************
Insert : 382
Select on ClusteredIndex : 146
Select on Unique index with cache hit: 11
Select on Unique index without cache hit : 713
Select on Non-unique index : 901
Tempdb Temp table Inserts : 86, Selects : 6
inMemory Temp table (AOS) Inserts : 71, Selects : 7
SGOC Inserts : 678, SGOC Lookups (25) times each entry : 59
Update : 1103
Inserts thru recordInsertList : 347
Insert RecordSet : 463
Update RecordSet : 212
Delete From : 66

SANDBOX

********* Large buffer read **************
LargeBufferReads: Selected 1000 records in 1721ms.
********* Test run with 1000 Records **************
Insert : 2659
Select on ClusteredIndex : 1000
Select on Unique index with cache hit: 12
Select on Unique index without cache hit : 10144
Select on Non-unique index : 10712
Tempdb Temp table Inserts : 125, Selects : 6
inMemory Temp table (AOS) Inserts : 99, Selects : 7
SGOC Inserts : 9300, SGOC Lookups (25) times each entry : 41
Update : 12371
Inserts thru recordInsertList : 2868
Insert RecordSet : 208
Update RecordSet : 161
Delete From : 144

Хотя Insert (382 vs 2659) конечно доставляет
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: Logger (1).
Старый 13.10.2017, 15:40   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
486 / 362 (13) ++++++
Регистрация: 07.06.2003
а для 10к можете сделать? (у вас 1000)
Старый 13.10.2017, 15:46   #11  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,311 / 1339 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
по идее если другая машина подключена гигабитным кабелем напрямую к АОСу, это не должно особо влиять. другое дело, если АОС пытается обратиться к SQL Azure который может быть расположен в другом сегменте сети и сигнал проходит через кучу роутеров а то и вообще через интернет
Ну, инстанс SQL Server-а должен по идее быть в том же DC с нормальной латентностью и на read-only сценариях вполне пристойно выступает (по Select on Non-unique index разница с T1 менее чем в два раза). А вот INSERT/UPDATE на always on с похоже что таки синхронным коммитом на инстанс в другом регионе конечно проседает
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 13.10.2017 в 16:15.
За это сообщение автора поблагодарили: fed (3), mazzy (2).
Старый 13.10.2017, 16:09   #12  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,311 / 1339 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
а для 10к можете сделать? (у вас 1000)
да лехко

DEV

********* Large buffer read **************
LargeBufferReads: Selected 1000 records in 370ms.
********* Test run with 10000 Records **************
Insert : 3498
Select on ClusteredIndex : 888
Select on Unique index with cache hit: 110
Select on Unique index without cache hit : 6933
Select on Non-unique index : 7891
Tempdb Temp table Inserts : 813, Selects : 61
inMemory Temp table (AOS) Inserts : 818, Selects : 75
SGOC Inserts : 6874, SGOC Lookups (25) times each entry : 576
Update : 10951
Inserts thru recordInsertList : 3360
Insert RecordSet : 560
Update RecordSet : 543
Delete From : 4611

SANDBOX

********* Large buffer read **************
LargeBufferReads: Selected 1000 records in 1611ms.
********* Test run with 10000 Records **************
Insert : 26555
Select on ClusteredIndex : 10094
Select on Unique index with cache hit: 125
Select on Unique index without cache hit : 100669
Select on Non-unique index : 100839
Tempdb Temp table Inserts : 959, Selects : 75
inMemory Temp table (AOS) Inserts : 913, Selects : 81
SGOC Inserts : 90174, SGOC Lookups (25) times each entry : 416
Update : 128997
Inserts thru recordInsertList : 27578
Insert RecordSet : 1499
Update RecordSet : 1095
Delete From : 1153
__________________
-ТСЯ или -ТЬСЯ ?
Старый 13.10.2017, 18:04   #13  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,181 / 4007 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Меня больше всего интересует - почему в tempDb такая небольшая разница между Azure SQL и локальным SQL. Такое ощущение что у них в Azure какой-то мегалоггинг, который огромное время занимает. По обычной БД он срабатывает, а по tempdb - нет.
Хотя с другой стороны и по select'ам из tempDB разница небольшая, что вообще необъяснимо в моих пределах понимания.
P.S. Ооо - прочитал идею Vadik насчет синхронного коммита в другой регион. Ну да - вариант интересный и задержки по записи в обычную БД легко объясняет. Но задержки по чтению - как-то не очень.

Последний раз редактировалось fed; 13.10.2017 в 18:08.
Старый 13.10.2017, 22:40   #14  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,921 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Да может просто темпдб на хорошую стойку смотрит, а обычная база - на гэ.
И всего делов
Старый 14.10.2017, 08:34   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,921 / 1540 (57) ++++++++
Регистрация: 12.10.2004
А кто-нибудь пробовал портировать этот инструмент на предыдущие версии аксапты, 2012 и 2009 ?
Интересно было бы померяться датацентрами.

Можете поделиться?
Старый 22.11.2017, 13:11   #16  
Blog bot is offline
Blog bot
Участник
 
19,717 / 666 (62) +++++++
Регистрация: 28.10.2006
i-neti: Средство тестирования производительности в Dynamics 365 for Finance and Operations
Источник: https://i-neti.ru/blog/424
==============






подробнее



Источник: https://i-neti.ru/blog/424
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 22.11.2017, 21:26   #17  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
358 / 331 (12) ++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Ух ты, средство тестирования производительности!
На этом можно было бы и закончить.
За это сообщение автора поблагодарили: twilight (1), mazzy (2).
Старый 22.11.2017, 21:40   #18  
twilight is offline
twilight
MCTS
MCBMSS
 
694 / 126 (6) +++++
Регистрация: 17.10.2004
Адрес: Москва
И какая практическая польза от этого теста? )
__________________
I could tell you, but then I would have to bill you.
Старый 28.11.2017, 05:32   #19  
trud is offline
trud
Участник
Лучший по профессии 2017
 
486 / 362 (13) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от twilight Посмотреть сообщение
И какая практическая польза от этого теста? )
Кстати я понял , неплохая статья по тестированию SQL Azure и сравнению его со скоростью SQL на ноутбуке
http://cdn2.hubspot.net/hubfs/233452...1-2017-ENG.pdf
т.е. у них получился просто огромный разброс в скорости (500%) в зав-ти от датацентра, по видимому чтобы это хоть как-то понимать, мс и создала этот тест

Цитата:
The results for both, the physical and virtual machines, shows that the execution time is significantly lower/faster than for the Azure Premium P2 Tier. Only the execution time for Azure Premium P2 database, located in West Europe, is comparable to results from physical and virtual machines, but still 50 % slower than the slowest servers.
Цитата:
For the Azure Basic databases, there was a 20% performance difference between the three tested locations (West Europe, West Japan and West US). For Standard S3 databases the difference had grown to 25%, while on Azure Premium P2 databases the performance difference was a staggering 500%. When the same test takes 5 times as longer on one database than the other, given the same DTU strength, it’s
surprising that it can be sold as the same product. So in other words, ordering the same service at different locations you may end up with completely different underlying hardware.
За это сообщение автора поблагодарили: Logger (3), EVGL (5), fed (5), mazzy (2).
Старый 03.12.2017, 11:11   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,921 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Вопрос к модераторам
Может объединить темы
dennis365foroperations: Performance test tool in Dynamics 365 for Finance and Operations
i-neti: Средство тестирования производительности в Dynamics 365 for Finance and Operations
Все равно речь идет об одной статье и об одном и том же инструменте.
Теги
performance, performance test tool

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
jaestevan: Microsoft Dynamics 365 for Operations Blog bot DAX Blogs 0 02.11.2016 01:11
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 15 Blog bot Dynamics CRM: Blogs 1 10.02.2016 10:26
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 17 Blog bot Dynamics CRM: Blogs 0 10.05.2014 06:30
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 16 Blog bot Dynamics CRM: Blogs 0 23.01.2014 03:15
Platform updates overview - 3.70.B - NAV2009 R2 Blog bot Dynamics CRM: Blogs 0 07.02.2011 22:06
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:49.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.