alexef: NAV 2009 Scalability, интересный документ - Dynamics CRM: Blogs

Blog bot · 14.01.2009, 09:39

...
На http://thriftysoftwarebuildingteam.com/ можно найти интересный документ (Loking Management Test Results).

Компания пропагандирует свое Locking Management решение.
Приводит сравнительные тесты для NAV 2009 (10,20,40 users). SQL Option.

И не плохие такие результаты производительности на тюнингованном до нельзя NAV видны.

даже утверждают:
Out tests show that NAV will show better performance than AX in similar environment and the same
hardware configuration.

Вообщем интересная информация к размышлению.

Подробнее... http://blogs.technet.com/alexef/archive/20...calability.aspx

**mazzy** · 14.01.2009, 12:00

оказывается это реклама решения Locking Management Solution from Thrifty Software Building Team Ltd
вот только я не понял главного - за счет чего собственно уменьшается время блокировок, каков принцип работы этого решения.

А без этой информации - очередная галимая и пустая реклама.

apanko · 14.01.2009, 13:10

Цитата:

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

оказывается это реклама решения Locking Management Solution from Thrifty Software Building Team Ltd
вот только я не понял главного - за счет чего собственно уменьшается время блокировок, каков принцип работы этого решения.

Even crises has good sides

**mazzy** · 14.01.2009, 13:27

Цитата:

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

Even crises has good sides

Это к чему?

apanko · 14.01.2009, 13:35

К тому, что данную ссылку (http://thriftysoftwarebuildingteam.com) изначально опубликовали в той теме.

**mazzy** · 14.01.2009, 13:45

Цитата:

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

К тому, что данную ссылку (http://thriftysoftwarebuildingteam.com) изначально опубликовали в той теме.

Да, спасибо.
А теперь вот alexef в своем блоге привел.

Но ни одна не делает суть более понятной. Что там реклама, что здесь. Только та была в правильном разделе.

Что-то сравнили. И что? На каких принципах работает эта штука? Объясните, кто знает.

Wizard_imported · 14.01.2009, 15:54

Написано же

Цитата:

Our solution is the set of programming rules and methods that allow NAV system avoid user locking. Theoretically we can make any vertical or custom solution free of user locking by rewriting code based on our rules and methodology.

В том что это теоретически можно сделать, сомнений нет и не было. Те кто хотели уже сделали. Правда, каждый по-своему. И каждый остановился на том этапе, когда производительность стала достаточной. Из контекста Even crises has good sidesможно понять что основная идея - переход на Identity в книжных таблицах. Возможно, ещё комит вставили в функцию получения очередного номера документа ("can occur missing document numbers").
Автор пишет о том, что готов взяться за оптимизацию любой базы. Интересно посмотреть на обещанный результат реальной работы (надеюсь, на приличного веса базе, хотя бы 10млн в 32 таблице). В первую очередь интересует трудоемкость процесса. Ещё несколько смущает упоминание оптимизации бизнес-процессов, но как я понял это не является требованием для достижения заявленной свободы от блокировок.

**mazzy** · 14.01.2009, 16:08

Цитата:

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

можно понять что основная идея - переход на Identity в книжных таблицах.

Что это значит? можно подробнее?

Цитата:

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

Возможно, ещё комит вставили в функцию получения очередного номера документа ("can occur missing document numbers").

Что значит "вставили commit"?
Это вместо одной транзакции выполняется несколько?
А что с целостностью и транзакционностью?

Wizard_imported · 14.01.2009, 16:24

Цитата:

Что значит "вставили commit"?

взяли номер документа (увеличили значение в таблице серии номеров) и закончили транзакцию. В случае отката уже самого создания документа "can occur missing document numbers".

Цитата:

можно подробнее?

Entries (17, 32, ets) в стандарте создаются способом "последний + 1", с написанным в начале юнита LOCKTABLE. убираем это всё, поручаем нумерацию серверу и получим "при учете заказов продажи двумя разными пользователями, записи Книги Операций (...) будет перемешаны"
На мой взгляд, это первое что приходит в голову, когда понимаешь, чем вызваны эти пресловутые блокировки.

apanko · 14.01.2009, 16:30

Цитата:

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

Entries (17, 32, ets) в стандарте создаются способом "последний + 1", с написанным в начале юнита LOCKTABLE. убираем это всё, поручаем нумерацию серверу и получим "при учете заказов продажи двумя разными пользователями, записи Книги Операций (...) будет перемешаны"
На мой взгляд, это первое что приходит в голову, когда понимаешь, чем вызваны эти пресловутые блокировки.

А когда идет откат транзакции - получаются пропуски в книге операций?

**mazzy** · 14.01.2009, 16:32

Цитата:

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

взяли номер документа (увеличили значение в таблице серии номеров) и закончили транзакцию. В случае отката уже самого создания документа "can occur missing document numbers".

Entries (17, 32, ets) в стандарте создаются способом "последний + 1", с написанным в начале юнита LOCKTABLE. убираем это всё, поручаем нумерацию серверу и получим "при учете заказов продажи двумя разными пользователями, записи Книги Операций (...) будет перемешаны"
На мой взгляд, это первое что приходит в голову, когда понимаешь, чем вызваны эти пресловутые блокировки.

угу и получили дырки в номерах.
ок. спасибо. в принципе понятно.

Но действительно ли так работает пресловутое "патентованное средство" и какие последствия имеет их "радикально черный цвет" - непонятно.

Wizard_imported · 14.01.2009, 16:41

Цитата:

А когда идет откат транзакции - получаются пропуски в книге операций?

да, конечно. И нарушается, например, функциональность "регистров" - "от операция Но.", "до Операция Но.". И тогда становится ясно что "The task is quite complex and not trivial" ибо

Цитата:

какие последствия имеет их "радикально черный цвет" - непонятно.

конечно, это мои догадки.
кстати, это всё не решает проблему дедлоков. Но на демо-базе их можно и не словить, поэтому я и хочу видеть рассказ о реальной оптимизационной работе.

finn · 16.01.2009, 09:57

Про отказ от LOCKTABLE и использования "AutoIncrement" свойства для поля "Entry No." видел информацию так же в блоге Jörg A. Stryk.
Правда там рекомендуется делать это с осторожностью великой.....

Вот пост:
http://dynamicsuser.net/blogs/stryk/archiv...sql-server.aspx

Там кроме всего прочего много полезной инфы по теме и интересные комментарии...

finn · 16.01.2009, 12:27

Ну и еще что бы добить тему

Вот обсуждение dynamicsuser.net :
http://dynamicsuser.net/forums/t/25283.aspx

Часть завесы над авторами решения "Locking Management Solution" приоткрывается.
Но все более не понятно как это сделано и, похоже, что это не простая игра с LOCKTABLE.
Известные специалисты рвут на себе волосы не могут поверить в то, что это можно сделать, и обещают тут же стать реселлерами решения как только им покажут реальных клиентов.
С интересом жду развития событий…

P.S.
Где то тут конечно все должно быть не все так идеально, но тем интересней.

**mazzy** · 16.01.2009, 13:28

Цитата:

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

Часть завесы над авторами решения "Locking Management Solution" приоткрывается.
Но все более не понятно как это сделано и, похоже, что это не простая игра с LOCKTABLE.
Известные специалисты рвут на себе волосы не могут поверить в то, что это можно сделать, и обещают тут же стать реселлерами решения как только им покажут реальных клиентов.

В общем, снова подтвердилось, что эта изначально была реклама в стиле
у нас еть такие приборы,
но мы вам о них не расскажем.
но если вы позвоните
то их вам конечно продажем...