2. В большом ритейл-холдинге существуют «не 1С» системы в магазинах (100 шт) и центральная база на 1С. Каждый магазин утром выгружает данные о продажах в текстовый файл и выкладывает на общий ресурс, из которого затем происходит загрузка в 1С. Загрузка выполняется полностью в автоматическом режиме. Файл с одного магазина загружается 5 минут, таким образом, общая длительность загрузки – более 8 часов. Как ускорить эту процедуру? Считаем, что код процедуры загрузки уже оптимален.
2. В большом ритейл-холдинге существуют «не 1С» системы в магазинах (100 шт) и центральная база на 1С. Каждый магазин утром выгружает данные о продажах в текстовый файл и выкладывает на общий ресурс, из которого затем происходит загрузка в 1С. Загрузка выполняется полностью в автоматическом режиме. Файл с одного магазина загружается 5 минут, таким образом, общая длительность загрузки – более 8 часов. Как ускорить эту процедуру? Считаем, что код процедуры загрузки уже оптимален.
Многопоточность! Несколько фоновых заданий на загрузку, например каждое фоновое задание грузит 10 или 5 магазинов
(22) То же самое хотел предложить. Разделить магазины на группы и настроить не сколько фоновых - по одному на группу. Чем больше групп - тем больше фоновых. Главное найти золотую середину между количеством групп и нагрузкой на сервер.
Всё же есть сомнения в (1) "Считаем, что код процедуры загрузки уже оптимален."
Посмотри, что творится в процедуре загрузки.
2-3 минуты можно сэкономить...
1. Дана некоторая таблица данных в MS Excel, информацию из которой требуется разово загрузить в некий справочник в 1С, структура которой не совсем простая, поэтому типовой обработкой «Загрузка из табличного документа» воспользоваться нельзя. Каким образом решить эту задачу наиболее быстро?
(9) Инструментами разработчика загрузить файл в ТЗ как параметр запроса, преобразить как удобнее писать в справочник, в процедуре обработки результата запроса написать код заполнения справочника.
(19) Да нет же. Говорю - универсальный механизм был. Процесс-координатор управляет процессами-воркерами, контролирует пул потоков, собирает результаты, перезапускает задачи при сбоях... По-идее и очередь задач должна присутствовать, но в упор не помню ее реализацию.
Где-то в дебрях инфостарта можно найти публикацию с готовой подсистемой для параллельного выполнения задач. Грамотно построенную грамотным человеком, явно прочитавшим пару книжек по concurrency. К сожалению, навскидку не вспомню ее примет :)
"обертывание" загрузки в транзакцию ускоряет процесс или тормозит
В 7.7 ускоряло, причем значительно (в файловой базе). В 8.Х субъективно одинаково что в транзакции, что без нее. Там все-равно при записи объекта транзакция начинается и фиксируется.
(25) Зависит от объема данных исходных транзакций. Это же своего рода буферизация. Если кучу мелких заворачиваешь в одну большую - то экономишь на накладных расходах. Но в сильно большую нельзя - пойдут лишние операции с диском и с какого-то порога получишь падение производительности. Обычно оптимальный размер (количество исходных транзакций заворачиваемых в одну) подбирается эмпирически. Если транзакции изначально "большие", то смысла обертывать почти нет.
По-сути это и есть многопоточность, только инициируется она клиентами, а не регламентом сервера. Но если 100 клиентов одновременно ломанутся что-то там грузить в базу, то она может и сдохнуть от нагрузки, поэтому лучше обрабатывать данные в многопоточной процедуре, чтобы не запускать потоков больше, чем есть ресурсов у сервера, да и юзерам нужно немного оставить для работы.
ЗЫ: Вообще, множество одновременных запросов к базе - это DDoS. Тут все упираетя в мощность сервера. Если тянет 100 потоков загрузки - можно и сервисом, а если не потянет - может и умереть.
А в конце концов перейти на УТ11 или Розницу с 1С-Сервер на вебклиентах не вариант? Ну или РИБ
100 магазинов конечно круто. Работал в сети из 20 магазинов на ут11.2. работало без проблем и с ТО и со скоростью
Итак,
1. 5 минут загружается файл с одного магазина.
2. Код процедуры загрузки оптимален.
Задача - ускорить процесс загрузки.
Включаем логику:
Если файл одного магазина загружается 5 минут, то варианта три:
1. Либо ну очень большие обороты в магазине (порядка 20 000 строк загрузки по практике грузятся не более 2-3 минут)
2. Либо все-таки код не оптимален. Нужно смотреть, каким образом происходит идентификация номенклатуры (вот чует мое сердце, что куча разыменований).и создание документов.
3. Либо комп тормозной.
Кроме того, чтобы ускорить процедуру, можно рассмотреть вариант не последовательной, а пакетной загрузки:
- Предварительную свертку всех файлов в один пул
- Общую обработку.
Господи, да откуда минутам взяться? Разве что это время включает тормозное проведение.
1. Читаем текстовый документ (100% с разделителями).
2. Начинаем парсить строку, получаем реквизиты сравнения, ищем соответствие объектов по справочникам (дай бог, чтобы одна номенклатура была, а то еще характеристики, серии, номера ГТД, единицы измерения различные).
3. При отсутствии оных - создаем, записываем, проводим.
Этот вопрос на собеседовании задают.
Раз написано, что код процедуры загрузки уже оптимален, то считаю что загрузку трогать нельзя.
Мой вариант ответа - перевести все сто магазинов на учет в 1С :)
Другой вариант созрел уже позже - выгружать продажи по факту или чаще по регламенту. Только это не ускорит)
"Этот вопрос на собеседовании задают."
Тоже столкнулся. Собеседование не прошел. Так что не знаю правильно ли я предложил.
Я предложил одновременно грузить фоновыми заданиями на разных процессах. Если ресурсов сервера не хватает - разнести на несколько серверов.
Кто-нибудь знает правильный ответ?
Что тут не так??? Заказчиком была поставлена задача учета в типовой конфигурации УТ отгружаемых товаров в разрезе кладовщиков, которые этот товар непосредственно выдали покупателю. Исполнителем для решения этой задачи было добавлено новое измерение «Кладовщик» в регистр накопления «ПартииТоваровНаСкладах», которое заполняется из реквизита «Ответственный» документа «Реализация товаров и услуг». Работоспособность системы сохранилась, а Заказчик получил отчеты по новой информации в требуемом виде.
Кратко прокомментируйте этот способ реализации и последствия, которые возникнут.
Предложите свой способ решения этой задачи.
(42) При такой реализации не будут закрываться остатки, т.к. этот РН исходя из своего названия имеет тип Остатки и его регистратором является множество документов.
Следует сделать всё тоже самое, но только с оборотным регистром в котором регистрируются именно продажи. Либо воспользоваться уже готовым вариантом как в УТ 11, это реквизит документа «Реализация товаров и услуг» и измерение в РН «ВыручкаИСебестоимостьПродаж» - «Менеджер». Либо, если менеджер и кладовщик различаются в этой организации по своей роли, то добавить в этот РН измерение «Кладовщик» и заполнять его из соответствующего реквизита документа (ответственный).
Ну а вообще, дано очень малоинформативное описание. Возникает сразу вопрос, если документ заводит некий кладовщик, именно то лицо, которое просто выдает товар со склада и не связан с оформлением и взаиморасчетами, то всё-таки правильнее было бы, чтобы в этой организации применялась ордерная схема учета, а в таком случае, тогда нужно будет уже отталкиваться от использования кладовщиком документа «Расходный ордер на товары». А для этого документа не назначен ни один оборотный регистр накопления, который соответствовал бы требуемой логике. Поэтому придётся создать свой РН с видом Обороты и написать обработку его заполнения при проведении этого документа. Ну и в итоге, дабы требование заказчика узреть в отчете, то для этого в УТ 11 есть типовой отчет «ТоварыКОтгрузке», в котором можно доработать запрос и, например, добавить новый вариант этого отчета с измерением «Кладовщик», и желательно через расширение, если УТ на типовой поддержке и периодически обновляется. Ну или можно свой новый отчет сделать, тут уж всё зависит от множества деталей, которых естественно нет в таком, еще раз повторюсь, малоинформативном описании.