Крючков Владимир

4958
Рейтинг

ivanov660
Владимир Крючков



  •   Регистрация: 02.02.2011 (15 лет назад)

  •   Был(а) на сайте: вчера в 11:30

Друзья
  • Alexander Kondrin
  • Антон Коваленко
  • Артур Аюханов
  • Группа Полипластик
  • Александр Алехин
  • Александр Егоров
  • Дмитрий Виссаров
  • Карина Арсенян
  • Евгений Комиссаров
  • Ольга Терскова
  • Димтрий Павлюченко
  • Дмитрий Котов
  • Виктор Клевцов
  • Константин Скворцов
  • Игорь Антонов
  • Дмитрий Малышев
Подписчики 406
Группы

Профессиональный разработчик

IE 2017 Докладчик

IE 2018 Докладчик

IE 2019 Докладчик

Докладчик Meetup

IE 2021 Докладчик

Лауреат Infostart Awards

IE2021_msk Online

IE2022 Докладчик

IE2023 Докладчик

TEAMLEAD EVENT 2025 Докладчик

Рейтинг 4958

Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности
+37 –

Статья Программист 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free) Нет файла HighLoad оптимизация

Можно существенно ускорить расчет себестоимости почти без программирования

22.12.2025    2348    ivanov660    49       

37
Проблемы производительности: Поля через несколько точек в условиях соединений
+32 –

Статья Программист 1С:Предприятие 8 Универсальные Бесплатно (free) Нет файла HighLoad оптимизация

Рассмотрим, что происходит при отступлении от стандартов разработки.

25.11.2025    3523    ivanov660    33       

32
Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres
+52 –

Статья Программист 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free) Нет файла HighLoad оптимизация

Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.

10.11.2025    6500    ivanov660    48       

52
Используем частотный анализ количества выполненных запросов для выявления проблем оптимизации
+25 –

Статья Для всех Универсальные Бесплатно (free) Нет файла HighLoad оптимизация

Влияние сортировки на быстродействие динамических списков.

27.10.2025    3246    ivanov660    8       

25
Проблемы производительности. Особенности подсчета количества строк в таблице данных СУБД Postgres
+19 –

Статья Программист 1С 8.3 Универсальные Бесплатно (free) Нет файла HighLoad оптимизация

Расскажем, как выполняется подсчет количества записей и что можно улучшить.

20.10.2025    2235    ivanov660    7       

19
Проблемы производительности. Оператор различные в динамических списках
+61 –

Статья Программист 1С:Предприятие 8 1C:ERP Бесплатно (free) Нет файла HighLoad оптимизация

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

18.02.2025    8920    ivanov660    39       

61
Проблемы производительности. Индексация с дополнительным упорядочиванием
+57 –

Статья Системный администратор Программист 1C:ERP Бесплатно (free) Нет файла HighLoad оптимизация

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

04.02.2025    7431    ivanov660    21       

57
Поиск дублей по полям ключей шапки, табличных частей (используем hash функцию)
+24 –

Статья Программист 1С:Предприятие 8 Универсальные Бесплатно (free) Нет файла Математика и алгоритмы Запросы

Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.

08.07.2024    4930    ivanov660    9       

24
Поиск и анализ длительных вызовов - CALL, SCALL
+64 –

Статья Системный администратор Программист Универсальные Бесплатно (free) Нет файла HighLoad оптимизация Технологический журнал

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    11356    ivanov660    13       

64
Простой менеджер данных (simple data manager)
+84 –

Инструменты и обработки Программист 1С:Предприятие 8 Универсальные Абонемент ($m) Внешняя обработка (ert,epf) Перенос данных 1C

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

3 стартмани

13.06.2024    9435    107    ivanov660    36       

84
Смотреть все

Комментарии

HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #48 05.02.26 13:02
(47)
1. Коллега, предлагаю вам сначала поставить себе монитор производительности и выполнить замеры, чтобы найти места где существуют проблемы в конкретной вашей ситуации!
2. Если место совпадает с описанным в статье, то решение у вас есть.
3. Если есть другие места, то тут надо решать по месту.

Вы же понимаете что поведение ЕРП зависит от данных и окружения. Мы по факту оптимизации решили более 50 задач связанных с проблемами производительности, а в статье приведена лишь одна из них.
HighLoad › Решение проблемы быстродействия в ERP на рабочем примере › #32 28.01.26 10:33
(31)
Данный замер выполнялся на боевой базе под нагрузкой. На момент проведения не было понятия, где проблема находится. У кого-то работало нормально, у кого-то были сложности.
Если знать где проблема и еще почему она проявляется, то можно сразу чинить) А вот найти где и почему - это один из сложных вопросов. К тому же, ТЖ позволяет получить больший объем информации нежели простой замер времени. Т.е. подбор подходящего инструмента зависит от ситуации и окружения.
HighLoad › Проблемы производительности: Поля через несколько точек в условиях соединений › #34 09.01.26 22:56
(33) https://infostart.ru/1c/tools/936096/
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #46 30.12.25 13:03
(45) Я просил вести конструктивный диалог. Однако, с вашей стороны пока я вижу что возразить вам нечем, кроме как бросить пару пафосных и оскорбительных фраз без понимания сути. В общем мне не приятно с вами общаться.

А костыльным решением я назвал его потому что реализовать полноценно не получится из коробки для всех из-за лицензионных ограничений.
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #44 29.12.25 20:51
(43)
Цитата
Но предложение костылить индексы в сторону справочников, а не регистров выглядит сомнительным.
Будьте любезны и просветите меня в сомнительных сторонах данного предложения
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #42 29.12.25 12:17
(41) Видимо вы не внимательно прочитали - регистры сведений про которые я написал являются вспомогательными техническими. А речь идет про быстродействие, а не про логику ЕРП.
И дополнительно выносить в текущий момент все на справочники не получится, т.к. функционал доступен только КОРП лицензиям.
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #38 24.12.25 22:15
(37) Видимо речь идет про актуализацию статистики. Обычно планировщик СУБД при формировании плана запроса и выборе подходящего источника смотрит статистику.
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #35 24.12.25 8:35
(33) У меня только один комментарий - facepalm

Прикрепленные файлы:

star-trek-facepalm.gif
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #34 24.12.25 8:33
(32) А вас не смущает тот факт что в исходном запросе уже существует внутреннее соединение с регистром сведений по ключу аналитики? И этот регистр используется по всей конфигурации, даже при формировании движений документов.

Цитата
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.АналитикаУчетаНоменклатуры КАК АналитикаОтбора
ПО (ИсточникБазы.АналитикаУчетаНоменклатуры = АналитикаОтбора.КлючАналитики)

Сформулируем ваш послы правильным образом:
Если у вас в 1С проблемы с данными, то устраните эти проблемы. Т.к. 1С по умолчанию считает что проблем у вас нет!
HighLoad › Ускоряем расчет себестоимости в пару строчек кода. Проблемы производительности › #30 23.12.25 16:02
(29) Предлагаю вам почитать матчасть, прежде чем делать необоснованные заявления.

Возьмем рекомендации от компании 1С "Эффективные условия запросов"(
https://its.1c.ru/db/v8std/content/658/hdoc), которые они по идее должны соблюдать.

Цитата
1. Условия запросов должны быть написаны оптимально с точки зрения производительности, чтобы исключить существенное увеличение длительности выполнения запросов при увеличении объема данных в таблицах.
...
Цитата
Для условий в ПО ЛЕВОГО соединения следует индексировать поля в правой таблице.

Берем сам запрос и смотрим как тут получается:

Цитата
ВНУТРЕННЕЕ СОЕДИНЕНИЕ АналитикиЗаказов КАК АналитикиЗаказов
...
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.КлючиАналитикиУчетаНоменклатуры КАК АналитикаЧерезТочку
ПО (АналитикаЧерезТочку.Ссылка = ИсточникБазы.АналитикаУчетаНоменклатуры)
ПО (АналитикиЗаказов.РегистраторСебестоимости = ИсточникБазы.Регистратор)
И (АналитикиЗаказов.Номенклатура = АналитикаЧерезТочку.Номенклатура)
И (АналитикиЗаказов.Характеристика = АналитикаЧерезТочку.Характеристика)
И (АналитикиЗаказов.Назначение = АналитикаЧерезТочку.Назначение)
И (АналитикиЗаказов.Склад = АналитикаЧерезТочку.МестоХранения)
И (ИсточникБазы.СлужебноеВидДвиженияПриход)
И (ИсточникБазы.Организация = ДД.Организация)

Правая таблица у нас запросе это справочник "КлючиАналитикиУчетаНоменклатуры" с псевдонимом "АналитикаЧерезТочку" и соответственно для нее должны быть созданы индексы, которых нет.
А вот у регистра сведений "АналитикаУчетаНоменклатуры" с этим все в порядке (с индексами).

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