Обсуждение и советы: создание интернет-магазинов - решения, процессы, прайсинг

При импорте.


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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