Уважаемые специалисты, посоветуйте пожалуйста: конфигурация КА2 начала притормаживать после последнего обновления. В ней используется  несколько расширений, которые писались, чтобы не устраивать массовое выгоняние из базы - в расширениях только заимствованные документы (менялись их процедуры). Стоит ли постараться по максимуму перетащить изменения из расширения назад в конфигурацию? Все измененные документы - добавлены нами в процессе работы, в оригинальной КА2 их не было. Если это сделать и удалить в расширении те документы - будет ли хоть чуть-чуть добавление скорости запуска и работы 1С?

нет не будет

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

(2) Не верь (1). Он все врет. Если удалить это минимум в 2-3 раза увеличит скорость

Опять эти двое маются.
Автор, переноси на postgre, новые релизы на ней летают.

(1) Прав.

(3) Давай голосовалку замутим по выбору одного из двух твоих мнений.

(0) > расширений, которые писались, чтобы не устраивать массовое выгоняние из базы.

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

(0) >> конфигурация КА2 начала притормаживать после последнего обновления.

Я понимаю, когда пользователь начинает подобную ахинею нести. Но ты ж типа специалист. Ты должен оперировать конкретными показателями и результатами их сравнения "до" и "после". А с такими формулировками надо в ООН писать в суд по правам человека и пользователя.

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

(7) ну одно дело расширение в закрытие месяца которое раз в месяц вызывается, а другое дело в реализации. Или в механизме нумерации которая используется для всего И как тут оценишь производительность. На сколько подниматься общая производительность при удалении расширения. Ну где то от 0 до 2-х раз, плюс минус в этом диапозоне

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

Это новые платформы тормозят 8.3.12 и 13 просто жесть
Особенно чувствуется в файловых

Давно не было такой подлянки от 1С

нужно просто определить, а что именно обновлялось. Платформа подтормаживает - такие очучения мои, а не пользователей. НО!
Если взять просто платформу и просто создать на ней пустой конфиг и начинять его (конфиг т.е.) постепенно всякими потрохами, то тормозов и не видно. Даже не понятно, сколько придется нагружать конфиг всякой всячиной, чтоб он начала тормозить.

Но когда к готовой конфигурации, например БП3 или ЗУП3 прикручиваешь новую платформу - явно падает скорость работы в программе. Кто там больше виноват: платформа или конфигурация - загадка

https://its.1c.ru/db/metod8dev#content:5940:hdoc

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

Кажется, это субъективно.
Бабахнуть замеры времени на критичные операции на тесте и запустить 1000 раз к примеру.
А потом перенести из расширений.
и бахнуть еще 1000 раз.
И сравнить, вот это было бы уже объективно.

Аналогично проверять после обновлений стало хуже или нет

(16) а у них есть альтернатива?

(17) Ты как бетатестер продуктов 1с должен отписываться на бугрепорт в таких случаях. Говорят они даже исправляют иногда)

А из жизни - один раз начался вой что "послевашегообновлениявсесломалось", открываю замер производительности, а тама мама родная уже год как все сломалось, просто присели на уши новенькому

(0) Сейчас у клиента периодически бывают адские подвисания со 100% нагрузкой. В это время может рабочий процесс отвалиться и всех вышибить, платформа у всех пользователей висит и не реагирует ни на что.
P.S: 8.3.13.1690, началось после обновления бухгалтерии с режимом совместимости 8.3.12.
Расширения и до этого были, тормозов не было.

(20) Тут тебе в ТЖ надо.
Может появился юзер который смотрит отчеты без отборов по времени или намудрил в компановке что то ядреное

(20) ну я у себя массово только на 8.3.12 решился. Так что на глюки с совместимостью с 8.3.12 пожаловаться не могу.
А решился на смену платформы с 8.3.10 на 8.3.12, а не еще выше, как раз после чтения отзывов на мисте, из которых сделал вывод о высоких рисках в работе с 8.3.13

рабочий процесс отвалиться и всех вышибить - постоянно такое встречал когда временная таблица в запросе получается БОЛЬШАЯ.
Смотрим кто и обучаем отборам

(22) я 8.3.13 так нигде и не запустил что то да отваливалось, а потом забил

как то так само собой получаются только четные релизы после 8.2 ставил : до 8.3.8 не помню что было, но 8.3.10 теперь на 8.3.12 заменяю

(25) 12 на старте то еще говнецо было.
Там аггреганая функция в запросе сломалась.
Починили конечно быстро, но мне в зад шишек напихали

(26) ну так выждал до последнего и теперь на нее

Для периодических регистров сведений, подчиненных регистратору и имеющих периодичность, отличную от "По позиции регистратора", после проведения документа-регистратора запрос к таблице СрезПоследних возвращает неправильные данные.
Вот еще из багтрекера 12 релиза

(21) Появились из другой учетной системы, которые передают текст модуля по веб-сервису и через выполнить им возвращается результат. Гляну что там передают, сразу на них подумал. Но они клялись и божились...

(29) Хорошей практикой, у меня по крайней мере, считается записывать в РС то, что приходит в веб сервис.
Очень много раз помогало в расследованиях

(30) Да на прошлых проектах так и делал. А тут они работы должны были сдать в прошлом году и свалились как снег на голову...

(31) А не боишься что прийдет что то неваллидное, типо удаления всей номенклатуры или выгрузки всех ЛПР из базы?

(32) Я клиента предупредил письменно :) А так - копии каждый час + скидывается на другой сервер ночью.

(20) вообщем, делюсь горьким опытом.
Причину загрузки 100 удалось локализовать:
В базе включено было 3 расширения, в одном из них была добавлена обработка и включена в две подсистемы.

Сегодня на сервере каждую минуту заново создавались rphost и перекидывались пользовательские сеансы (до этого тоже фризило, но эпизодически). В ТЖ ничего внятного не пишется, кроме потери соединения.
В это время сам сервер 1С (после добавления ещё 4 ядер) до 100 не нагружается. Интерфейс у всех подвисает, плюс долгий вход в программу, нажимаешь о программе и ещё минуты 2 тупит.
Настройки сервера были дефолтные. Выявил подлеца только с помощью установки один rphost на 1 базу (всего около 10 их), 9 сразу залетали, а одна фризила.
Перед этим останавливал сервер, чистил серверный кэш - помогало на минут 5-10 и все по-новой.

Снял галочку использования данного расширения и сразу залетало (два других остались включенными). Буду на тестовой экспериментировать и писать уже в 1с, ветки почитал - такие проблемы у людей уже были, 3 месяца никак не могут решить.

Надеюсь, кому-нибудь поможет в выявлении проблемы.

P.S: данное расширение добавляли подрядчики через пользовательский интерфейс.

// Выявил подлеца только с помощью установки один rphost на 1 базу (всего около 10 их)

Отзыв классный, но весьма удивительно, что этой настройки ""один rphost на 1 базу"" не было сделано заранее.

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

(35) 8 баз из 10 - архивные (старые редакции и до свертки - прошлый год, делали из-за изменения аналитики с 2019г), людей немного - всего 100-120 онлайн.
>700 человек онлайн - там да, сразу настраивал.

(4) тс ж не пишет про субд.. с чего бы переносить?

(8) записал. делал такое, что нумерация перенес в расширение, чтобы клиент мог обновлятся без программистов... благо, перед тем, как решили мне не заплатить - пусть теперь сосут у 1С с расширениями))

(38) СУБД - MSSQL, перенести на Postgre невозможно, потому что настройкой СУБД занимаются другие люди и доказывать им что-то проблематично. По этой же причине я несогласен с (6) - какой я специалист, если у меня все права порезаны?

Сейчас тормоза почти ушли: я настроил регламенты СУБД в соответствии с рекомендациями 1С и отключил часть ненужных проверок, которые нужны только одному пользователю (обмен электронными документами с фискальными органами). Но что-то иногда ещё подвешивает клиента и я пока не понял, как это отловить...