Не PLI а слошная "обработка данных"

[tkachenkoser]

Чаще всего решаю текущие вопрос по ICQ, но сейчас тема будет явно интересна для всех.
Программа PLI лучшая в своем роде, всем советую, удивляюсь продуманности и возможностями. Но есть один момент (но очень длинный), при котором хорошего ничего не подумаешь. Особенно после обновления от 15 октября 2012.
Специально для PLI был выделен сервер чуть ли по самому писку моды. Процессор intel core i7, разогнан до 4600 мгц, память 8 гб 2000 мгц, ssd диск intel 520. - Реально лучше только многопроцессорные решения, но экспериментально проверил, что скорость работы PLI зависит только от частоты процессора.
И даже при такой конфигурации - слово "Обработка данных" я вижу наверно не менее получаса в день. То что никакой нет оптимизации под многоядерность - ладно, возможно это большая сложность. То что необходимо время для загрузки прайса поставщика и для пересчета цен - все ясно. Но вот становится очень интересны действия PLI при нажатии на "все товары" когда открыты товары поставщиков. - начинаются перечисления кучу непонятных операций, множество сравнений, поисков, поиск разниц в цене, одинаковых товаров. Стоит побывать в определенной категории, потом вернуться "все товары" - и снова ПЛИ превращаться на несколько минут в "обработка данных". При этом никаких изменений в прайсах не происходило, новых наценок не было. Это я терпел более года.. Но вот 15 октября вышло обновлении после которого, уже не могу, не высказаться - в этой обработке еще появилось пересчет всех прайсов поставщиков! Теперь я не полчаса в день буду видеть надпись "обработка данных", а не менее часа.
Частично удалось ускорить этот процесс благодаря тонкой подстройки алгоритмом сравнения товаров каждого прайс листа, отключения сравнения "названия 2", поиска вхождения кириллицы, поиска только по артиклю.. И даже после этого, эта однотипная операция на таком сервере занимаем 3 минуты!
Вот очень хочется знать - зачем это делать каждый раз, если 100 раз открывать просто товары, он 100 раз проделывает абсолютно одинаковые операции? Что за пересчет всех прайсов? Почему нельзя чтоб все эти пересчеты осуществлялись когда загружается прайс лист, когда есть изменение, или при пакетной обработке. Если сравнение товара, то почему оно не делается только в нужной категории, при вызове УМКЕ. Если это это так необходимо - почему бы не сделать КЕШ где будет результаты первого открытые товаров.
Если это можно отключить, оптимизировать то почему в справке этого нет?

[TechAdmin]

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

[tkachenkoser]

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

[Octav]

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

+1 к автору. Время много уходит на это. А то что i7 поставили это зря, я собираюсь под это дело ставить i5-655k (2-ух ядерный) разгонять его до 4500мгц и отключать виртуальные ядра. Для примера на данный момент стоит i5-2300мгц (2-ух ядерный и не разгоняется), при включенных виртуальных ядрах (а они и у Вас по умолчанию должны быть включены) импорт прайсов занимал порядка 53 минут, после их отключения время сократилось до 33-35 мин.

[tkachenkoser]

Я специально тестировал различные операции на разных процессорах - corei5, corei7, intel core 2 duo, самым главным отказалась частота процессора.
От количества ядер точно не зависит - приложение всегда занимает только одно ядро.
С отключенным HT действительно грузятся дольше, но не намного больше.. А вот во время пакетной обработки, отключение HT очень плохо сказывается на времени обработки.

[Octav]

А зачем тогда i7 поставили?

[tkachenkoser]

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

[Octav]

Должна производительность быть ниже. Вашу частоту 4600мгц поделить на кол-во ядер (например 4)=1275мгц
Теперь для моего варианта: 4500мгц делим на 2 ядра = 2250мгц.
Техподдержка мне тоже самое сказали. Самый идеальный вариант - это одноядерный с максимальной чатотой, но такие уже EOL... Так что остается только 2-ух ядерники.

[MirTN]

О каком кол-ве товаров в СТИП и СТУСС идёт речь коллеги?

[tkachenkoser]

СТУС 25000, СТИПП 80000.. ПЛи как мог оптимизировал, импортируется только товары что в наличии, старые товары отключаются.