Привет всем. Был релиз КА2 2.4.13.243. Время проведения документов: От 2 до 5секунд. Обновили до релиза 2.5.7.255. После обновления релиза - проведение документов существенно увеличилось (от 9 до 17 секунд).
Замеры производительности показывают, что львиная доля проведения занимает функция СтрЗаменить(), т.к. вызывается она много тысяч(миллионов) раз и занимает 66% от всего проведения.
В универсальной процедуре собирается запрос по отражению документа, текст запроса большой, никаких кэширований, для каждого документа вызывается и собирается запрос заново.
Вот сама процедура: ПроведениеДокументов.ДополнитьЗапросОтраженияДокумента(Запрос, ТекстыЗапроса, ТекстыШаблоновОтражения, ТекстыЗапросовДанныхДокумента, ТекстыШаблоновВТ)
Вопрос: У кого нибудь есть такие же проблемы, что после обновления на 2.5 документы стали проводиться существенно дольше?

(0) Есть подозрение, что у вас еще не завершился переход на новую версию. Отрабатывает фоновое задание по переходу на новую версию. Что показывает Интернет поддержка и сервисы/Результат обновления программы? Все ли обработчики завершены?

(1)Поддержу. Сделал пробное обновление. Операций по завершению обновления 454.

(1) Все обработчики завершены (458)

(3) Журнал регистраций 1С какого размера сейчас? Ну или вся папка Кластера 1С.

(0) Ну а теперь объясните, как проводите документы. И почему у вас СтрЗаменить() вызывается миллионы раз. Что с доработками, есть ли активные расширения?

(0) а почему не посмотреть откуда и зачем она вызывается

// Вопрос: У кого нибудь есть такие же проблемы, что после обновления на 2.5 документы стали проводиться существенно дольше?

Ответ: кто-нибудь не рискует срочно и обморочно переходить на 2.5 с 2.4 типовым способом, т.к. там проблем будет выше крыши
даже не обращая внимания на наличие вызова ПроведениеДокументов.ДополнитьЗапросОтраженияДокумента

Так что, не переходить? у нас доработанная, ну нужна вся эта история с фсбу!!

(0) А в замечаниях к выпуску ничего про 20 релиз платформы не говорится? Может они там под это дело СтрЗаменить() радикально оптимизнули? :)

(8) очень рисковано. Можете попробовать на копиях, потому что все доработки придется написать заново.

(5) Запускали групповое перепроведение документов.
Вот пример замера производительности при проведении одной реализации товаров:
https://ibb.co/tDDryTs
34.74% + 13.89% - занимает как раз СтрЗаменить. Если запускать групповое перепроведение, то этот процент ещё больше.
Очистка кэша не помогла. С серверами все нормально, т.к. их не меняли при обновлении релиза.

(5) Конфа типовая никаких доработок и расширений.

(12) Пишите в техподдержку 1С. Если это ошибка, поправят. Это будет всяко быстрее, чем самому корячиться. Раз доработок нет, тогда это самый легкий путь.

(11) бред. В (0) про миллионы вызовов, а в реальности их 600(+-). Не может СтрЗаменить столько выполняться, скорее всего отладка не те строки показывает. Ну или какой другой глюк платформы.
Кэш чистили?

Продолжение расследования. Подняли демо базу с тем же релизом. Сделали замер производительности при проведении реализации в обоих базах. В демо базе строка с СтрЗаменить() работает гораздо быстрее, чем в нашей базе. Количество вызовов одинаковое.
Замеры производительности: https://ibb.co/mD7vqKy
Кэш чистили не помогает. Копаем дальше.

(14) Про миллионы вызовов это я писал, когда был групповое проведение документов. На один документ приходится по 300- 620 вызовов. Документов было запущено 120 тыс. на проведение до этого.

(15) Может у вас как-то так случилось, что на боевой базе и на сервере разрабов разные версии платформы? Или это все на одном сервере происходит?

Базу для тестирования откуда взяли? Я бы подозревал, что при создании копии боевой для тестирования недосмотрели чего-то

(17) SQL сервер один и тот же. Платформа одна и та же. Пользователей нет, никто в базах не работает. Регламентные задания включены в обоих базах, но ничего не выполняется в данный момент.

Всем спасибо. Проблема решилась после: 1) остановкой службы 1С 2)очистки серверного кэша
До этого очищали локальный кэш. Прошу прощения за недоразумение головного мозга.

Серверного кеша не существует.

(20) Существуют сеансовые данные в C:\Program Files\1cv8\srvinfo\reg_1541\snccntx*
И да запросто может быть что если не было рестарта сервера после обновления конфы то там куча хлама от старой конфы

(20) (21) /Clearcache ?

(22) может на новых платформах это и сраатывает, но раньше от этого ключа очистка как в (21) не работает

(22) https://its.1c.ru/db/metod8dev#content:5899:hdoc:примеры%20скриптов
Остановка службы 1С:Предприятие с очисткой временных файлов.
Разумеется в переменные подставить надо свои пути к папке srvinfo и имена служб (если у вас не х86-64).

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%