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

MirTN · 05 фев 2013 12:14

При импорте.

При пакетной обработке. Импорт занял 51мин, 28 сек.

Загрузка на CPU в обоих случаях отсутствует.

Octav · 05 фев 2013 12:15

Нужен только прайс или архив БД тоже ?

05 фев 2013 12:31

Можно с архивом БД, чтобы протестировать в одинаковых условиях настройки.

massqwest · 05 фев 2013 15:04

MirTN писал(а):При импорте.
Загрузка на CPU в обоих случаях отсутствует.

Подтверждаю.Тоже делал такие замеры.Да и вообще тема актуальна.

05 фев 2013 16:33

Объясните разницу между старой версией программы и новой версией?

В новой версии программы был внедрен программный модуль, который даёт возможность выполнять параллельно несколько частей одной операции, например разбить операцию поиска производителя товара на 4 части, если используется 4х ядерный процессор, т.е. для каждого ядра процессора по 1й части от операции поиска производителя или на 8 частей, если доступно 8 ядер, тем самым нагрузив процессор на полную мощность.
Для задействования нового режима много поточной обработки данных, необходимо переписывать исходный код программы для каждой операции, т.е. для задействования новой возможности в полной мере, необходимо полностью переписать весь исходный код программы. К сожалению это не возможно сделать быстро, по объективным причинам, поэтому в программе были модифицированы только некоторые, наиболее время затратные операции, к которым на данный момент относятся: определение производителя товара, автозамена значений в наименование, определение цвета у товаров, корректировка ошибочных символов cyr|lat, сохранении результатов импорта в СТИПП (частично), обновление цен при пакетной обработке.
Параллельно выполнять несколько операций при импорте 1го прайс-листа нет возможности, т.к. каждая операция зависит от предыдущей, например для определения производителя товара необходимо получить список товаров из прайса, например перед применением правил импорта необходимо определить категории в прайс-листе и т.д., каждая операция зависима и их порядок строго задан. Поэтому возможность выполнения параллельных задач было внедрено непосредственно в сами операции.
Основной выигрыш в скорости проявляется только на больших, объёмных прайс-листах, на маленьких прайс-листах программа не успевает нагрузить процессор какой-либо операцией, т.к. она может завершаться довольно быстро и переходить к другой операции.

Тестировал на одном прайс-листе. Версия Professional

У вас в базе данных активирован режим автоматического сопоставления товаров - Поиск соответствия товаров: артикул из СТУС в наименовании товара в СТИПП

: compare_products_on_sku.png (48.86 КБ) 4486 просмотров

Именно из-за него у вас так долго импортируется прайс-лист. Исходный код программы, для данного вида операции автоматического сопоставления товаров не был переписан и он не использует много поточную обработку данных.
При деактивации данного вида автоматического сопоставления товаров время импорта данных из прайс-листа составило (на 2х ядерном процессоре):

: time_import_burokrat_price.png (5.16 КБ) 4486 просмотров

Скорость обработки 1 товара составила ~0.005сек (200 товаров в секунду).

Время в журнале операций:

: import_price_buro_log.png (30.21 КБ) 4486 просмотров

: import_price_buro_log2.png (20.42 КБ) 4486 просмотров

Как видно на снимке экрана скорость обработки прайса с 28000 позиций достаточно велика.

Octav · 05 фев 2013 16:41

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

05 фев 2013 16:57

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

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

И для каких операций сейчас работает многоядерность?

Об этом было сказано выше. На данный момент это:
- определение производителя товара;
- автозамена значений в наименование;
- определение цвета у товаров;
- корректировка ошибочных символов cyr|lat;
- сохранении результатов импорта в СТИПП (частично).

MirTN · 05 фев 2013 17:03

Можете прокомментировать мои скриншоты?

Octav · 05 фев 2013 17:12

TechAdmin писал(а):Вы можете сообщить какие операции у вас выполняются наиболее долго, мы добавим много поточную обработку таковых в первую очередь, если это будет возможно.

Поиск артикула из СТУСС в наименовании СТИПП (да и вообще весь поиск одинаковых товаров)...

Есть еще один непонятный момент... Да действительно заметил что при операции "Поиск производителя" нагрузка на ЦП выросла, НО только в 2 раза, то есть если раньше для данной операции проц был нагружен на 25% (при включенных виртуальных ядрах: всего 2 физических и 2 виртуальных), то сейчас (после обновления) нагрузка составляет 50%, хотя по логике должна быть 100% загрузка... Или не так?

05 фев 2013 17:21

Можете прокомментировать мои скриншоты?

На первом скриншоте импортируются данные из прайс-листа, данная операция не может быть разбита на нескольно частей, поэтому загрузка данных идёт в один поток.
На втором скриншоте идёт пакетная обработка данных, для данной операции внедрён много поточный режим только для обновления цен товаров. Далее идёт операция проставления наличия товара, которая пока не оптимизирована под много поточность.
Кстати, на обоих скриншотах видно что процессор вообще "спит", на первом скриншоте видна нагрузка 2%, на втором 0%, по какой причине так происходит у вас не понятно. Если у вас 4х ядерный процессор, тогда должно использоваться как минимум 1ядро и нагрузка должна быть ~20-25%.
И почему открытие прайса у вас занимает 5минут, это вообще очень очень долго. Мы можем проверить у себя импорт данного прайса, на этой БД, если необходимо.