Евгений, у меня нормальный сервер. 32 ядра, 4.7 в разгоне, 256ГБ оперативки, SSD mvme n.2(менее 30% занято) и тд. Все оптимизировано под 1с.
Однако, мне совершенно не нравится скорость работы обновления прайсов. Сейчас я все переделал на работу с json-файлами(у вас нет такой возможности, пришлось писать костыли) и читаются они почти мгновенно даже при очень большом количестве данных. Еще думаю насчет вообще бинарных файлов, они меньше весят и теоретически могут еще быстрее читаться. Все операции по строкам, алгоритмы и так далее - делаются у меня в отдельных скриптах вне 1с вообще и не замедляют загрузку. Сами json - файлы я тоже собираю алгоритмами и не гружу этим 1с. То есть база получает уже готовые файлы, которые просто надо синхронизировать(сопоставить с номенклатурой) и записать изменения в регистр.
Я вижу что узких места два.
1. Синхронизация. Тут я поотключал все варианты кроме трех. поиск по идентификатору номенклатуры поставщика, поиск по артикулу поставщика, поиск по артикулу справочника в 1с. К сожалению, нельзя убрать первую из указанных опций, потому что иногда артикулы поставщиков неуникальны даже в рамках одного прайса. Как еще можно ускорить этот процесс? Я читал, что у вас используется чуть не везде веб-сервис, как его отключить? Как делать простую загрузку для файлов, которые сохранены в json или txt - у вас она пока для файлов этого типа закрыта. Скажется ли его отключение на скорости синхронизации? И какие еще варианты вы можете предложить?
я не понимаю, что там за проблема со скоростью, даже датафреймы с 100 000 строк и более должны моментально синхронизироваться, даже при условии тройного поиска соответствий(id, арт поставщика, арт справочника) в двух регистрах данных. Или у вас используется построчное сравнение?
2. Запись в регистр. Вот это - самая долгая операция. Тут я даже предположить не могу, как ее ускорить, вероятно, это больше вопрос к коду, который от меня скрыт. Что-то посоветуете?
Я только вижу, что данные после синхронизации сначала сравниваются с имеющимися и пишутся только изменения. Тогда почему это происходит так долго? Обычно это 10-15% позиций от всего прайса.
Цель - добиться того, чтобы прайсы с 200-300 000 строк обновлялись не дольше чем 10-20 секунд при средней загрузке сервера в течение дня.
Однако, мне совершенно не нравится скорость работы обновления прайсов. Сейчас я все переделал на работу с json-файлами(у вас нет такой возможности, пришлось писать костыли) и читаются они почти мгновенно даже при очень большом количестве данных. Еще думаю насчет вообще бинарных файлов, они меньше весят и теоретически могут еще быстрее читаться. Все операции по строкам, алгоритмы и так далее - делаются у меня в отдельных скриптах вне 1с вообще и не замедляют загрузку. Сами json - файлы я тоже собираю алгоритмами и не гружу этим 1с. То есть база получает уже готовые файлы, которые просто надо синхронизировать(сопоставить с номенклатурой) и записать изменения в регистр.
Я вижу что узких места два.
1. Синхронизация. Тут я поотключал все варианты кроме трех. поиск по идентификатору номенклатуры поставщика, поиск по артикулу поставщика, поиск по артикулу справочника в 1с. К сожалению, нельзя убрать первую из указанных опций, потому что иногда артикулы поставщиков неуникальны даже в рамках одного прайса. Как еще можно ускорить этот процесс? Я читал, что у вас используется чуть не везде веб-сервис, как его отключить? Как делать простую загрузку для файлов, которые сохранены в json или txt - у вас она пока для файлов этого типа закрыта. Скажется ли его отключение на скорости синхронизации? И какие еще варианты вы можете предложить?
я не понимаю, что там за проблема со скоростью, даже датафреймы с 100 000 строк и более должны моментально синхронизироваться, даже при условии тройного поиска соответствий(id, арт поставщика, арт справочника) в двух регистрах данных. Или у вас используется построчное сравнение?
2. Запись в регистр. Вот это - самая долгая операция. Тут я даже предположить не могу, как ее ускорить, вероятно, это больше вопрос к коду, который от меня скрыт. Что-то посоветуете?
Я только вижу, что данные после синхронизации сначала сравниваются с имеющимися и пишутся только изменения. Тогда почему это происходит так долго? Обычно это 10-15% позиций от всего прайса.
Цель - добиться того, чтобы прайсы с 200-300 000 строк обновлялись не дольше чем 10-20 секунд при средней загрузке сервера в течение дня.
Изменено: - 05.08.2022 00:45:07