Нужно провернуть довольно большую многочасовую обработку. В файловой версии она 8 часов отрабатывает. Может ли она отработать быстрее в скл версии? Вопрос почему возник, процессор диск и память пишут загрузку 10% в момент отработки. А у меня еще другая база была в скл, там другая обработка жрала все под 90-100%.

"загрузку 10%" << "под 90-100%."
даже если взять 10-15% на погрешность и транзакционные расходы. значит ответ - на сервере происходит большее число работы за единицу времени.

(0) может. а может и нет

Стаж: 2 года 9 месяцев 23 дня ппц

у файловой на порядок больше скорость записи
у скульной быстрее выборка данных. причем чем больше в БД данных тем больше файловая приогрывает. плюс масштабируемость у скульной больше

так что если мы говорим о перепроводки (или о массовой записи), то файловая впереди скульной

Если мы говорим о выгрузки данных на сайт, то не факт что файловая зарешает

Так что по какому параметру будем производительность сравнивать?

(4)
в моем случае обмен между базазами 1с через com за год по всем документам и справочникам.

(0) есть файловая версия на SSD диске, а объем файлового кеша системы больше размера БД. Почти всегда будет быстрее.

(5)Скорее всего без особой разницы будет, т.к. сам com медленее

(4) >> у файловой на порядок больше скорость записи
особенно когда в неё пишут 100 ползователей

(0) Если в этой обработке кривые запросы в цикле, то серверная не поможет.

Еще в свое время сталкивался с базой, которая файловая и сильно тормозила. После перевода в скл она залетала. Просто объем был достаточно большой и подходил к предельному размеру таблиц. Я не знаю, как 1с обрабатывает эту ситуацию, но при больших размерах файловая продолжает работать но сильно тормозит. Я сейчас склоняюсь именно к этой версии, что база начинает тормозить с определенного момента, когда размер подходит к критичному для файловых таблиц.

(8) Мы сейчас р сферической базе в ваккуме говорим, или о конкретной ситуации когда ТС один в базе и запустил обработку?
Так то можно учесть вляние пятен на солнце на скорость подключения по com

(10) отладчик в руки. Может у тебя каждый раз новое соединение инициализируется. Или каждый раз перезаполняются справочники, даже если данные не поменялись

(5) "обмен между базазами 1с через com" - и это в канун 2018 года, атас)

(10) посмотрите размер таблиц - узнаете, есть ли критические таблицы.

(13) а чем надо в канун 2018?

(15)
черех хмл наверно или тхт

если выгрузка сейчас идет в монопольном режиме и размер транзакций не большой (до 1000 объектов) то серверную версию можно даже не пробовать, если и будет ускорение - то не значительное.

если это НЕ монопольный режим и одна большая транзакция - то в скуле будет ощутимый прирост скорости

(17)
А какой критерий измерения большизны транзакции, как вычислить?

(0) "В файловой версии она 8 часов отрабатывает. Может ли она отработать быстрее в скл версии? " Что мешает развернуть SQL-сервер и проверить?

(15) явно не устаревшим и глючным com-соединением)

(19)Время, этож возиться надо, создавать базы, загружать базы. А вдруг зря, обидно будет немного

запись 1000 строк в таблицы - это вполне нормальная
запись 10000 строк - уже тяжелая, но приемлемая
запись 100000 строк - явно большая для 1с


1 стока <> 1 объекту/документу

(20)
Что в нем устаревшее то? Вполне работает.

(21) Не хочешь делать сам - делегируй это кому-нибудь.

(23) работает - не трогай. согласен)

(20) сохранять и читать файлик более модно?

(5) Хочешь быстрее - делай обмен через файлы, а не COM. Оптимизируй сам обмен. разбей на этапы (Справочники,
РС, Документы и т.п.), оптимизируй правила по рекомендациям 1С.

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

(23) Дело не в том, что устаревшее, а в том, что COM еще тот тормоз. Почему запросы в цикле это плохо, представляешь? Так вот, каждый вызов через COM это "запрос".

(20)  так вот почему в типовых для обменов приоритет отдан глючному ком, а не как раньше через надежный файл

(27)
Переделывать не вариант. Закончить все надо до конца года. Седня последнюю ошибку устранил вроде. Если на файлы переделать, до конца года точно не успею.

с чего это через ком будет медленее?
Через файл мне нужно выгрузить 100500 реквизитов и не факт что они мне понадобятся.
А через ком я дергаю только то что мне нужно.

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

(30) разбивай на группы и на этапы и грузи паралельно
Т.е. 1 поток грузит чисто справочник номенклатуру
2 поток грузит чисто справочник контрагенты

Вероятность пересечения мала, поэтому врядли он нарвется на блокировку

во втором этапе грузим документы тут тоже можно разбить например отдельно банк, отдельно касса, отдельно приходы и т.д.

скорости это не прибавит, но зато тебе будет чем заняться эти 8 часов

(31) При выгрузке через COM ты тоже не знаешь, пока не сделаешь запрос через COM. Не вижу принципиальной разницы.

(28) почему ком тормоз? можно тормозам объяснить?

(32)
Кстати это идея, спасибо, попробую

самописный обмен через ком будет гораздо быстрее выгрузки/загрузки через файло. а еще если в 2-3 потока, тем более

(35) Возможно. Я говорил про обмен через КД.

(34) я выгружаю через ком документ. дальше мне нужно найти по ссылки контрагента. Если я нашел я тупо использую найденный объект. Если не нашел, тогда да я делаю еще один запрос по ком на получения всех реквизитов элемента справочника.

(38) в КД не ком обмен, а хрень. там выгружается файл, а загрузка этого файла дергается из базы приемника через ком-соединение.

(39) это уровень прикладной логики, а не минус технологии.

я могу пулять по ком документ и ниче не искать по реквизитам. а наличие контрагентов из документа, решается тем, что ты их загнал в базу приемник до документа.

(21) Почему сразу зря? Любой результат будет информативен.

+42 К тому же будет платформа для тестов. Не только для этой задачи, но и для любой другой.

(39) Вот это "дальше мне нужно найти по ссылки контрагента" в коде как выглядит?

(44) дело техники. Начиная от найтиПоКолду/НайтиПоРеквизиту/НайтиПоНаименованию
и заканчивая СсылкаНаОбъект=Справочники.Контрагенты.ПолучитьСсылку(Новый УникальныйИдентификатор(ГУИД));

(45) искать надо сами объекты, а не реквизиты. в реквизит просто ссылку пишешь и все.

(28) Что за чушь?

Может немного не по теме, но сегодня обнаружен ЭФФЕКТ прироста памяти - на рабочем компе стало 6 гигов, если при 4-х документ проводился за пол-часа или даже дольше, то сейчас - менее минуты. В доке порядка 40 тысяч строк. База на Постгри, платформа 8.3.10.2580 доклад закончил! )

(48) Это как раз понятно, своппинг из-за недостачи памяти.
4G для 1С это очень мало

(48) А в чем прикол делать такие доки по 40К строк? Можно сделать 10 доков по 4000 строк и обойтись четырьмя гигами памяти.

А так, любую систему можно раком поставить.