Производительность Cистем

[Сергей_imported]

Господа, вопрос, собственно, следует из subj. Что скажите, кто имеет большой опыт? Как уже говорилось в теме сравнение ERP-систем, имеется несколько 1С-овских баз которые падают в центральную. Обработка данных с 5-ти магазинов и склада в центре занимает всю ночь. Боюсь, что с открытием еще 3-х магазинов в офисе уже никто не сможет работать, т.к. время обработки стремится к бесконечности с ростом базы. Номенклатура 60тыс. наименований. О Navision'овских системах, точнее уже MSBS'овских слышал разное. Одни говорят, что работают они на порядок быстрее, чем 1С, другие, что даже медленнее. Скажу, что Сервер БД у нас 2-х процессорный (Xeon 2,4 ГГц), 2 Гб оперативки, аппаратный райд и т.д.
Интересно, насколько решает проблему производительности сервер приложений в Аксапте и сопоставимо ли решение для Навижна, скажем, если использовать "в качестве" сервера приложений терминальный сервер, скажем Citrix, напрямую связанный с сервером БД через Гигабитный канал.

[mazzy]

вопрос большой и очень... хм... политизированный.
Поэтому здесь нужно четко определять о чем мы говорим и что имеем в виду.

Вы говорите

Цитата:

несколько 1С-овских баз которые падают в центральную. Обработка данных с 5-ти магазинов и склада в центре занимает всю ночь

Т.е. имеется в виду УРБД или МОД.
Что вы подразумеваете под словом "обработка"?
Время работы УРБД? Время перепроведения для восстановления ТА?

Тут сразу надо сказать, что репликации нет ни в Аксапте, ни в Навижин как... просто такого нет, поскольку все сделано исходя из идеологии централизованной базы.

Однако появится новая вещь типа закрытия склада Которая делается небыстро.

Еще пример, выписка накладных. Вполне возможна ситуация, когда выписка в Аксапте будет делаться медленнее, чем в 1С. Почему? Да потому что в Аксапте действий при выписке может делаться гораздо больше. Если включить проверку кредитного лимита, если включить авторезервирование, если включить провеку отрицательного физического склада, если включить автозамены товаров при продаже, если включить автоподбор ГТД, партий или серийных номеров, если включить автосоздание закупки при продаже...

Т.е. если говорить на пользовательском уровне, то сложно сравнивать скорости систем.

Корректно сравнивать можно на достаточно низком программистском уровне. На низком программистском уровне Аксапта работает с SQL хорошо. Нормально работает на Oracle, что позволяет включать сегментацию. Нормально работает с кэшированием. Умеет кластеризоваться (хотя здесь хотелось бы большего).

Навижин, например, отлично работает со своей технологией SIFT в формате своей базы. Действительно радует. Но при большом количестве пользователей его оптимистические блокировки уже работают плохо.

Но об этом ли вы спрашиваете? О технических ли параметрах?
Наверняка вы спрашиваете, будет ли на вашем оборудовании, ваши сотрудники вашего предприятия работать быстрее? Так?

Если так, то ответ такой: при равном функционале и равном количестве пользователей Аксапта будет работать быстрее Навижин, Навижин будет работать быстрее v7. v7 будет самым медленным.

Вот что будет с v8? Вопрос...

[mazzy]

Цитата:

Сообщение от Сергей

Интересно, насколько решает проблему производительности сервер приложений в Аксапте и сопоставимо ли решение для Навижна, скажем, если использовать "в качестве" сервера приложений терминальный сервер, скажем Citrix, напрямую связанный с сервером БД через Гигабитный канал.

и еще.

Терминальное решение (WTS, Citrix) позволяет снять нагрузку с клиентов и не передавать массивы данных по сети. Все. Другого выигрыша в общем-то и нет.

Трехуровневое решение в Аксапте делает то же самое только своими средствами. Свои средства позволяют сделать обработку более хитрой, интелектуальной... Но по большому счету у вас по прежнему уменьшаются требования к клиенту и снижается нагрузка на сеть.

Поэтому влияние терминального решения на разные системы примерно сопоставимо, если узким место у вас является сеть.

Если же узким местом является другое... хм... место, то надо думать дальше

[dumf_imported]

Вопрос, действительно.. ребром.

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

К сказанному выше хочу добавить следующее.

Можно сравнить 1с по производительности с Navision Attain.
Мне кажется, что эти системы по маштабируемости более или менее одинаковы.
Axapta дает гораздо больше возможностей для наращивания.
В подробности конкретных технологий не хочется углублятся, так как очень много много зависит от задач и тех кто их ставит.

По поводу AOS в Axapta и терминального сервера в связке с Navision Attain.

Однозначно AOS.

Суть простая. Терминальный сервер, это всего лишь возможность работы на слабых клиентских машинах и тонких каналах связи. То есть по сути для базы данных совсем не важно откуда к ней обращаются. (Например, N клиентов, каждый со своей рабочей станции или N клиентов запущенных на терминальном сервере. AOS же по сути занимается распределением и оптимизацией работы этих N клиентов.)

[Dzemon]

Цитата:

Сообщение от Сергей

Обработка данных с 5-ти магазинов и склада в центре занимает всю ночь. Боюсь, что с открытием еще 3-х магазинов в офисе уже никто не сможет работать, т.к. время обработки стремится к бесконечности с ростом базы.

Как я понял, тут речь идет о "филиальной сети". К тому же еще и розничной. А как только появляется розница, так всплывают новые проблемы. И основная проблема - учет чеков продаж в магазинах. Насколько я понял, чеки и др.операции учитываются сразу в центральной базе. Я подойду с известной мне стороны: Навижин + RBO. В этом варианте, каждый магазин учитывает чеки в свойе базе, что, естественно, сокращает время учета. А результаты реплицируются в центральную базу. По такой схеме в Англии работает на Навижине розничная сеть из 800 точек. Терминальный доступ не решит этой проблемы просто из-за огромного количества операций. Т.е. структура должна быть распределенной.

[komar]

Действительно, розница в онлайне не нужна. Пожалуй, единственный случай, когда офлайн однозначно лучше онлайна.

[mazzy]

ну, не единственный...

есть еще нефтяники со спутниковыми каналами, где спутник то появится над горизонтом, то уйдет за горизонт

Но вообще говоря, с выводом не согласен. Тут речь идет не об онлайне/оффлайне, а о том, насколько вообще нужно хранить/реплицировать ВСЕ данные в центре.

Нормальный путь - обмениваться с центром небольшим числом агрегированных взаимосвязанных параметров. Cейчас часто думают, что получим в центр все 100 тыс. проводок, и тут-то мы все и проверим. Не проверим! Среди 100 тыс. проводок скрыть вранье гораздо легче, чем среди нескольких параметров (если они взаимосвязаны). Вопрос только в том... кто разработает эти параметры... кто разработает эти самые внутренние отчетные формы, которым можно верить...

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

Черт, что-то увлекся я. Извините.
Так что насчет производительности?
Может про операторы какие-нибудь поговорим?

[Dzemon]

2Mazzy:
Истинная правда!!!

И самое неприятное, что заставляя внедренцев тащить эту прорву операций в центр, менеджеры/финансисты НИКОГДА не найдут времени и возможно их проанализировать. В лушем случае они получают аналитику по весьма крупным блокам. Дурная голова всему остальному покоя не дает....

[Сергей_imported]

Цитата:

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

Т.е. имеется в виду УРБД или МОД.
Что вы подразумеваете под словом "обработка"?

Имеется ввиду дикл обмена через МОД (подготовка данных, выгрузка, загрузка и т.д.), перепроведение документов, работа нескольких внешних и внутренних обработок, как то: "взаиморасчеты и остатки по поставщикам", которые в стандартном модуле не работают, выгрузка данных на сайт и т.д.

[Сергей_imported]

Цитата:

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

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

Всем спасибо за сообщения. Из вышесказанного я понял, что имеет смысл рассматривать 2 решения: Axapta Retail и Navision с RBO.
Тащить все проводки никто и не собирается, но меня будут интересовать остатки (желательно в On line) и продажи (с определенной дискретностью).
А что значит "критично, когда много одновременных пользователей. 50 одновременных - это много? Притормаживает ли при этом программа (в смысле быстрого вывода информации на экран)?

[komar]

Цитата:

Сообщение от Сергей

А что значит "критично, когда много одновременных пользователей. 50 одновременных - это много? Притормаживает ли при этом программа (в смысле быстрого вывода информации на экран)?

Которая из программ притормаживает? И при каких условиях?
В смысле вывода на экран не должна ни одна притормаживать.

[Dzemon]

Цитата:

Сообщение от Сергей

Всем спасибо за сообщения. Из вышесказанного я понял, что имеет смысл рассматривать 2 решения: Axapta Retail и Navision с RBO.
Тащить все проводки никто и не собирается, но меня будут интересовать остатки (желательно в On line) и продажи (с определенной дискретностью).
А что значит "критично, когда много одновременных пользователей. 50 одновременных - это много? Притормаживает ли при этом программа (в смысле быстрого вывода информации на экран)?

Вообще-то есть еще 3 решение - Микрософт Ретейл, я читал только описание и судя по нему это нечно и за копейки......но про него никто ничего не знает.

При RBO он-лайн остатки можно получить только отчетом, т.к. учет результатов осуществляется в "конце дня".

Экран никогда не тормозит, тормозит учет из-за блокировки учетных таблиц.

[mazzy]

Цитата:

Сообщение от Сергей

...меня будут интересовать остатки (желательно в On line) и продажи (с определенной дискретностью)...

вот-вот.

поговорите с ans'ом. У него тоже руководство хотело видеть остатки онлайн и таки получило их. Спросите его, кто-нибудь эти данные вообще смотрит? А если смотрит, то что с ними делает?

ans, ничего личного.

[mazzy]

Цитата:

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

При RBO он-лайн остатки можно получить только отчетом, т.к. учет результатов осуществляется в "конце дня".

...по Z-отчету.

Кстати, Сергей, у вас кассы или POS'ы?
вы ставите задачу получать остатки действительно онлайн или вам достаточно периодичности z-отчетов?

[Dzemon]

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

[Сергей_imported]

Цитата:

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

[Кстати, Сергей, у вас кассы или POS'ы?
вы ставите задачу получать остатки действительно онлайн или вам достаточно периодичности z-отчетов?

У нас, только не плюйтесь сразу, POS'ы от Kraftway. Поверте, не я их выбирал
Остатки, конечно можно получать и по z-отчетам. On line нужен только для стола справки, чтобы можно было видеть наличие товара по сети и отправить покупателя в тот магазин, где он точно найдет то, что ищет. Если это затруднительно, то On line нужен хотя бы на уровне базы магазина, это-то, надеюсь, не проблема.

Но до конца приемуществ Axapta Retail vs Navision + RBO не понимаю. С одной стороны Аксапта гибче (например есть централизованно-децентрализованное ценообразование и т.д.), производительнее и т.д., с другой Навижн с РБО вроде как обеспечивает необходимые требования, например система дисконтных карт так же предусмотрена. Да и дешевле и быстрее при внедрении. Вот только про производительность приминительно к моей задаче не понял.
Я так понимаю Axapta Retail продвигает Корус (и насколько понял они сами дописали нечто для магазинов, которые передают данные в центр, где и стоит собственно Аксапта). Как мне показалось, лидер в продвижении Навижн + РБО фирма Импакт-софт. И та и другая компания, как и следовало ожидать, хвалят себя и говорят о недовольстве заказчиков от внедрения конкурентов.
У Коруса, вроде бы как, удачное внедрение в сети О'Кей, у Импакта в Азбуке вкуса. Естественно, напрямую с IT-директорами обеих компаний поговорить не получается.

Тяжело, конечно, что называется "не пощупав", сделать выбор, поэтому всячески расчитываю на мнение независимых эксперотв, коими считаю участников данного форума. =)

[mazzy]

Цитата:

Сообщение от Сергей

On line нужен только для стола справки, чтобы можно было видеть наличие товара по сети и отправить покупателя в тот магазин, где он точно найдет то, что ищет

а... вот вы какие... сильно.

а каков процент дефицитного товара от всего ассортимента?

[mazzy]

Цитата:

Сообщение от Сергей

И та и другая компания, как и следовало ожидать, хвалят себя и говорят о недовольстве заказчиков от внедрения конкурентов.
...
Тяжело, конечно, что называется "не пощупав", сделать выбор, поэтому всячески расчитываю на мнение независимых эксперотв, коими считаю участников данного форума. =)

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

Только мне кажется, что вам таки придется вникать в тонкости, "щупать" и таки делать выбор. А кому легко?

[Dzemon]

Замечание: RBO расчитана на OPOS-драйвера для оборудования, либо на фискальные принтеры. Для ваших касс есть OPOS-драйверы? Либо придется оставить существующую кассовую систему, а бэк-офис магазина делать на Навижине и в нее импортировать чеки.
Про Аксапту еще ктоньть расскажет....

[ДК]

Да... коллеги...
Если мы будем БРАТЬСЯ за решение задачи в которой менеджер центрального офиса (ЦО) требует показать ему остаток сухого молока на третьей полке во втором ряду в супермаркете "Урюпинский".......
Существует масса решений именно уровня магазина/супермаркета. На какой угодно платформе.
Существует масса решений как из одной системы донести данные до другой.
Именно как говорит mazzy - нужно думать над разработкой таких форм, спецификаций и требований, которые могли бы дать ЦО возможность УПРАВЛЯТЬ всем бизнесом. А не копаться в 100 проводок.
Посмотрите: во всех огромных розничных сетях на западе ЦО дает РЕКОМЕНДАЦИИ и КРИТЕРИИ ОЦЕНКИ ИХ РАБОТЫ своим магазинам. Но ни кто и не где не управляем магазином в ShitRiver из NN.