![]() |
#1 |
Участник
|
Компания, осуществляющая внедрение разводит руками - одноврменный учет невозможен из-за блокировки учетных таблиц. Результат - один пользователь учитывает -> второй ждет
|
|
![]() |
#2 |
Участник
|
Да, именно так.
Уменьшайте время блокировки данных. Либо программно, либо увеличивая мощность железа. Для Аксапты методика повышения производительности описана здесь http://axapta.mazzy.ru/lib/querytuning/ http://axapta.mazzy.ru/lib/mssqlsetup2/ http://axapta.mazzy.ru/lib/adjustment/ http://axapta.mazzy.ru/lib/dbgrowthsolution/ Для Навижина похоже, но есть особенности. Во-первых, разберитесь с узкими местами (снимите данные счетчиков), во-вторых, разберитесь с индексами. В Навижине многие индексы можно выключить, много чего включить дополнительно. Но включать/выключать индексы можно только на основании данных измерения производительности. |
|
![]() |
#3 |
Moderator
|
Да, именно так.
Ну с двумя пользователями это может быть и не заметно (хотя, если документ длинющий можно и заметить), а десяток пользователей точно не могут. Кроме увеличения мощности железа, это может помочь, но не на 100%. Можно еще попробовать пакетный учет - есть специальное задание - отбираешь нужные документы и учитываешь их одним махом. пользователь может ставить признак ("к учету"), а специально написанная процедурка отбирает такие документы и учитывает. При такой схеме ( и "правильной" мощности железа ![]() Еще можно сократить длину строк в документе. Так журнал из 100 строк учтется в несколько раз быстрее, чем из 1000. Так что можно дробить документ (вручную или автоматически), определяя оптимальный его размер |
|
![]() |
#4 |
Участник
|
dmites,
а что подразумевается под "сложным складом"? Конечно, первым делом надо посмотреть на железо. Но, хорошо бы иметь своего человека, который бы мог пошариться по коду учета и оптимизировать его, выкуинв лишние LOCKTABLE, COMMIT. В особенности, если стандартный код был сильно расширен/изменен. Работа временами муторная (за нее берутся неохотно), но дает порой хороший результат. |
|
![]() |
#5 |
NavAx
|
Поддерживаю gala. Если юзеры будут не учитывать документы, а, так сказать, ставить их в очередь на учет, то все будет гораздо лучше
![]()
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
![]() |
#6 |
Участник
|
Тож поддерживаю вариант отложенного учета.
|
|
![]() |
#7 |
Участник
|
Не всегда можно делать пакетный учета, т.к. пока товар не купить его не переместить, пока не переместишь не продашь и т.д. и т.п.
Учитывать такие документы нужно в порядке заведения. Зато небольшое колдовство над КЮ 12451 (даже не трогая 22) позволяет увеличть скорость учета внутренних перемещений, списания, инвентаризации, оприходования в 3-7 раз!!! Конечно, в этом случае второй пользователь все-равно будет ждать, но гораздо меньше. |
|
![]() |
#8 |
Участник
|
Вот статистика к предыдущему сообщению.
|
|
![]() |
#9 |
Moderator
|
Цитата:
Хорошо, конечно, если только акты списания такого объема, а когда все документы по системе большие, да еще их и много.... Что делать, сколько КЮ колдовать ![]() ![]() Да и колдун нужен хороший ![]() Да и переход на новую версию весьма сомнителен Кстати в 4.0 указанного КЮ не обнаружино.. ![]() Так что мне кажется, что это крайний случай, когда ничего другого не поможет.... |
|
![]() |
#10 |
NavAx
|
Цитата:
Кстати в 4.0 указанного КЮ не обнаружино..
![]()
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
![]() |
#11 |
Участник
|
Цитата:
Сообщение от gala
![]() А что именно Вы правите? есть какие-то общие рекомендации?
Хорошо, конечно, если только акты списания такого объема, а когда все документы по системе большие, да еще их и много.... Что делать, сколько КЮ колдовать ![]() ![]() Да и колдун нужен хороший ![]() Да и переход на новую версию весьма сомнителен Кстати в 4.0 указанного КЮ не обнаружино.. ![]() Так что мне кажется, что это крайний случай, когда ничего другого не поможет.... То сначала рекомендаций просите, то крайним случаем обзываете. Нелогично. Теперь по-порядку. По-поводу рекомендаций. Сервис - Монитор клиента - Старт. Учитываем критический документик. Сервис - Монитор клиента - Стоп. Ищем критические точки по времени выполнения. Собственно колдуем и тестируем. По-поводу количества КЮ. Если все документы большие то начинать нужно по порядку с самого критического. Ускорив учет одного типа документа вам будут ясны критические места и в других документах. А КЮ над которыми имеет смысл колдовать не так много и эффект от колдовства больше будет чем от железа. По-поводу колдуна. Без него сейчас никуда. Боюсь даже до оптимизации не добраться ![]() По-поводу новой версии. Сочуствую вашим клиентом, если они работают на голом Кронусе. Если это не так (я в этом практически не сомневаюсь), то сомнение отпадает само собой ![]() По-поводу крайнего случая. На все выпады ответил, поэтому, не вижу ничего крайнего. И остатки сразу видны и учет быстро идет и порядок докуметов не нарушается. Поэтому мне крайним больше представляется пакетный учет. Вообщем все ваши агрументы это лапша ленивого кодера и консультанта для клиента. ![]() |
|
![]() |
#12 |
Moderator
|
Цитата:
Никто не говорит, что в код лезть не надо (Это Navision ![]() Просто всегда у решения должна быть альтернатива. Цитата:
- сократить количество строк в документах - пакетный учет - колдовтство на учетными КЮ - еще индексы можно пооптимизировать и по-перестраивать... - upgrade железа Цитата:
![]() Пакетный - это же не раз в день. Можно настроить и каждый час и пол-часа. Иногда это даже для пользователей удобно бывает...... |
|