Были файловые базы. Был отчет который запускался в одной из баз, далее через com цеплялся к другим базам (4 шт) и оттуда запросом вытаскивались данные. Работало нормально. Потом все эти базы перевели на SQL. Отчет стал долго формироваться и если раньше с такими же параметрами и отборами он формировался 1 минуту, то сейчас можно и 5 минут ждать. И нагрузка на сервер доходит до 98%. В каждой базе писать в общем модуле функцию к которой обращаться из основной базы также через COM, а поможет ли ?

(0) главное тут, что появился сервер приложений
и сейчас по вводным остается гадать где у вас данные собираются: на клиенте, на сервере, может бегают туда-сюда

(0) надо поднять вэбсервер на го, переписать получение данных  под rest api и тогда полетит. Инфа 100%

Запрос &НаСервере выполняется.
Там же  результат запроса в табл. значений и оттуда
Отчет.ТабличнаяЧасть.Загрузить(ТЗ);

получается, что искать через замер производительности ? И подозрение на Отчет.ТабличнаяЧасть.Загрузить(ТЗ);

(4) Получается

web-сервисы быстрее Com в такой ситуации.

(6) Тогда придется лезть в конфигуратор остальных баз ?

Попробуй обмениваться между базами не напрямую, а через сериализацию/десериализацию таблиц значений. В этом случае передача через COM будет атомарной - передается строка, это намного быстрее должно быть.

Разверни цент, сливай данные туда, отчет строй там. Еще быстрее будет

Для начала неплохо бы вообще определиться - что стало узким местом.
Может проблема вовсе не в COM. Клиент-серверные базы в принципе зачастую медленнее выполняют отдельные операции, чем файловые.
Тогда переход на вэб-сервисы никакого заметного результата не даст (кроме пользы отказа от  COM).
В самой базе-источнике отчета, если сформировать этот отчет, он будет так же медленно собираться?

(0) Для начала нужно выяснить, время уходит на выполнение запросов или на обработку результата?

(0) создайте 5ой базу, которая будет собирать инфу с других 4х баз для отчета. А вы будете уже цепляться к ней по http, получить структуру данных по параметрам и загонять в свой отчет. Можно даже с использованием СКД, просто при комоновке указываем полученную таблицу.

(12) *5ую

(10) Кстати да. Возможно тормозит именно исполнение запроса. На постгресе такое часто бывает, неудачный план выбирается.

Смотрите план запроса (или в ТЖ или в трассировке СУБД).

(14) Если запрос составлен криво, то и план будет не оптимальным (или планировщик запроса отвалится по таймауту и вернет рандомный план как оптимальный или SQL промахнется со статистикой и выделением памяти под запрос и дальше начнется фейерверк. Про покрытие запроса индексом -это отдельная тема).

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

(6) +100
(7) нет, у всех баз есть публикуемый сервис ODATA, этого формата должно хватать на 90% всех обменов

надо делать замер производительности.
Если долго подключается к COM, то можно сделать робота, который будет вытаскивать данные заранее и сохранять в базу, где формируется отчет.
Com возможно долго подключается из-за проверок лицензий - помню с ними были какие-то проблемы

Измерил.
Connection=v8.Connect(СтрокаПодключения);   55%
выполнение запроса еще 34%

(19) Коннект в цикле для каждой строки, что ли? :)

(20) ага :)
количество 1
подключение 17 секунд.

Еще раз сделал замеры при одинаковых условиях (параметры, отборы).
На файловых базах :
подключение 5 секунд.
запрос 13 секунд.
На SQL базах
подключение 15 секунд.
запрос 17 секунд.
Т.е. разница во времени выполнения запроса не такая существенная на фоне увеличения времени подключения к клиент-серверной базе через com.

(22) это все на одной машине, и клиент и сервер 1с и сервер БД?

Да, все на одной машине.

(24) всё же уточни по (20), сколько коннектов на забор данных из одной внешней базы?

(25) Из 5-й подключаюсь к 4-м другим базам.
К одной базе один коннект.
Создал коннект, подключился к базе №1, выполнился запрос, отключился, результат загрузил в ТЗ.
И так еще 3 раза все сгружаю в одну ТЗ.

(26) тогда "5 минут ждать" из (0) нуждаются в пояснительном замере

(27) Замеры на домашнем компе. Одни и те же базы, только сделал файловые и SQL варианты.
На файловых базах :
подключение 5 секунд.
запрос 13 секунд.
На SQL базах
подключение 15 секунд.
запрос 17 секунд.

На рабочем сервере картина еще хуже, там одна SQL база обрабатывается больше минуты, а их таких 4. Вот и набегает 5 минут.

(28) вот по пятничному, вы смахиваете на журналиста. Там умножаю, тут нет. Вы понимаете, что даёте бредовые данные для понимания Ваших метрик?

(29) Не понял.

(30) на себя

(31) Что "на себя" ?
Замер производительности показывает пропорции.
Я показал разницу между файловой и клиент-серверной версиями.
Выше уже писал, что пока базы не были переведены на SQL, скорость работы отчета устраивала.

Переписал отчет с использованием WEB-сервиса.
Стало быстрее. Но тут другая засада :(
Если формировать отчет по очень дальнему периоду, например, за 2019 год, то на рабочем сервере отчет завис, пару минут подождал, закрыл базу. Пробовал несколько раз.
На домашнем компе этот же отчет в этой же базе и при таких же параметрах формируется за 5 секунд.
Одна и та же платформа и SQL и на рабочем и на домашнем компах.

засада уже на формировании отчета местной, не удаленной базы.

Извиняюсь за выражение, но какая-то хрень творится.
Захожу через сервер и оттуда выполняю запрос к текущей базе. Отчет завис, выше писал уже.
Захожу тонким клиентом через веб-сервер и оттуда выполняю запрос с теми же параметрами к текущей базе. Отчет выполняется за 5 секунд.
Нафига тогда ставили этот долбаный SQL с 1с-сервером, выпулив почти пол ляма ?

(35) Позовите специалиста.

(35) Интересно, а тебе какое дело до "почти пол ляма"?

(37) Скорее всего рубился за ... денег выделили, ну и спросят в последствии ...

(36) Уже звали, вернее те сами пришли. Теперь вот плоды.
(38) С меня не спросят :) Не я же ставил и моим мнением не интересовались, просто поставили перед фактом.

На домашний комп поставил SQL и 1С-сервер. Закинул базу с рабочего сервера.
На моем компе аж летает хоть захожу просто через тонкого, хоть через веб.
На рабочем же сервере запрос к дальним периодам просто вешает базу. Например, запрос за 2019 год.
Речь сейчас об обычном простеньком запросе к остаткам и оборотам по счетам.

(39) Пора "На рабочем же сервере"

(40)+ менять

(41) Что менять ?
Я с SQL не дружу. Может там что-то в настройках криво сделали ? Знать бы где.
На домашнем компе я тупо по методичке устанавливал, никаких настроек не делал.

(42) имхается там просто сервер говно
хуже чем твой домашний комп

Пока были файловые базы, то работало намного быстрее.
Домашний комп  : АМД Ryzen 5 3500  20Гб памяти. диск SSD
Рабочий сервер : Интел ксенон Е5-2630 1,8 Ггц  памяти 220 Гб диск SSD
Сейчас на рабочем сервере крутится простейший запрос, загрузка ЦП 40%, памяти 20%. Крутится уже 15 минут.
На домашнем компе этот же запрос к такой же базе выполняется за 5 секунд.
Не верится, что дело в железе.

(44) сам сравни https://www.cpubenchmark.net/compare/AMD-Ryzen-5-3500-vs-Intel-Xeon-E5-2630L-v4-vs-Intel-Xeon-E5-2630L-v3/3588vs2914vs2818
особенно Single Thread Rating
и возможно там на зионе виртуалка или еще какая хрень и буст не работает

Глянул.
На сервере ксенон Е5-2630 v2

Сейчас выгрузил дт и загрузил в файловую базу. Сформировал отчет за 20 секунд.
SQL-база минут 15 формировала отчет пока я принудительно не закрыл базу.
Железо ведь не настолько хуже на сервере, чтобы была такая большая разница ?

(47) Конечно нет. Наши отцы и деды формировали отчеты на 486sx и ничего. Позовите специалиста.

(48) Я же уже отвечал
Ну да ладно, мне не трудно повторить
"Уже звали, вернее те сами пришли. Теперь вот плоды."

Мог бы думать на свой отчет. Но он аж летает на моем домашнем компе где я сам установил платформу с сервером.

Я не специалист, но говорят что в sql иногда требуется какое-то обслуживание, фоновые задания по реиндексации в наименее загруженное время.. я не уверена что это так называется в sql.

(51) Расскажите о себе.

У меня на домашнем 2019, на сервере 2014. Платформа 8.3.18.1363 одинаковая и на сервере и на домашнем компе.
Может здесь собака порылась ?

2019 и 2014 - это я про Microsoft SQL Server

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

(55)тесты имеете ввиду Гилева в попугаях?

Сейчас не надо покупать дорогущие сервера за многолямов
Надо брать нечто шустрое но дешевое и менять планово через 3-4 года а не ждать десятки лет

(56) не только
банальный CPU-Z бенчмарк и CrystalDiskMark дисковой

Ну и писать отчеты под сервер 1С должен специалист по клиент-серверу
А не тот кто только для файловой локальной умеет или в RDP
Ибо там на передаче между клиентом и сервером по тормозной локалке бывает упс, особенно если в цикле с клиента сервер дергать или много данных сериализовывать сложных типов

(59)+ для общего развития https://xn----1-bedvffifm4g.xn--p1ai/news/2017-03-09-how-server-call-works/

(60) Там запрос простейший.
на клиенте Выполнить()
оттуда вызов процедуры на сервере.

Запрос=Новый Запрос;
    Текст =
    "ВЫБРАТЬ
    |    ЕСТЬNULL(ХозрасчетныйОстатки.Субконто1, ХозрасчетныйОбороты.Субконто1) КАК Контрагент,
    |    ЕСТЬNULL(ХозрасчетныйОстатки.Субконто1.Родитель.Наименование, ХозрасчетныйОбороты.Субконто1.Родитель.Наименование) КАК Родитель,
    |    ЕСТЬNULL(ХозрасчетныйОстатки.Субконто1.Наименование, ХозрасчетныйОбороты.Субконто1.Наименование) КАК Наименование,
    |    ЕСТЬNULL(ХозрасчетныйОстатки.Субконто1.ИНН, ХозрасчетныйОбороты.Субконто1.ИНН) КАК ИНН,
    |    ЕСТЬNULL(ХозрасчетныйОстатки.СуммаОстатокДт, 0) КАК НамДолжны,
    |    ЕСТЬNULL(ХозрасчетныйОстатки.СуммаОстатокКт, 0) КАК МыДолжны,
    |    ЕСТЬNULL(ХозрасчетныйОбороты.СуммаОборотДт, 0) КАК Оплата,
    |    0 КАК Сальдо_1007
    |ИЗ
    |    РегистрБухгалтерии.Хозрасчетный.Остатки(&НаДату, Счет В ИЕРАРХИИ (&СписокСчетов), , ) КАК ХозрасчетныйОстатки
    |        ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Обороты(&ОплатаС, &ОплатаПо, , Счет В ИЕРАРХИИ (&СписокСчетов), , , КорСчет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетныеСчета), ) КАК ХозрасчетныйОбороты
    |        ПО ХозрасчетныйОстатки.Субконто1 = ХозрасчетныйОбороты.Субконто1
    |
    |ОБЪЕДИНИТЬ ВСЕ
    |
    |ВЫБРАТЬ
    |    Хозрасчетный_1007.Субконто1,
    |    Хозрасчетный_1007.Субконто1.Родитель,
    |    Хозрасчетный_1007.Субконто1.Наименование,
    |    Хозрасчетный_1007.Субконто1.ИНН,
    |    0,
    |    0,
    |    0,
    |    ЕСТЬNULL(Хозрасчетный_1007.СуммаОстаток, 0)
    |ИЗ
    |    РегистрБухгалтерии.Хозрасчетный.Остатки(&НаДату, Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.МатериалыПереданныеВПереработку), , ) КАК Хозрасчетный_1007"    ;

Запрос.Текст = Текст;

    Граница = Новый Граница(КонецДня(Отчет.НаДату), ВидГраницы.Включая);
    Запрос.УстановитьПараметр("НаДату", Граница);
    Запрос.УстановитьПараметр("ОплатаС", Отчет.ОплатаС);
    Запрос.УстановитьПараметр("ОплатаПо", КонецДня(Отчет.ОплатаПо));
    Запрос.УстановитьПараметр("СписокСчетов", СписокСчетов);
    
    РезультатЗапроса = Запрос.Выполнить();

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

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

Что касается Com-соединенря,то оно работает в режиме толстого клиента и все действия выполяются на клиенте (в соединении)как это было в обычном режиме.
Конечно,если делать соединение на сервере,то по сети ничего бегать не будет,а вот через границу процессов - да.

(62) На SQL 2019 аж летает.
Сейчас даже не о com или web идет речь. Зависает простейший запрос к своей же базе.
На SQL 2014 полностью зависает база.
Где-то есть список совместимости платформ 1С с версиями SQL ?

Простите, а обычные типовые осв,карточка счета и журнал ордер по субконто формируются одинаково быстро(медленно)?

(63) Раскидайте Остатки и Обороты по временным таблицам.

(63) А чего скульный профайлер говорит ?

(66) lazy table spool скорее всего он говорит. И ReadRowCount >10^6

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

Ребята вопрос немного в тему.
Не хочу отдельную ветку создавать.
Какая альтернатива СОМ-соединению для отчетов кроме как rest через api?
Чтоб вообще не трогать конфы а только внешими отчетами.
HTTP  запросах нужно ли что до в конфу допиливать?
И еще что лучше для того чтоб сравнивать остатки между базами.
Мне нужно на время перехода из Ут+Розница на КА постоянно сверять остатки..

Я думаю через txt файлы(

(70) Это ответ мне?
Я имел ввиду если с подключением.
Через текстовик писал уже. Не удобно

(0) перепиши на http-сервисы

(71) XML

(71) Еще ODATA можешь попробовать.

(69) Какова периодичность сверки?

(69) я кстати, делал расширения с HTTP-сервисами для снятия отчетов.
А что касается сверок, то можно или запускать с ключом внешнюю обработку или если это типовая, настроить ту же внешнюю обработку для запуска по расписанию.

(65) Уже лучше. На моем компе 4 секунды, на сервере 25 секунд. Но хотя бы не зависает.

Спецы, а все же, есть разница какую версию SQL на каком релизе платформы использовать ?
У меня 2019 и никаких тормозов. На рабочем сервере 2014 и зависания.

(77) Почитать требования платформы - не предлагать?

(69) Если не лень править конфигурации, можно прямыми запросами обойтись. :-)

(77) Пока ты не дал инфы про рабочий сервер: размер баз, количество ОЗУ, виртуалка или нет. Что показывает очередь к дискам в момент выполнения запросов.

(78) Ты как в каждой дырке затычка. Предложи еще ЖКК почитать.
(80) Не виртуалка. Базы 4-5 Гб. Остальное в 44-м сообщении писал.

(75) Не часто. Думаю возможно что в день несколько раз и потом несколько дней или неделю тишина будет.

(81) Там ни про загруженность ОЗУ, ни про очередь к дискам ничего нет. При таких базах это вряд ли сыграет, но тем не менее. Возможно, полнотекстовый поиск перестраивается или другие регл.задания просто кладут на лопатки этот древний процессор.

(81) > Предложи еще ЖКК почитать
А ты не читал еще что-ли???

(37) А, так это ты тот "специалист", что лапшу на уши повесил клиенту о том как все начнет просто летать после перехода на SQL ? А я то думал, чего это ты взъелся за упоминание про те пол ляма ))
(83) Точно не помню, но где-то 20% память и 40% ЦП. Очередь к дискам не смотрел.

(85) Не. Я - тот, кто бумаги на покупку подписывал. Вот у меня и вопрос - тебе-то дело какое? Получил задание - делай. Не можешь - сознайся и не делай. Но нет, кругом все у тебя не так.

(81) >> Предложи еще ЖКК почитать.

Первая здравая мысль за третьи сутки существования ветки.
Была ещё про то чтобы пригласить специалистов, но ты упорно делаешь вид, что это не к тебе адресовано.
Желание разобраться самостоятельно конечно похвально и достойно уважения.
Но проблема явно в недостатке компетенций.

(85) >> лапшу на уши повесил клиенту о том как все начнет просто летать после перехода на SQL?

А ты свечку держал? Лично слышал что специалисты говорили клиенту?
Ты уверен, что знаешь причины перехода на SQL? Ты уверен, что требования специалистов были клиентом выполнены, а не было диалога типа "сейчас у нас нормального железа нет, а потому поставьте нам SQL и 1С на вот это вот древнее *авно мамонта, а мы потом когда-нибудь честно-честно сделаем апгрейд".

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

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

(0) Насколько актуальными должны быть данные? Если хотите, чтобы летало и актуальность в несколько минут вас устроит то:
1) Поднимаете еще 1 базу агрегатор.
2) Поднимаете http сервис в этой базе. Добавляете метод для загрузки данных и метод для отдачи итоговой инфы.
3) Создаете в этой базе табличку для хранения данных
4) Создаете план обмена в 4 базах с фиксацией изменений по данным из отчета.
5) Пишите внешнюю обработку с рег заданием (либо в конфу встраиваете новое рег задание). В ней получаете изменения по плану обмена и выгружаете их post запросом в базу агрегатор.
6) Рабочей базой, где нужен отчет, получаете от базы агрегатора ТЗ с данными и пихаете в СКД.
7) Продумать механизмы контролирования обмена (уведомления об ошибках и т.д.)

(86) "Но нет, кругом все у тебя не так."
На домашнем компе где 1с-сервер и SQL я ставил сам, все летает.
На рабочем сервере зависает. Не медленно работает, а именно ЗАВИСАЕТ полностью база, другие пользователи тоже в этот момент работать нормально не могут.
Ну и при чем тут я ? Не я же ставил на рабочем сервере всю эту ....
"Не можешь - сознайся и не делай"
Что я не могу ? Отчет я переделал. А в настройки SQL я не полезу, не я ставил, не мне и исправлять .

(90) > SQL я ставил сам
Причем поставил версию, отличную от той, что в продуктиве и начал по ней делать далеко идущие выводы.
Умничка.

(89) Переделал уже. Спасибо  H A D G E H O G, раскидал запрос по временным таблицам, заработало.
Сделал в удаленных базах WEB-сервис. Пока не к спеху, но наверное перенесу WEB в расширение.
(91) Так я и спрашивал, может есть рекомендации для какой платформы какую версию SQL.
На 2019 даже без переделок отчета все летает. А на 2014 зависает.

Ребята как победить такое:

m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<m:code>8</m:code>
<m:message>Сущность 'Catalog_ВидыНоменклатуры' не найдена</m:message>
</m:error>

по комнде

http://localhost/intertopKAmarat/odata/standard.odata/Catalog_ВидыНоменклатуры

(93) зачем в этой теме? Вы ВидыНоменклатуры для одата опубликовали?

(94) Все по мануалу вроде сделал.

https://infostart.ru/1c/articles/1570140/

По версиям вот кое-что нашел
http://catalog.mista.ru/1c/articles/913435/
"Хуже всех, во всех тестах  себя показал MSSQL 2014! Часто возникали ошибки при тестировании."
Как раз эта и установлена на сервере.
Ну и по тестам
https://www.tableau.com/about/blog/2016/3/announcing-real-time-analytics-sql-server-2016-our-performance-test-results-51385
" Самый продолжительный запрос выполнялся за 3,83 секунды в SQL Server 2016 по сравнению с 3048 секундами в SQL Server 2014 - это повышение производительности в 795 раз!"
Т.е. вполне реально, что на 2014 SQL база вешается, а на 2019 нормально формируется отчет.

Ну-с, осталось взять себя за помидоры и наконец таки заапдейтить SQL-сервер в продуктиве, до 2019

(95)
// создаём массив метаданных
Массив = Новый Массив;
Массив.Добавить(Метаданные.Справочники.Контрагенты);
Массив.Добавить(Метаданные.Справочники.Номенклатура);
// активируем
УстановитьСоставСтандартногоИнтерфейсаOData(Массив);

Добавьте в массив еще и виды номенлкатуры

(98) Уже. Сам. Успел. Спасибо тем не менее

(92) Магия, епт.

(100) Ага, магия :)
Или мне кажется или так и есть: полное соединение и отдельные врем. таблицы по скорости одинаково ?

Только что-то мне разонравился вариант с WEB-сервисом. Сделал через HTTP и туда передаю сам текст запроса и параметры.
В таком случае и раскидывать по временным таблицам не нужно.  
Да и проще перенести в расширение, что я и сделал.