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

[belugin]

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

[fed]

Цитата:

Сообщение от belugin

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

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

[Vadik]

Цитата:

Сообщение от 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]

Цитата:

Сообщение от 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

[trud]

Цитата:

Сообщение от belugin

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

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

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

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

[Vadik]

Цитата:

Сообщение от trud

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

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

[wojzeh]

Цитата:

Сообщение от trud

надо выбрать все что надо, потом разнести и отправить результат

звучит, как вызов сервиса. мож, так и надо зарефакторить?