dennis365foroperations: Performance test tool in Dynamics 365 for Finance and Operations

[Blog bot]

Источник: 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/

[trud]

Занятно.
а есть у кого-нибудь доступ к АХ, где база расположена не на обычном SQL, а на SQL Azure(т.е. это как я понимаю будет прод или сандбокс). можете там запустить это и сравнить
только к кол-ву записей прибавить нолик(чтобы было 10к, а не 1к)
у меня на локальной дев машине такие результаты(core i7, SSD Samsung)

Quote:

********* 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

[fed]

Запустил в нашем 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]

Вообще задержки в операциях с большим сетевым обменом - ожидаемые. Но задержки в операциях типа insert_recordset или update_recordset - это сюрприз. Предположу что наш конкретный Sandbox (на 20 пользователей) крутится на чем-то типа Intel Atom в блейде...

[Ivanhoe]

Так в соглашении MS нигде не сказан SLA по производительности только по доступности.

Очень интересна практика решения проблем по скорости. Неужели будет ответ "вот сча дискетку доформатирую, тьфу, подождите еще пару дней пока закроется склад и продолжайте работу"?

[belugin]

Я знаю что в prod и UAT - 3box - там SQL сервер на отдельной машине. Это может влиять (даже то, что локально named pipes а в другую машину tcp/ip)

[fed]

Quote:

Originally Posted by belugin

Я знаю что в prod и UAT - 3box - там SQL сервер на отдельной машине. Это может влиять (даже то, что локально named pipes а в другую машину tcp/ip)

Я в принципе согласен что при работе с сетевой машиной, операции массовой вставки/обновления/чтения должны больше времени занимать. Но мне все-таки кажется что пятикратная разница - это перебор. Надо бы посмотреть, какой там размер записи, но если предположить что, например, 100 байтов, то тогда отправка 10000 записей - это с накладняком - мегабайта полтора. Даже на 10 мегабитной сети допотопной, такой объем пересылался секунд за 5, а не за 15. Так что похоже что у них там стоит между AOS и SQL канал с большими задержками и пропускной способностью мегабита в два.
Кроме того - удивляет время на recordset-based operation и на RecordInsertList(). Первые должны выполняться вообще за одно сетевое обращение к серверу, вторая должна приводить к отсылке десятка-полутора крупных пакетов, к тому же асинхронно передаваемых.

[trud]

Quote:

Originally Posted by belugin

Я знаю что в prod и UAT - 3box - там SQL сервер на отдельной машине. Это может влиять (даже то, что локально named pipes а в другую машину tcp/ip)

по идее если другая машина подключена гигабитным кабелем напрямую к АОСу, это не должно особо влиять. другое дело, если АОС пытается обратиться к SQL Azure который может быть расположен в другом сегменте сети и сигнал проходит через кучу роутеров а то и вообще через интернет(и плюс обрабатывается еще и сервисом до ухода запроса в SQL)

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

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

[Vadik]

Quote:

Originally Posted by 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) конечно доставляет

[trud]

а для 10к можете сделать? (у вас 1000)

[Vadik]

Quote:

Originally Posted by trud

по идее если другая машина подключена гигабитным кабелем напрямую к АОСу, это не должно особо влиять. другое дело, если АОС пытается обратиться к SQL Azure который может быть расположен в другом сегменте сети и сигнал проходит через кучу роутеров а то и вообще через интернет

Ну, инстанс SQL Server-а должен по идее быть в том же DC с нормальной латентностью и на read-only сценариях вполне пристойно выступает (по Select on Non-unique index разница с T1 менее чем в два раза). А вот INSERT/UPDATE на always on с похоже что таки синхронным коммитом на инстанс в другом регионе конечно проседает

[Vadik]

Quote:

Originally Posted by 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

[fed]

Меня больше всего интересует - почему в tempDb такая небольшая разница между Azure SQL и локальным SQL. Такое ощущение что у них в Azure какой-то мегалоггинг, который огромное время занимает. По обычной БД он срабатывает, а по tempdb - нет.
Хотя с другой стороны и по select'ам из tempDB разница небольшая, что вообще необъяснимо в моих пределах понимания.
P.S. Ооо - прочитал идею Vadik насчет синхронного коммита в другой регион. Ну да - вариант интересный и задержки по записи в обычную БД легко объясняет. Но задержки по чтению - как-то не очень.

[Logger]

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

[Logger]

А кто-нибудь пробовал портировать этот инструмент на предыдущие версии аксапты, 2012 и 2009 ?
Интересно было бы померяться датацентрами.

Можете поделиться?

[Blog bot]

Источник: https://i-neti.ru/blog/424
==============






подробнее



Источник: https://i-neti.ru/blog/424

[skuull]

Quote:

Ух ты, средство тестирования производительности!

На этом можно было бы и закончить.

[twilight]

И какая практическая польза от этого теста? )

[trud]

Quote:

Originally Posted by twilight

И какая практическая польза от этого теста? )

Кстати я понял , неплохая статья по тестированию SQL Azure и сравнению его со скоростью SQL на ноутбуке
http://cdn2.hubspot.net/hubfs/233452...1-2017-ENG.pdf
т.е. у них получился просто огромный разброс в скорости (500%) в зав-ти от датацентра, по видимому чтобы это хоть как-то понимать, мс и создала этот тест

Quote:

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.

Quote:

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]

Вопрос к модераторам
Может объединить темы
dennis365foroperations: Performance test tool in Dynamics 365 for Finance and Operations
i-neti: Средство тестирования производительности в Dynamics 365 for Finance and Operations
Все равно речь идет об одной статье и об одном и том же инструменте.