Про длительность пересчета заказа

[А.Х.]

Поделитесь, пож., статистикой: сколько времени занимает полный пересчет заказа из 50 позиций с изделиями ПВХ?

Т.е. есть набранный сохраненный заказ, открыли, нажали "Рассчитать" - через какое время процесс расчета завершится?

Полный пересчет: расчет спецификаций материалов, работ, цен, скидок, м.б. предупреждений по статическим нагрузкам и т.п.

 

У нас, в зависимости от мощности компьютера - от 1 до 3х мин на заказ. И еще 10 секунд на сохранение всех изменений в базу.

(при этом на 1 позицию приходится ~200 записей в разных таблицах).

 

Программа не важна, хотелось бы оценить ситуацию "со стороны пользователей".

У кого-нибудь это происходит хотя бы в два раза быстрее?

[dvim]

Какая программа, какая СУБД ?

50 ПВХ окон быстрее 1 минуты - могут и СО2006 и Профокна и ПС3.

Последние 2 - в локальном или терминальном режиме .

 

Просто все настраивается. Профсегментовскому софту очень помогает SSD.

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

[А.Х.]

Хорошо, зайду с другой стороны

С т.з. пользователей - 2 мин на пересчет заказа из 50 позиций ПВХ - это много или мало?

[dvim]

Не мало, но терпимо.

 

С тз пользователей важнее время просчета заказа частнику - до 5 окон с комплектацией.

Тут больше 15-20 секунд ИМХО плохо.

[Леха]

Не мало, но терпимо.

 

С тз пользователей важнее время просчета заказа частнику - до 5 окон с комплектацией.

Тут больше 15-20 секунд ИМХО плохо.

 

Фигню говорите.

 

способность давать ответы в процессе разговора не говорит ни о профессионализме ни о расторопности а только о заранее заготовленных ответах.

 

чем быстрее ваш клиент получит ответ о цене тем меньше шансов что он станет вашим клиентом.

 

в идеале цену клиент должен получить только при окончательном расчете

[А.Х.]

Опять же, речь не об ответе клиенту.

Только восприятие менеджерами по продажам скорости работы программы.

[Rexther]

 

Фигню говорите.

 

способность давать ответы в процессе разговора не говорит ни о профессионализме ни о расторопности а только о заранее заготовленных ответах.

 

чем быстрее ваш клиент получит ответ о цене тем меньше шансов что он станет вашим клиентом.

 

в идеале цену клиент должен получить только при окончательном расчете

Зачем путать теплое и мягкое?

Скорость расчета - это одно, а скорость ответа менеджером Заказчику - это вовсе иное.

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

Вопрос КАК и КОГДА расчетными данными воспользуется тот кто пользуется инструментом, в данном случае менеджер, не относится к вопросам функционирования ПО вообще никак. Это вопрос организации продаж, обученности конкретного менеджера и т.д.

[Леха]

ничего я не путаю.

 

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

Ошибочно думать что клиент хватается за ПЕРВОГО кто дает цену - как раз НАОБОРОТ: самые высокие шансы получить заказ у последних. При равной цене и качестве.

 

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

 

а считать миллисикунды - это вообще бред

[Леха]

и еще насчет "удобства менеджеров" - программа это не кресло, скорость работы программмы во многом зависит от компьютера, мощности сервера и загруженности сети, и от оптимизации базы.

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

[Rexther]

ничего я не путаю.

 

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

Ошибочно думать что клиент хватается за ПЕРВОГО кто дает цену - как раз НАОБОРОТ: самые высокие шансы получить заказ у последних. При равной цене и качестве.

 

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

 

а считать миллисикунды - это вообще бред

 

Вот как раз твое пояснение и показывает, что ты говоришь о технологии продаж. А вопрос в теме по технологии работы программы. Ты говоришь об организации производства, а тут спрашивают о скорости вращения фрезы - фигурально выражаясь ...

 

На счет "одинаковости" всех программ тоже не верно, не вполне так ...

И еще: скорость работы программы, конечно зависит от железа, от настроек сети и пр. внешних факторов. Но, во-первых есть еще внутренние алгоритмы, которые могут иметь и вносить определенные ограничения. При чем такие что никаким железом не лечатся. А во-вторых удобство пользования программой важный показатель. И более удобная программа, при прочих равных, будет "быстрее", чем не удобная.

[Леха]

по моему мнению - программы можно разделять на более и менее НЕудобные.

 

ИМХО наиболее человечий интерфейс имеет СО. ПС например более неудобен. Но ожидать от инженерного калькулятора красоты и эргономики неразумно. так что миримся с его интерфейсовскими неудобствами.

 

ты , Костя, прав в части что

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

н общий принцип ТС в том что менеджерам надо чтобы ткнул - и она сама посчитала.

у меня своих таких менеджеров полтора десятка плюс дилеры и я каждый день с ними воюю.

 

Проблема, считаю не стоит выеденного яйца , и на все "хотелки" могу только ответить "идите - работайте!"

 

почему? именно потому что я рассматриваю вопрос со стороны организации продаж и производства. Было бы замечательно если бы штаны сами на нас по утрам запрыгивали и ремни сами затягивались - но это фантазии тех кому нечем заниматься, я это так понимаю.

 

Ты, Костя, пытаешься ответить как технарь на вопросы которые тебе вообще не должны задаваться. Зря теряешь время.

 

Лучше работайте над системой быстрых отчетов, потому что встроенные профстроевские - слишком уж мощный иструмент чтобы разобраться в нем без законченного программистского образования. Нужно чтобы отчеты мог проектировать такой лопух как я... Иначе в них нет смысла.

[Rexther]

По моему пониманию ТС - разработчик ПО. И просто хочет сравнить то время, которое затраичвает его программа на расчет с тем временем, которое уходит на тот же процесс у других программ.

 

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

 

А чем конкретно СО удобнее, чем ПС?

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

Нужны конкретные замечания - что в СО удобнее, чем в ПС ...

Собственно для этого я и создал специальную тему.

[Леха]

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

например в ПС прописывать алюминий намного удобнее чем ПВХ, а в СО - наоборот - ПВХ прописывается легко, но с алюминием приходится заморачиваться намного сильнее, и необходимость прописывать систему в ПС аж в 3х каталогах - уже не кажется настолько мрачной

 

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

[dvim]

Я помню как на кривых настройках обычное тендерное предложение на остекление дома (~1000 квадратов) пересчитывалось 20-30 минут....

Предоставить заказчику надо не один вариант. (От говнопрофиля до 70мм пятикамерки, от белого до ламинации , стекла).

Оттуда пошли локальные базы, терминальные сервера, SSD....

 

Если ТС волнует тема производительности , то надо этим надо работать . (Если у них система на MS SQL то рекомендую поработать с профайлером и протюнить саму БД. Ибо разработчики ORM обычно слабо знают саму СУБД, и ее сильные стороны. )

[А.Х.]

По моему пониманию ТС - разработчик ПО. И просто хочет сравнить то время, которое затраичвает его программа на расчет с тем временем, которое уходит на тот же процесс у других программ.

Неа, ТС в настоящий момент поддерживатель winDraw'а в питерской оконной компании.

Менеджеры жалуются, что медленно работает.

И ТС проводит бенчмаркинг с целью понять - медленно работает и надо что-то делать или менеджерам просто витаминов выдать

 

Так же ТС считает, что у кого кого, а у Rexther'а данные такие точно есть. Но раз их не публикуют ...поеду за витаминами съезжу

 

з.ы. То, о чем говорит многоуважаемый джин dvim не использует ни ORM ни обработку чего-либо на стороне RDBMS и имеет тоько сильные стороны

Изменено 18 апреля, 2012 пользователем avkh

[dvim]

WinDraw - MS SQL

 

Что показывает профайлер, какие запросы?

Если этот запрос запихать (даже бездумно) в database tuning wizard что он предложит и какой инпрувмент даст?

Буквально недавно ряд процедур (не оконная система, транспорт) были таким образом ускорены в ~20 раз.

Просто Ms sql очень приятный сервер - там все есть (На Файрберд можно скачать профайлер, но установить у меня его корректно так и не получилось ) .

Изменено 18 апреля, 2012 пользователем dvim

[А.Х.]

Люди, да услышьте Вы ж меня! Технические моменты не интересны, как и что можно оптимизировать я знаю.

[viollan]

Внесу и я свои 5 копеек

Преамбула: Средняя скорость расчета заказа = средней температуре по больнице.

Для примера возьмите 3-5 демоверсий разного ПО и отрисуйте в них одинаковые конструкции с замером времени. Для определения скорости нужно определять не по количеству изделий в заказе, а по количеству УО (условных окон) рассчитываемых исходя из сложности конструктива и набора параметров/условий подбора спецификаций необходимых для указания менеджером. Полученные цифры соотнесите с % брака по вине расчетчика и выясните, а надо ускоряться?

Если все же надо читаем дальше...

Если Вас не устраивает скорость тогда оптимизируйте.

Скорость расчета пропорциональна объему и сложности заказа. Узких мест в расчете 3 удобство графического модуля, алгоритмы расчета спецификации и факторы не зависящие от ПО и Оборудования. Определите ваш случай.

В части построения конструкций применяйте/ищите оптимальные приемы конструирование. Одно и тоже действие дублируется разными элементами управления и разными командами от пользователя, вплоть до горячих клавиш и скриптов автопроектирования в случае WD, а так же использование шаблонов. Помните увеличивая скорость, увеличится количество ошибок, особенно если большое влияние оказывает человеческий фактор.

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

И самое главное, на мой взгляд, есть такая вещь как скорость обработки, запуска в производство, изготовление изделий/заказа. Скорость запуска заказа не должна превышать скорости его изготовления.

P.S.: Эти нехитрые действия можете провести своими силами или с участием разработчиков ПО

P.P.S.: После аргументированных вами неудобств в построении разработчику, будет проще разработать методики ускорения процесса расчета (если конечно до этого дойдет)

[SirAlex2]

Неа, ТС в настоящий момент поддерживатель winDraw'а в питерской оконной компании.

Менеджеры жалуются, что медленно работает.

...

Проблема в слове WinDraw. Около семи лет назад разработчик показывал мне эту программу. О ее плюсах и минусах я писал. Остановлюсь на том, что критично в этой теме. Если ничего не перепутал и ничего не изменилось с тех времен, то сравнивать быстродействие этой программы с прогами других разработчиков бесполезно. В программе принят другой, "отличный" подход А именно, все конструктивно-технологические особенности изделия описываются скриптами, что требует при расчете изделий многократный вызов интерпритатора команд. это конечно гибкий инструмент и возможно в будущем перспективный, когда вычислительная мощь железа вырастет настолько, что замечать этой работы просто не будет. На мой взгляд, расчетная программа стандартные задачи должна решать с помощью комплированного машинного кода, а возможность программировать оставить для всяких немыслимых конструктивно-технологических фантазий. Увеличивайте вычислительную мощь компа, добавьте камней в процессорный блок. И если уж сравнивать быстродействие, то между пользователями этой проги, при прочих равных условиях и обращайте внимание на железо. Пользателем этой программы не являюсь, в том числе и по указанной причине.

 

...

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

...

Нецелесообразно: http://forum-okna.ru...0&gopid=271528

[А.Х.]

Внесу и я свои 5 копеек...

Монотонно повторяю (уже, правда, не надеюсь быть услышанным ): меня интересует мнение конечных пользователей (менеджеров-расчетчиков) неважно каких программ в виде: на 50 позиций готов/неготов ждать пересчет заказа 05/1.0/2.0/3.0 мин.

 

Меня не интересуют сравнение с какими-либо программами, удобство построителей, способы настройки расчета спецификаций, методы оптимизации SQL-запросов, архитектура ПО и другие увлекательные, но не имеющие отношения к моему интересу, вещи

 

По теме пока высказался только один dvim в виде:

2 мин на 50 позиций: не мало, но терпимо.

 

 

Offtop: Про winDraw - я и сейчас не знаю существующих программ, которые были бы лучше чем оно И интерпретатора там нет и для настройки (проф. и фурн.) программирование не так что бы требуется. С заказами от 70-80 позиций - да, есть проблемы, но терпимо.

 

Изменено 21 апреля, 2012 пользователем avkh

[dm201]

Монотонно повторяю (уже, правда, не надеюсь быть услышанным ): меня интересует мнение конечных пользователей (менеджеров-расчетчиков) неважно каких программ в виде: на 50 позиций готов/неготов ждать пересчет заказа 05/1.0/2.0/3.0 мин.

Как это неважно каких программ? Например, в СО кнопки "Рассчитать" нету (по крайней мере я не нашел), там заказ пересчитывается по изделиям. И чтобы пересчитать 50 изделий надо много-много шевелить мышкой.

[А.Х.]

Как это неважно каких программ?

Ну, я предполагал, что такая кнопка везде есть

А как иначе пересчитать полностью заказ с другим заполнением или профилем?

В 50 позициях менять по очереди?

А если надо просто пересчитать, т.к. цены на материалы изменились?

Это современная версия СО?

 

з.ы. Это оффтоп. Но любопытно...

Изменено 24 апреля, 2012 пользователем avkh

[viollan]

Ну, я предполагал, что такая кнопка везде есть

А как иначе пересчитать полностью заказ с другим заполнением или профилем?

В 50 позициях менять по очереди?

А если надо просто пересчитать, т.к. цены на материалы изменились?

Это современная версия СО?

 

з.ы. Это оффтоп. Но любопытно...

Да это не временная версия, это с 3-й версии так, а сейчас выпущена уже 7-я и все руками и ни кто не жалуется как видите.

[BFMachine]

Профсегментовскому софту очень помогает SSD.

 

А можно поподробнее? Сравнивали или это теоретические выводы?

[dvim]

А можно поподробнее? Сравнивали или это теоретические выводы?

 

Сравнивали. Использовались небольшие (40 Гб) интеловские диски - туда ставился сам ПС и базы.

Система оставалась на HDD . Просто не готовы были ее переносить и "рисковать".

Рост производительности - существенный.

 

Сейчас, на основании реального опыта - уже готов брать 120 Гб SSD и устанавливать туда еще и саму систему.

Повторю : сейчас SSD - самый простой и дешевый способ роста производительности.

 

2avkh

Я одного не понимаю, почему оценка идет по заказу в 50 окон.

Имхо заказ либо на 2-5 окон, либо это тендер на 1000-3000 квадратов. (окон 300).

Советую сравнивать по 300 окнам

Изменено 24 апреля, 2012 пользователем dvim