Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

02.03.22

База данных - HighLoad оптимизация

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

 

Инфраструктура исследуемой системы

 

          Технологическая платформа 1С:Предприятие 8, версия 8.3.19.1417

          Конфигурация: 1С:ERP Управление предприятием 2, версия 2.5.6.291

Операционная система: Windows Server 2019 Standard

          СУБД: Microsoft SQL Server 2019

 

Проблема

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

Согласно данным подсистемы БСПОценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд  в его финале.
 

Задача

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


Решение

1. Первым делом проверяем корректность записанных замеров и локализуем проблему: клиент или сервер? Для этого сравниваем выборочно длительности замеров подсистемы “Оценка производительности” с длительностью события CALL технологического журнала 1С на сервере. Данные совпадают, следовательно, клиентские замеры верны, проблему необходимо искать на сервере.

 

2. Далее анализируем данные счетчиков производительности. Определяем, справляется ли оборудование. По показателям видно – во время тестирования высокой нагрузки на сервере приложений 1C и СУБД не наблюдается. 

% использования CPU в среднем менее 50%:

 

 

Объем свободной оперативной памяти более 200ГБ:

 

 

Высоких очередей на диски нет:

 

 

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

 

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

 

Время вызова

Сеанс

CALL

DBMSSQL

SCALL

TLOCK

13:07:30.364007

6210

70 125 988

3 792 993

531 081

6 236 358

13:07:37.551009

6208

76 220 002

4 306 155

511 998

10 000 353

 

Видим, что есть ожидания на управляемых блокировках (TLOCK) и запросы к базе данных (DBMSSQL), но их длительность в сумме составляют не более 15% от длительности клиент-серверного вызова. На что тратятся оставшиеся 85% времени, по-прежнему непонятно.

 

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


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


Получаем несколько проблемных контекстов, первый:

06:20.488056-37,SDBL,3,process=rphost,p:processName=erp,OSThread=10300,t:clientID=827,t:applicationName=1CV8C,t:computerName=ERP01,t:connectID=17392,SessionID=6210,Usr=user,AppID=1CV8C,DBMS=DBMSSQL,DataBase=db01\erp,Trans=0,Func=insertRecords,tableName=#T06036ff19e4b4edebb79e14a39f4ed41,Rows=0,Context='Форма.Записать : Документ.ПриобретениеТоваровУслуг.Форма.ФормаДокумента
Документ.ПриобретениеТоваровУслуг.МодульОбъекта : 375 : ОбщегоНазначенияУТ.ПроверитьЗаполнениеКоличества(ЭтотОбъект, ПроверяемыеРеквизиты, Отказ);
    ОбщийМодуль.ОбщегоНазначенияУТ.Модуль : 4090 : ПроверитьОкруглениеКоличества(Объект, Отказ, ПараметрыПроверки);
        ОбщийМодуль.ОбщегоНазначенияУТ.Модуль : 4333 : Выборка = Запрос.Выполнить().Выбрать();'

06:32.128002-1,DBMSSQL,5,process=rphost,p:processName=erp,OSThread=10300,t:clientID=827,t:applicationName=1CV8C,t:computerName=ERP01,t:connectID=17392,SessionID=6210,Usr=user,AppID=1CV8C,DBMS=DBMSSQL,DataBase=db01\erp,Trans=0,dbpid=58,Sql='SELECT TOP 2
T1._Fld34846
FROM dbo._Const34845 T1',Rows=1,RowsAffected=-1,Context='Форма.Записать : Документ.ПриобретениеТоваровУслуг.Форма.ФормаДокумента
Документ.ПриобретениеТоваровУслуг.МодульОбъекта : 375 : ОбщегоНазначенияУТ.ПроверитьЗаполнениеКоличества(ЭтотОбъект, ПроверяемыеРеквизиты, Отказ);
    ОбщийМодуль.ОбщегоНазначенияУТ.Модуль : 4090 : ПроверитьОкруглениеКоличества(Объект, Отказ, ПараметрыПроверки);
        ОбщийМодуль.ОбщегоНазначенияУТ.Модуль : 4333 : Выборка = Запрос.Выполнить().Выбрать();'

 

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

 

Следующий контекст:

06:43.066016-63016,SDBL,4,process=rphost,p:processName=erp,OSThread=10300,t:clientID=827,t:applicationName=1CV8C,t:computerName=ERP01,t:connectID=17392,SessionID=6210,Usr=User,AppID=1CV8C,DBMS=DBMSSQL,DataBase=db01\erp,Trans=1,Sdbl='SELECT ALLOWED
****************************
INTO #Tfef0a9ac00bd44c890415f30c2ad08af
FROM
#T3300dee202d84412a982e91daf772310 Q_001_T_001 LEFT JOIN InfoRg45048 Q_001_T_002 ON (Q_001_T_001.Q_000_F_001  =  Q_001_T_002.Fld45050) INNER JOIN Reference351 Q_001_T_003 ON (Q_001_T_001.Q_000_F_001  =  Q_001_T_003.ID) INNER JOIN Reference352 Q_001_T_004 ON (Q_001_T_001.Q_000_F_000  =  Q_001_T_004.ID)
WHERE
(Q_001_T_004.Fld59648  =  351:00000000000000000000000000000000)
',Rows=1,Context='Форма.Записать : Документ.ПриобретениеТоваровУслуг.Форма.ФормаДокумента
Документ.ПриобретениеТоваровУслуг.МодульОбъекта : 855 : НоменклатураПартнеровСервер.ЗаполнитьПустоеСопоставлениеВНоменклатуреПартнераПоНоменклатуреИБ(Товары, Отказ);
    ОбщийМодуль.НоменклатураПартнеровСервер.Модуль : 335 : СопоставлениеНоменклатурыКонтрагентов.ЗаполнитьПустоеСопоставлениеВНоменклатуреКонтрагентаПоНоменклатуреИБ(ТаблицаТоваров, Отказ);
        ОбщийМодуль.СопоставлениеНоменклатурыКонтрагентов.Модуль : 298 : Выборка = Запрос.Выполнить().Выбрать();'

06:50.409005-45997,DBMSSQL,5,process=rphost,p:processName=erp,OSThread=10300,t:clientID=827,t:applicationName=1CV8C,t:computerName=ERP01,t:connectID=17392,SessionID=6210,Usr=User,AppID=1CV8C,DBMS=DBMSSQL,DataBase=db01\erp,Trans=1,dbpid=72,Sql='SELECT
T1._Q_001_F_000RRef,
****************************
',Rows=0,RowsAffected=0,Context='Форма.Записать : Документ.ПриобретениеТоваровУслуг.Форма.ФормаДокумента
Документ.ПриобретениеТоваровУслуг.МодульОбъекта : 855 : НоменклатураПартнеровСервер.ЗаполнитьПустоеСопоставлениеВНоменклатуреПартнераПоНоменклатуреИБ(Товары, Отказ);
    ОбщийМодуль.НоменклатураПартнеровСервер.Модуль : 335 : СопоставлениеНоменклатурыКонтрагентов.ЗаполнитьПустоеСопоставлениеВНоменклатуреКонтрагентаПоНоменклатуреИБ(ТаблицаТоваров, Отказ);
        ОбщийМодуль.СопоставлениеНоменклатурыКонтрагентов.Модуль : 298 : Выборка = Запрос.Выполнить().Выбрать();'

Опять контекст одинаковый, опять пакетный запрос и работа с временными таблицами…

 

5. Похоже, что это может быть проблемой на уровне технологической платформы 1С. Возможно, об этом уже сообщалось вендору и сообществу? Ищем что-то похожее в сервисе публикации ошибок 1С https://bugboard.v8.1c.ru/, а также на партнерском форуме https://partners.v8.1c.ru/forum.

 

6. В результате поисков  обнаруживаем похожую ошибку https://bugboard.v8.1c.ru/error/000109738 и обсуждение https://partners.v8.1c.ru/forum/topic/1981666. Так как ошибка исправлена в релизе платформы 1С версии 8.3.20.1549, обновляем тестовый стенд на последнюю актуальную версию платформы (на момент написания статьи – 8.3.20.1613). После чего заново проводим нагрузочное тестирование: деградация производительности больше не возникает.

 

Выводы и рекомендации

  • Сложно переоценить важность проведения тестирования – функционального, либо нагрузочного.
  • Перед установкой нового релиза прикладного решения и/или технологической платформы 1С рекомендуется всегда выполнять такого рода исследования.

     

Расследование проводил: Георгий Бяков
Эксперт по технологическим вопросам

ИТ-Экспертиза

эксперт быстродействие erp 1С:Эксперт технологическим вопросам платформа деградация производительности производительность высокая нагрузка

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122160    670    389    

714

Валидация JSON через XDTO (включая массивы)

WEB-интеграция Универсальные функции Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.

28.08.2023    8821    YA_418728146    6    

141

Все консоли запросов для 1С

Запросы Инструментарий разработчика Бесплатно (free)

Список всех популярных обработок.

17.03.2023    35542    kuzyara    84    

179

Версионирование объектов VS История данных

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Давайте разберемся в механизме «История данных» и поэкспериментируем для наглядности. Сравним «Версионирование объектов» и «Историю данных».

06.03.2023    18949    dsdred    54    

193

Шпаргалка по функциям АСИНХ

Механизмы платформы 1С Платформа 1С v8.3 Россия Бесплатно (free)

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

29.07.2022    41840    zeltyr    23    

194

Динамическое обновление - это зло?

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Копнем глубже в тему "Что же такое динамическое обновление" и почему оно может привести к проблемам. И может ли?

09.05.2022    26870    Infostart    83    

243

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    17193    ivanov660    18    

157

Стек технологий для 1С

Инструментарий разработчика Рефакторинг и качество кода Групповая разработка (Git, хранилище) Механизмы платформы 1С Бесплатно (free)

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

29.11.2021    43676    mrXoxot    63    

464
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. capitan 2466 02.03.22 17:08 Сейчас в теме
Георгий, в описанных bugboard событиях речь идет о деградации при последовательном выполнении нескольких пакетов запросов с использованием одного менеджера временных таблиц.
У вас совсем другой случай.
Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале

Это независимое событие, а не часть цепочки с одним менеджером временных таблиц.
Плюсом к этому задержка в 12 секунд не попадает в ошибку 150-200 секунд
Может надо в студию выложить ТЖ по длительности CALL в начале тестирования и в финале?
Или копнуть в сторону как у вас при тестировании вызывается “Проведение документа поступление товаров и услуг”
Интересно, что скажет на это Елена Сворцова, да прославится ее имя во всем ютюбе
Serg O.; sasha_r; it-expertise; +3 Ответить
3. it-expertise 324 02.03.22 21:10 Сейчас в теме
(1) Елена Скворцова подготовила ответ:

Независимым (если я правильно поняла, о чем речь) является событие CALL. Именно его длительность росла.
Внутри него выполняется множество других событий, в том числе запросов -DBMSSQL, каждый запрос логируется отдельно. Эти запросы являются (могут являться) частью пакета (цепочки пакетов) и использовать один МВТ.

Таких цепочек внутри одного CALL может быть больше одной, и таких "промежутков" между событиями, когда как будто бы не выполняется ничего, было много, кроме того, то, что в начале могло быть 12 секундами, к концу теста могло увеличиться. Так мы получаем CALL итоговой длиной 200 секунд.

Возможно, действительно стоило его привести в статье для наглядности в начале и в конец теста, но можно просто поверить :)
Что касается того, как при тестировании вызывается проведение документа Поступление товаров и услуг, то полагаю, что выполняется получение формы, после чего вызывается ее метод Записать или соответствующая команда формы, на что как бы намекает контекст, приведенный в статье.
Думаю, что автор статьи и расследования прояснит этот и другие моменты гораздо лучше
4. starik-2005 3033 02.03.22 23:43 Сейчас в теме
(3)
то, что в начале могло быть 12 секундами, к концу теста могло увеличить
Ужос! СДЕК пытаются сделать на 1С запись 4кк документов в сутки (с перспективой роста), а мы же знаем, что в одном дне 86400 секунд. Отсюда как бы вывод, что у правильных пацанов за одну секунду будут проводиться.... 50+ документов. Как так, да? ))) Я, конечно, намекал им, что писать 50 документов в секунду можно, но просто писать - это бессмысленно, нужно еще и читать, собирать отчеты, отдавать их в процессинговые центры... Но кто об этом думает-то? Это вторая задача )))
sasha_r; it-expertise; +2 Ответить
6. capitan 2466 03.03.22 09:29 Сейчас в теме
(4)Вы не путайте документы СДЕК и торговые документы
it-expertise; +1 Ответить
11. starik-2005 3033 03.03.22 11:17 Сейчас в теме
(6) А чем поступление товаров и услуг отличается от документа взаиморасчетов тех же? Поступление - это просто фиксация в регистрах новых остатков товаров и взаиморасчетов. Да, плюс товары и куча всех тех паразитных движений, которые денормализуют базу и деморализуют разработчика ))) Но суть в том, что докумменты поступления могут проводиться параллельно, что далеко не всегда для документов реализации, с которыми может быть все куда веселее.
roman72; Jimbo; +2 Ответить
13. capitan 2466 03.03.22 11:22 Сейчас в теме
(11)Хотите сказать, что у СДЕК на 1С запись 4кк документов в сутки документов взаиморасчетов?
15. starik-2005 3033 03.03.22 11:23 Сейчас в теме
(13) хочу сказать, что к ним пришли люди и показали, что это в принципе возможно. По крайней мере они так сказали. И это в принципе возможно, если ересь 1С-ную из обработки проведения выкинуть. Они вроде как решили пойти по этому пути.
17. capitan 2466 03.03.22 11:29 Сейчас в теме
(15)у разных документов разная логика
если взять конфигурацию из 1 документа и 1 регистра с ключом по УИД отправления то и 400кк можно наколбасить
20. starik-2005 3033 03.03.22 11:33 Сейчас в теме
(17) что-то сомневаюсь, что 400кк (5000 в сек) документов 1С в принципе способна записать и провести (положить в регистр). Даже с регистрами там туго все - 120кк паспортов недействительных, отсортированных даже, система на обычном омериканском процессоре класса ксеон поколения ТРИ записывает часа ЧЕТЫРЕ. Многопотоку тут сильно мешает эскалация блокировок с определенного количества записей, и это количество весьма невелико...
23. capitan 2466 03.03.22 11:35 Сейчас в теме
(20)Если всю базу на рам диск положить, то все возможно
25. starik-2005 3033 03.03.22 11:37 Сейчас в теме
(23) это как в мульте про говорящую рыбу: а город-то наверное меленький... Тот город заяц бежал - не перебежал... Так заяц-то видимо крошечный... Да из того зайца тулуп вышел )))
27. capitan 2466 03.03.22 11:40 Сейчас в теме
(25)Ну мы то здесь не про 400кк документов собрались
Но 99.99% что можно такую базу сделать и провести
48. roman72 379 09.01.23 22:10 Сейчас в теме
(23) А можно здесь поподробнее?
Я ранее был фанатом выкладки всей базы в RAM-диск.
Но вот в течение двух лет уже два разных ит-специалиста в разных компаниях мне говорили, что скорости nvme-дисков уже настолько высоки, что близки к скоростям оперативной памяти (т.е. RAM-дисков).
В контексте что RAM-технологии уже устарели для решений 1С.
38. Nikola23 696 03.03.22 22:49 Сейчас в теме
(20) Сомневаетесь - проверяйте. Или аргументы в студию.
Никто не знает какая логика проведения. Включено ли оно вообще, считаются ли онлайн итоги
Это 4кк одинаковых документов или 400 разных видов по 100 000 штук.

И еще куча если.
it-expertise; +1 Ответить
41. starik-2005 3033 04.03.22 10:57 Сейчас в теме
(38)
проверяйте
Ну так всегда можно оттолкнуться от минимума - документ с двумя, пусть, реквизитами (контрагент, сумма) и регистр накопления с этими же двумя реквизитами, ну и код формирования движений. Есть у Вас железо, которое может обеспечить запись 5к таких документов? Ну и не забываем, что они должны быть где-то сгенерированы (в примитивном случае массив контрагентов длиной Х, индекс в котором выбирается рандомом, плюс рандомная сумма - это, полагаю, будет быстро работать). В один поток файловая 1С дает записать не сильно много таких объектов, серверная в один поток примерно в два раза медленнее, значит потоков надо в четыре раза больше (заложиться на деградацию производительности в ходе роста нагрузки). Я готов протестить этот минимум, дальше можно будет понять, что на данном железе максимальная производительность вот такая для такого примитивного документа, значит для любого более сложного необходимо будет больше ядер, быстрее проц, более быстрое устройство хранения ну и т.д.
42. Nikola23 696 04.03.22 12:12 Сейчас в теме
(41) если готовы - очень интересен результат.
Но учтите, что контрагенты должны сильно отличаться, чтобы не блокировать регистр по измерению...

Да и потоков надо не 2/4, а 500).

У меня под рукой подходящего сервера пока нет.
5. capitan 2466 03.03.22 09:26 Сейчас в теме
(3)Независимым является каждое проведение документа Поступление товаров и услуг
Крайне маловероятно, что два и более проведений используют один менеджер временных таблиц.
Если это так, то это ошибка в конфигурации, а не в платформе.
Либо вы при тестировании не закрываете форму документа и проводите его многократно, это ошибка в построении тестового контура.

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

В описанных bugboard событиях говорится о совершенно другом примере
Столкнулись с проблемой постепенного замедления выполнения запроса (пакета) при работе алгоритма.

Алгоритм использует много ВТ (порядка 100) в ходе работы часть ВТ уничтожается и снова создаются (в них дописывается результат работы итерации), проблема в том что каждая следующая итерация немного дольше предыдущей, первая итерация выполняется порядка 5 мс, а последняя (12) уже порядка 80 секунд.


Тут на мой взгляд великая неувязочка

Хотелось бы конечно получить пояснение или логи ТЖ).
it-expertise; +1 Ответить
8. it-expertise 324 03.03.22 09:51 Сейчас в теме
(5) увы, но логи/ТЖ без разрешения клиента предоставить не можем. Что могли привести в статье для наглядности - сделали.
7. it-expertise 324 03.03.22 09:47 Сейчас в теме
(1) а вот и ответ Георгия (автора этого разбора):

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

Возможно стоило привести анализ вызова в начале нагрузочного тестирования и в его конце, учтем на будущее ;) . Итерация нагрузочного тестирования, при которой собирался полный технологический журнал для анализа, была прервана после того, как длительность выполнения ключевой операции выросла более чем в 4 раза. Этого достаточно для анализа. Поэтому проведен анализ вызовов длительностью около 70 секунд.

В статье приведены не все "дырки", их на самом деле было больше, но если приводить все эти контексты, то тексты логов сделают её нечитаемой. Цель статьи - описать методику анализа, поэтому старались кратко и по делу.

Тестирование проводилось силами заказчика, для этих целей они использовали Vanessa Automation со сценариями создания документов.
9. capitan 2466 03.03.22 10:31 Сейчас в теме
(7)
Возможно стоило привести анализ вызова в начале нагрузочного тестирования и в его конце, учтем на будущее

Не возможно, а точно надо было это сделать.
Иначе все привязки к указанным багфиксам превращаются в тыкву.
Может это вообще Vanessa Automation не дружила с текущей платформой и в ней вы поймали один менеджер временных таблиц на несколько проведений.
Не хочу метать камней в огород Vanessa Automation, но они вроде и не позиционируют себя как инструмент для нагрузочного тестирования.
Это кстати самое вероятное предположение.
Потому что если бы на каком то релизе платформы проведение документа поступление товаров и услуг возрастало в процессе работы пользователей до 150-200 то хелпдеск 1С бы просто разорвали
Также не совсем понятна группировка по типу события.
Если вы расследуете регрессию во времени, то группировка как раз вам мешает.
Неожиданный итог статьи: ошибку вы не поймали, и непонятно, возникла бы она в результате реальной работы или это проблема в тестовом контуре, но победили ее обновлением платформы.
36. ivanov660 4330 03.03.22 16:35 Сейчас в теме
(7) Я надеюсь, что Vanessa использовалась без API 1C Automation? т.к. правильное нагрузочное тестирование проводить через это апи нельзя.
2. starik-2005 3033 02.03.22 18:06 Сейчас в теме
Функциональное и нагрузочное тестирование (особенно в свете намечающейся массовой миграции с MS на PG, с W на L) - дело нужное и важное (must have), переоценить которое просто невозможно. Спасибо за еще одно напоминание о том, что без него вообще никак...
it-expertise; capitan; +2 Ответить
10. capitan 2466 03.03.22 10:34 Сейчас в теме
(2)
Вспоминается...
Вскрытие показало, что больной умер в результате вскрытия.

Функциональное и нагрузочное тестирование (особенно в свете намечающейся массовой миграции с MS на PG, с W на L) - дело нужное и важное (must have), переоценить которое просто невозможно.

В процессе обсуждения родилось некоторое дополнение.
Тестовый контур должен походить на реальный, иначе возможно просто тестирование тестового контура.
14. starik-2005 3033 03.03.22 11:22 Сейчас в теме
(10)
оцессе обсуждения родилось некоторое дополнение.
Тестовый контур должен походить на реальный, иначе возможно просто тестирование тестового конту
Но тут всегда есть возможность при проблемах реального контура и отсутствии проблем на тестовом просто поменять их местами )))

Понятно, что проводить нагрузочное тестирование на I9-12900K с DDR5-6200, а потом работать на современном целероне (ну или на аналогичном ему по производительности древнем ксеоне) - так себе идея.
16. capitan 2466 03.03.22 11:27 Сейчас в теме
(14)Под тестовым контуром имелась в виду методология
Т.е. возможно они просто ванессу протестировали, а не реальную работу пользователей
18. starik-2005 3033 03.03.22 11:29 Сейчас в теме
(16) я вот еще раз посмотрел статью на предмет того, что они ванессу тестировали, и не нашел там ее. Она вообще умеет нагрузочное тестирование делать?
19. capitan 2466 03.03.22 11:30 Сейчас в теме
(18)Чуть выше по комментариям
Тестирование проводилось силами заказчика, для этих целей они использовали Vanessa Automation со сценариями создания документов.

скорее всего как раз сценарий ванессы и деградировал со временем
22. starik-2005 3033 03.03.22 11:35 Сейчас в теме
(19) но это не объясняет, почему при замене платформы все поправилось (ибо если в ванесссе проблемы, то они никуда бы не ушли, не?). Такое тестирование вообще можно было бы провести с помощью группового изменения документов - там есть прогресбар и невооруженным взглядом будет видна деградация, если она есть.
it-expertise; +1 Ответить
24. capitan 2466 03.03.22 11:37 Сейчас в теме
(22)Как раз объясняет.
Возможно в ванессе один МВТ на весь сценарий
26. starik-2005 3033 03.03.22 11:39 Сейчас в теме
(24) и как это объясняет? Типа ванесса сама еле-еле проводит документы, т.к. каждый следующий запрос в ней все дольше и дольше выполняется?
28. capitan 2466 03.03.22 11:41 Сейчас в теме
(26)в платформе поправили вот это:
Столкнулись с проблемой постепенного замедления выполнения запроса (пакета) при работе алгоритма.

Алгоритм использует много ВТ (порядка 100) в ходе работы часть ВТ уничтожается и снова создаются (в них дописывается результат работы итерации), проблема в том что каждая следующая итерация немного дольше предыдущей, первая итерация выполняется порядка 5 мс, а последняя (12) уже порядка 80 секунд.


Это как раз и напоминает выполнение сценария тестирования ?
31. starik-2005 3033 03.03.22 11:49 Сейчас в теме
(28)
Это как раз и напоминает выполнение сценария тестирования ?
А что там со сценарием? Создается документ, заполняется каким-то мусором, записывается, проводится. Тут ванесса и прочие ЦАТ заканчиваются. С трудом видятся здесь проблемы. Если бы нагрузочное тестирование просто повышало со временем генерацию документов за счет запуска "новых пользователей", то картина и так была бы ясна: до количества бзеров Х все в пределах нормы, после - опа. Но тут-то, как я понял, изменения нагрузки не было, а деградация производительности была.

Дальше анализируется APDEX, сортируется от худшего результата, анализируется худший результат на примере того самого разбора в статье. Вполне нормальный подход.
12. Gilev.Vyacheslav 1910 03.03.22 11:19 Сейчас в теме
имхо это так себе анализ, если вы ничего толком не нашли, и тем более не разобрались в причинах, кроме того что новая платформа работает лучше, я бы постеснялся назвать это экспертизой
buganov; Jimbo; YA_1456794870; ivanov660; sasha_r; it-expertise; +6 2 Ответить
21. capitan 2466 03.03.22 11:35 Сейчас в теме
(12)Имхо раз сценарий тестирования предложил заказчик, то задача решена.
29. starik-2005 3033 03.03.22 11:43 Сейчас в теме
(21)
задача решена
Решена в принципе, а не в сути )))

ЗЫ: И если суть - проблема в платформе, то как ее разработчики 1С могут выявить "толком"? Какие конкретно техжурнал может дать данные для этого? Мне кажется, что это просто очередное популистское заявление, не несущее в себе технического смысла.
sasha_r; Gilev.Vyacheslav; +2 Ответить
30. capitan 2466 03.03.22 11:49 Сейчас в теме
(29)Вы багфиксы по ссылкам прочитали?
33. starik-2005 3033 03.03.22 11:51 Сейчас в теме
(30) у меня нет туда доступа. Во франче его не давали никому, тестовый 7дневный период давно закончился, а теперь я даже не во франче.
49. check2 354 13.04.23 23:44 Сейчас в теме
(33) ОФФ. Купить за 4 рубля комплект специалиста, в который входит предоставление и к этому сервису в частности, нет желания?
https://1c.ru/news/info.jsp?id=29258
Я покупал ещё в 2010 чрез УЦ в Саратове, до сих пор есть доступ в багбоард, в релизы: ограниченно платформа и приблуды к ней типа EDT, явы, исполнителя, ИТС оч. ограниченно, прямо порезано. и есть доступ в партнёрские конференции. Если уйду в свободное плавание из франча у самым востребованным разделам доступ есть. Всё остальное за счёт клиентов можно получить...
50. starik-2005 3033 15.04.23 18:17 Сейчас в теме
(49)
нет желания?
Вот вообще 0.
32. capitan 2466 03.03.22 11:50 Сейчас в теме
(29)
Решена в принципе, а не в сути )))

Вспоминается...
Возвращаются два чукчи с охоты, волокут за хвост моржа, тот упирается клыками в снег, тащить мешает.
Попался им навстречу геолог:
– Вы лучше за клыки тащите – легче будет!
Так чукчи и сделали. Идут дальше, впечатлениями делятся:
– Слышь, – говорит один, – гораздо легче стало. Однако умный тот геолог.
– Нет, – говорит другой, – однако дурак геолог. Смотри, опять к морю пришли!

Заказчик выбрал метод тестирования, ему все починили)
34. starik-2005 3033 03.03.22 11:54 Сейчас в теме
(32)
однако дурак геолог. Смотри, опять к морю пришли!
Но сути вопроса не меняет: как 1С-неги могут понять, что проблема в платформе, не поменяв ее? Народ как-то писал, что на сборку РЛС-а и контроля прав для запроса у юзеров с тысячей ролей уходило 3 секунды. А запросов к базе десятками, получаем 30 сек на проведение документа.
Gilev.Vyacheslav; +1 Ответить
35. it-expertise 324 03.03.22 12:20 Сейчас в теме
(12) По нашему опыту, часть реальных расследований заканчивается диагностированием ошибки платформы. Конечно, сначала мы всегда ищем причины в прикладном коде, настройках контуров, аппаратных ресурсах, механизмах тестирования (если речь идет о тесте, как в данном случае).

Когда уверенность в платформенном влиянии возрастает, мы ищем известную ошибку платформы, если находим, возникает выбор - либо обход найденной ошибки, либо ожидание версии с исправлением.

В этом кейсе мы показали один из таких примеров. У нас есть и другие, и они на подходе.
37. Gilev.Vyacheslav 1910 03.03.22 17:02 Сейчас в теме
(35) я не пойму что вы хотите сказать, с одной стороны вы рассказываете про методику расследования и в итоге причин не выявили, кроме того что пусть другие в фирме 1С исправляют, с другой вы говорите что вы большие молодцы и можете понастоящему расследовать, так почему бы сразу нельзя было написать про настоящее расследование
ведь ваш финал текущий истории мог быть и другим - тупо могло не оказаться версии платформы где эта ошибка исправлена и тогда финал был бы вовсе не таким как вы тут показываете "розовое"
YA_1456794870; ivanov660; Serg O.; +3 Ответить
39. Serg O. 224 04.03.22 09:51 Сейчас в теме
(35)(37) присоединяюсь к предыдущему комментатору...
такой заголовок... такое начало... такие картинки .... и ...

вывод 1 - обновляйте платформу - это Ваш совет и "результат" ?!
а в чём "причина" была ?
как то на "РАССЛЕДОВАНИЕ" не очень тянет.

какие запросы ? какие таблицы, их объём ? Блокировки /Взаимоблокировки,
на сервере 1С или в Базе Данных (кстати про Базу нет ни слова...
SQL Server или Postgre ? какой версии... какие настройки, а это крайне важно)
Вам "повезло", что обновление платформы как-то помогло,
но такого "чуда" могло и не случиться...

более того, если у вас по 15-20 сек проводится 1 док. ... это УЖЕ очень не хорошо
а до 150-200 сек вообще что-то не то ...

Был доклад на Инфостарт 2017 или 2018гг кажется...
как в 100 раз ускорили работу с документами Поступления...
все ждали "чуда" ... а решение банальное - отложенное проведение,

т.е. "просто" проведения на клиенте (у пользователей) убрали... просто запись,
а проведение спрятали "под ковёр"...
оно так же или ещё более долгое, но его "не видно"
т.е. оно делается потом регл.заданием каждые 10-30 мин "параллельно" с работой пользователей...

вот ощущение от вашей статью такое же... сплошное разочарование
it-expertise; +1 Ответить
40. it-expertise 324 04.03.22 10:56 Сейчас в теме
(39) нам "повезло" с тем, что проблема решилась исправлением в платформе - это так. Если бы так не "повезло", мы продолжили бы расследование и нашли бы путь обхода (выше уже писали об этом) - тогда вы бы увидели другую статью.

Цель этой статьи - показать не совсем типовой кейс и способ выявления проблемы, который мы используем в своей практике. Иными словами: поделиться опытом. Надеемся, информация пригодится.
AlekseyBelyy; sasha_r; IT_Magnit; +3 Ответить
43. Gilev.Vyacheslav 1910 04.03.22 14:01 Сейчас в теме
(40) это словоблудие ребята - то что проблема решилась исправлением в платформе - это НЕ ВАШ УСПЕХ, вы тупо хорошо по ушам проехались, мол смотрите как МЫ хорошо решаем проблемы, а по факту это фирма 1С решила проблему, а вы это исправление "прихватизировали"

для того чтобы проверить устранение проблемы в новом релизе платформы ваш "экспертный анализ" не нужен, тупо поставили и проверили
YA_1456794870; ivanov660; Serg O.; +3 Ответить
44. triviumfan 92 05.03.22 14:08 Сейчас в теме
Эта ошибка постоянно то появляется, то исчезает от платформы к платформе. Да и анализ получился так себе.
OAC_soft; YA_1456794870; +2 Ответить
45. oleqlm 05.03.22 22:20 Сейчас в теме
(43) Коллеги, извините что офтоп. На первый раз сталкиваюсь с его бывшими клиентами, выслушиваю массу негатива в его адрес. Гилев - относитесь с уважением к коллегам и заказчикам, потому как ваш пост фактически не прикрытое хамство. Сообщество 1С не гопники, что бы такое публично озвучивать. "Кто, имея знания, делает вид, что не знает, тот выше всех. Кто, не имея знаний, делает вид, что знает, тот болен" (Лао-Цзы).
Jimbo; AlekseyBelyy; sasha_r; +3 Ответить
46. YA_1449767843 07.03.22 16:38 Сейчас в теме
(45) Подскажите пожалуйста, Вы из какой организации?
47. Serg O. 224 09.03.22 11:17 Сейчас в теме
про "расследования" хорошие статьи и инструменты давно есть.
Например, здесь же на Инфостарт, автор Владимир Крючков
в спец. конфигурации - Мониторинг производительности
https://infostart.ru/1c/articles/1611069/
и даже подобие "ИИ" Лариса для анализа состояния систем
- про которую он пишет на Инфостарте https://infostart.ru/1c/articles/1082702/

ну и конечно же "известные" (видимо не всем) с 2013-2014 гг инструменты с сайта Gilev.ru
анализ длительных запросов / блокировок / взаимоблокировок / анализ ЖР и т.д.
ivanov660; Gilev.Vyacheslav; +2 Ответить
Оставьте свое сообщение