Другой взгляд на APDEX и подсистему "Оценка производительности"

Публикация № 1006853

Администрирование - Производительность и оптимизация (HighLoad)

оценка производительность APDEX мониторинг

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

Для начала

Практически каждое широкораспространенное решение от фирмы "1С" и ее партнеров содержит в себе подсистему "Оценка производительности", которая позволяет выполнять замеры времени длительности операций. На основе собранной статистики можно предоставить относительную оценку производительности отдельной операции или всей системы в целом.

Казалось бы, что тут дальше рассказывать? Уже было множество публикаций на эту тему, зачем еще одна? Сегодня мы постараемся коснуться основ методики APDEX, а также рассмотрим ее реализацию в БСП. Но самая интересная часть будет в рассмотрении ее слабых сторон и возможных решений. Мы коснемся таких вопросов как:

  • Почему APDEX никогда не даст реальной картины происходящего в системе.
  • Причины, по которым подобная оценка производительности во многих случаях бесполезна для бизнеса.
  • Есть ли более эффективные пути отслеживания состояния производительности информационных систем.
  • Что делать, если сильно хочется использовать типовую подсистему "Оценка производительности".
  • Почему замеры времени на стороне 1С лишь вершина айсберга и им нельзя доверять.

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

В статью добавлена щепотка юмора и самоиронии. Никого высмеивать целью не ставилось.

Еще раз повторяю - я не враг APDEX и подсистемы "Оценка производительности". Я их хороший друг!

Что такое APDEX

По этой теме очень много материала, ведь APDEX - это международный стандарт оценки производительности корпоративных информационных систем. Фирма "1С" рекомендует эту методику. Вопросы по ней есть в экзамене "Эксперт по технологическим вопросам", а подсистема "Оценка производительности" из Библиотеки Стандартных Подсистем (БСП) встроена в большое количество типовых конфигураций.

Основное преимущество данной методики - это простой результат, который очень легко интерпретировать. Её использование начинается со следующих простых шагов:

  1. Поскольку APDEX ориентирован на потребности бизнеса, то совместно с ним определяются:
    • Список критичных бизнес-операций в системе, которые необходимо отслеживать.
    • Приоритет каждой операции
    • Целевое время отклика по каждой из них
  2. Старт замеров времени выполнения каждой операции для более полной статистики
  3. Анализ и интерпретация полученных результатов

Рассмотрим небольшой пример. Допустим бизнес определил, что операция "Закрытие месяца (перепроведение документов)" является приоритетной, а целевое время установили в 600 секунд. За некоторое время была собрана следующая статистика. Пример упрощенный и с таким количеством статистических замеров трудно говорить о точности расчетов, но для примера самое то.

Пользователь Номер сеанса 1С Дата записи Количество операций Среднее время выполнения (сек.)
Главный бухгалтер 19 15.01.2019 4:29:11 1 167,42
Главный бухгалтер 30 15.01.2019 6:47:36 1 3 199,88
Главный бухгалтер 46 15.01.2019 7:44:56 1 3 362,15
Заместитель гл. бухгалтера 58 15.01.2019 8:40:59 1 599,16
Заместитель гл. бухгалтера 61 15.01.2019 10:09:57 1 1 600,18
Главный бухгалтер 100 15.01.2019 12:34:49 1 160,86
Главный бухгалтер 36 16.01.2019 5:06:22 1 173,14
Главный бухгалтер 32 23.01.2019 9:51:05 1 1 981,29
Заместитель гл. бухгалтера 33 05.02.2019 9:21:07 1 965,88
Главный бухгалтер 25 08.02.2019 8:47:22 1 2 270,26
Разработчик 1С 27 08.02.2019 10:15:15 1 2 061,72
Итого 11 1 503,81

Для расчета индекса производительности используется следующая формула:

APDEX = (NS + NT/2)/N, где 

  • T - целевое время ключевой операции (600 секунд для этого примера)
  • N – общее количество выполнений операции (по нашим данным их 11)
  • NS – количество выполнений с временем отклика от 0 до Т (это данные сеансов 1С: 19, 58, 100, 26. Итого 4 замера)
  • NT – количество выполнений с временем отклика от T до 4T (время выполнения от 600 до 2400, это сеансы 1С: 61, 32, 33, 25, 27. Итого 5 замеров)

В нашем случае расчет будет таким:

APDEX  = (4 + 5/2)/11 = 0,59

Но что это значит? По методике APDEX полученный индекс производительности можно интерпретировать как качественную оценку по следующей шкале.

От До Оценка
0.00 0.50 неприемлемо
0.50 0.70 очень плохо
0.70 0.85 плохо
0.85 0.94 хорошо
0.94 1.00 отлично

Что это было?Полученный индекс 0.59 говорит об очень плохом уровне производительности для операции "Закрытие месяца (перепроведение документов)". Пора предложить клиенту услуги по оптимизации! Почему именно эта операция является столь критичной? Бизнес так решил, ему виднее!

Пример очень простой, даже примитивный. Но он должен показать основу расчета индекса производительности APDEX. Более подробную информацию можно прочитать на ИТС, сайте Вячеслава Гилева или в Wiki.

Что ж, пока все выглядит отлично. Мы собрали статистику времени выполнения ключевых операций, рассчитали индекс производительности и продемонстрировали результаты заказчику. Клиент "кивает" и дает добро на работы по оптимизации производительности.

Возможно, даже в договоре в качестве результатов работ по оптимизации зафиксировано не целевое время, а индекс производительности APDEX!

Пройдемте дальше.

Решение из БСП

Теперь рассмотрим более приземленную тему - как это реализовано в конфигурации? Мы будем рассматривать подсистему "Оценка производительности" из БСП версии 3.0. Данная версия может значительно отличаться от своих предшественников, но т.к. она включается в новые релизы конфигураций свой выбор остановим именно на ней. Тем более принцип ее работы не менялся уже многие годы.

Первое, что мы сделаем - установим в конфигураторе отбор по подсистеме "СтандартныеПодсистемы.ОценкаПроизводительности". Перед нами предстанет примерно такая картина.

Подсистема "Оценка производительности"Уоу! Так много объектов, но не теряйтесь! В первую очередь посмотрите на перечисление "УровниПроизводительности", значения которого совпадают с общей логикой распределения значений индекса производительности APDEX (см. таблицу выше). В справочнике "Ключевые операции" хранится список операций и их настройки (Имя операции, приоритет в виде числа, целевое время ключевой операции в секундах и некоторые другие характеристики), то есть все то, что необходимо для расчета этого индекса.Как-то так

С недавних (или почти недавних) пор появилось разделение замеров времени на технологические и обычные (если так можно выразиться). Технологические - это те ключевые операции, которые явно не относятся к бизнесу. Например, к последним можно отнести замеры различных обработчиков обновления при "накатке" релизов и другие служебные операции. Обычные ключевые операции - это как-раз то, что нам нужно, так как относится к работе бизнеса. Это то, что нам следует замерять и анализировать.

В регистре сведений "Замеры времени" хранится вся статистики времени выполнения в разрезе ключевых операций, даты начала сеанса и начала часа. В ресурсах регистра находятся результаты замера:

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

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

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

	// Фиксируем время начала операции
	ВесЗамера = 1;
	ИмяОперации = "ПримерЗамераНаСервере";
	ВремяНачалаОперации = ОценкаПроизводительности.НачатьЗамерВремени();
	
	// Делаем что-то невообразимо тяжелое
	ОченьТяжелаяОперацияНаСервере();
	
	// Фиксируем результат замера
	ОценкаПроизводительности.ЗакончитьЗамерВремени(
		ИмяОперации, 
		ВремяНачалаОперации, 
		ВесЗамера,
		"Просто сделаем замер");

После этого в регистре "Замеры времени" сразу же появится запись о времени выполнения операции.

Замер времени

В справочнике "Ключевые операции" автоматически добавится новый элемент справочника.

Автоматически созданная ключевая операция

При этом вручную ее создавать не пришлось, система сделала все за нас. Останется только скорректировать приоритет, целевое время и допустимый уровень производительности, чтобы в дальнейшем посчитать APDEX. На сбор самой статистики эти параметры никак не влияют.

Что касается замеров на клиенте, то главной особенностью является механизм фиксации результата. Все результаты замеров сохраняются на стороне сервера, ведь клиент не может записать данные в регистр сведений. Тут и возникает главная сложность: если каждый раз для записи замера обращаться к серверу, то это создаст повышенную нагрузку на сеть, появятся "подтормаживания" клиентского приложения в момент передачи данных. Поэтому в БСП сохранение результатов замера на клиенте выполняется асинхронно (ну почти асинхронно). В течении некоторого времени приложение накапливает на клиенте результаты замеров, а после запускает отправку сразу всей собранной статистики одним вызовом. Вот пример замера на клиенте.

	ВесЗамера = 1;
	ИмяОперации = "ПримерЗамераНаКлиенте";
	// Включаем отложенную запись результатов замера
	// Если передать "Ложь", то результаты замеров нужно
	// будет фиксировать самостоятельно
	АвтоЗавершение = Истина;
	ВремяНачалаОперации = ОценкаПроизводительностиКлиент.НачатьЗамерВремени(АвтоЗавершение, ИмяОперации);
	
	// Нагружаем клиентскую машину, экономим ресурсы сервера :)
	ОченьТяжелаяОперацияНаКлиенте();
	
	// Можно завершить замер тут, но оставим эту работу БСП
	//ОценкаПроизводительности.ЗакончитьЗамерВремени(
	//	ИмяОперации, 
	//	ВремяНачалаОперации, 
	//	ВесЗамера, 
	//	"Пример замера на клиенте");

Проходит некоторое время и результат попадает в регистр "Замеры времени". Интервал обработки порций замеров указывается в константе "ОценкаПроизводительностиПериодЗаписи" в секундах. Асинхронная обработка выполняется через глобальный обработчик ожидания, инициализированный в модуле управляемого приложения еще на стадии запуска.

 
 Что это за тяжелая операция из примеров

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

Типовые операции замера производительности

Посмотрите внимательно и ответьте честно: Вы можете уверено сказать, все ли в порядке с производительностью в этой информационной базе? :)

 
 Что это за отчет на скриншоте

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

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

Большие и не очень недостатки

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

Организационные проблемы

МаркетингКак было сказано ранее, APDEX ориентируется именно на бизнес. Это означает, что ключевые операции, для которых необходимо проводить замеры производительности, определяются бизнесом, целевое время для них устанавливается бизнесом, приоритет каждой операции также устанавливается бизнесом. (бизнес, бизнес, бизнес....).

На практике же все происходит иначе. Когда встает вопрос составления перечня ключевых операций обычно менеджеры ИТ-проектов или технические специалисты предлагают уже готовый перечень этих самых операций. Со стороны клиента лишь остается определить приоритеты и целевое время, но и тут не все так радужно. Частый ответ на вопрос "Какое целевое время установим для этой ключевой операции?" это "Как можно скорее!". И тут снова начинается игра в "подгони целевое время под текущее" с тем смыслом, чтобы можно было оптимизировать операцию без больших трудозатрат и при этом еще и заказчик будет доволен.

Приоритеты устанавливаются еще интереснее. Если список ключевых операций длинный, то обычно внимание акцентируется на первых 5-10 операциях, а дальше уже как получится. Во многих случаях приоритет ключевой операции - это что нужно оптимизировать в первую очередь, что "болит" и нужно исправить еще вчера. В такой обстановке настоящий приоритет устанавливается на первых нескольких операциях, а все остальное по остаточному принципу.

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

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

В этом свете APDEX - это лишь маркетинг, чтобы лучше продавать услуги по оптимизации или рекламировать высокопроизводительные информационные системы с лозунгом "Средний APDEX выше 0.75 на всех проектах!". По мне лучше убрать всю эту "мишуру" и вернуться к замерам в старых добрых секундах с мониторингом динамики изменения показателей.

Слишком много допущений

Что значит индекс производительности APDEX равный 0.75 или 0.44? Значит он только одно - субъективное мнение пользователей системы о качестве ее работы. Конечно, пользователям не важно что именно в системе сломалось, важен конечный результат. Но мониторинг важен для ИТ-службы!

Почему индекс стал 0.44? Тормозит сеть? В новом релизе сделали неоптимальный запрос и положили базу? Или может так и должно работать и это просто тяжелая операция? А может пользователь просто случайно указал период в отчете 10 лет вместо недели и ожидал быстрого формирования?

APDEX не дает ответом что именно в информационной системе происходит, какие операции работают медленно, а какие быстро. Он просто отражает субъективное мнение бизнеса и не более того. Да, он может быть пунктом в договоре об оказании услуг или каким-то образом отражен в SLA, но решить какие-то конкретные проблемы он не сможет.

APDEX не учитывает динамику

Требования бизнеса меняются и это нормально. Но сформированный список ключевых операций и их параметры зачастую не поспевают за этими изменениями, ведь не сразу понятно как должен измениться приоритет и целевое время. Бизнес еще не знает, ведь он на стадии изменений. Можно поставить через "экспертное" мнение, но к чему это приведет? Скорее всего к тому, что спустя время все ключевые операции все равно нужно будет пересматривать.

Таким образом, APDEX не может выступать в качестве метода мониторинга меняющейся системы, т.к. не будет поспевать за этими изменениями. А если нет актуальных данных, то зачем его использовать?

Большие погрешности в измерениях

Формулу расчета мы уже видели. Напомню, что индекс производительности APDEX рассчитывается как соотношение количества операций с приемлемой скоростью к общему количеству операций. Приемлемыми операциями выступают все те что выполнились с целевой скоростью, а также плюс половина операций, которая выполнилась меньше чем за время, в 4 раза превышающее целевое. Так отбрасываются аномальные замеры операций, длительность которых значительно отличаются. А это уже может сильно исказить результат.

Например, Вы розничная компания с десятками филиалов по всей стране. В каждом регионе у вас несколько филиалов и для контроля работы системы Вы анализирует показатели APDEX по регионам. В одном регионе 5 филиалов, на одном из которых, допустим, проблемы с сетью. Рассчитывая индекс производительности может оказаться так, что как-раз эти аномалии в одном из филиалов будут отброшены и Вы получите хороший показатель. Чего этот филиал так жалуются, работать не хотят? :)

Также для редких операций, например, закрытие месяца, считать APDEX вообщем-то бессмысленно, т.к. данных будет очень мало. Разве что считать за 10 лет, но есть ли в этом смысл?

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

  1. При возникновении ошибки во время замера на сервере его результат не будет зафиксирован.
  2. При замерах на клиенте, если включено автоматическое завершение замера, могут быть интересные ситуации:
    • После начала замера появилось модальное окно и пока оно не будет закрыто, замер не будет завершен.
    • Замер стартует перед проведением документа на клиенте. Если во время проведения возникла ошибка, то замер будет остановлен после закрытия ошибки пользователем. А это может быть +5000 к длительности операции!
    • Замер не включает в себя никакой дополнительной информации о замере, то есть не будет понятно где операция больше всего выполнялась. А это могло бы помочь определить узкое место - слабый компьютер у сотрудника, сеть "тормозит" или на сервере баз данных что-то пошло не так.

Вот пример кода, когда замер производительности покажет неадекватное время выполнения операции.

	ВесЗамера = 1;
	ИмяОперации = "ПримерЗамераНаКлиенте";
	
	АвтоЗавершение = Истина;
	ВремяНачалаОперации = ОценкаПроизводительностиКлиент.НачатьЗамерВремени(АвтоЗавершение, ИмяОперации);
	
	// Нагружаем клиентскую машину, экономим ресурсы сервера :)
	ОченьТяжелаяОперацияНаКлиенте();
	
	// Пока пользователь не закроет окно об ошибке
	// система будет считать, что замер времени выполнения продолжается.
	ВызватьИсключение "И пусть весь Мир подождет!";

"Но ошибка это исключительная ситуация" - обычно так отвечают на это. Да, это так, но ошибки случаются у всех и предсказать много их будет или мало нельзя. Так можно ли доверять статистике замеров?

Потерянные замеры

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

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

Влияние на производительность и обслуживаниеВот это поворот!

Да, Вы не ослышались! Контроль производительности с помощью замеров влияет на производительность!

Чем больше ключевых операций и чем чаще они выполняются, тем "тяжелее" будет таблица регистра сведений со статистикой замеров. На практике был случай, когда количество записей в регистре сведений "Замеры времени" оказалось больше, чем в каждой отдельной таблице этой базы. Соответственно, для хранения истории замеров понадобится свободно место на дисках и иногда не маленькое.

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

Ну и стоит упомянуть, что если фиксация результата замера выполняется сразу же, то операция записи в регистр сведений все же может увеличить время выполнения операции. Конечно, это может показаться несущественным  - 0.05 секунды на запись результатов замера. Но если операций 1000, десятки или сотни тысяч. Тут уже может оказаться, что подсистема "Оценка производительности" Вам не подходит.

Сложность интеграции

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

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

То есть нельзя просто так взять и добавить ключевую операцию для замера, нужно потратить время (или деньги заказчика).

Неужели все так плохо

Все ок!Конечно, нет! Если Вы дочитали до этой строчки, то, возможно, Вы считаете меня противником APDEX и подсистемы "Оценка производительности", но это не так. На самом деле использую ее до сих пор, замеряю время выполнения операций и выполняю мониторинг системы. Зачем же тогда все это?

Все просто, я лишь хотел донести эти мысли:

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

На этом все, спасибо что дочитали! Отличного Вам дня и стабильного рабочего окружения!

Другие ссылки

Тема замеров времени по методике APDEX достаточно часто обсуждалась как на Инфостарт, так и за его пределами. Вот некоторые материалы по данной теме:

81

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Hekeus 20.02.19 09:43 Сейчас в теме
Отличная статья!
APDEX - попытка перевода субъективного мнения пользователя в какие-то цифры. Как и любая цифровизация страдает кучей допущений и упущений. На мой взгляд - красочный вид и помощь в сдаче работ - это как раз его основное предназначение.
gubanoff; YPermitin; +2 Ответить
2. YPermitin 4990 20.02.19 09:47 Сейчас в теме
(1) Спасибо!

Иногда Apdex хорош, но если нужен серьезный контроль производительности, то смысла в нем может быть немного.
3. genayo 20.02.19 09:50 Сейчас в теме
Целевые показатели APDEX могут быть зафиксированы в договоре на внедрение, и работы не будут приняты, пока они не будут достигнуты, например.
YPermitin; +1 Ответить
4. YPermitin 4990 20.02.19 10:01 Сейчас в теме
(3) да, поэму эту методику в публикации я больше и называл как маркетинговый ход.

Вряд ли в договоре можно технические показатели зафиксировать, а APDEX без проблем :)
5. genayo 20.02.19 10:33 Сейчас в теме
(4) Я бы не назвал это чисто маркетинговым ходом. Всё-таки APDEX неплохо коррелирует с эксплуатационными характеристиками системы, и отклонение в APDEX вполне себе объективный показатель проблем.
Vladimir Litvinenko; AnderWonder; YPermitin; +3 Ответить
6. YPermitin 4990 20.02.19 10:38 Сейчас в теме
(5) Я вас понимаю.

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

С другой стороны есть объективные показатели работы системы: нагрузка на сеть, CPU, диски, время выполнения операций в секундах и др.

Почему бы не опираться на них при аудите системы.
Дмитрий74Чел; +1 Ответить
11. genayo 20.02.19 11:02 Сейчас в теме
(6) Так для бизнеса как раз и важна "субъективная оценка пользователей". А вот уже непосредственно техническая эксплуатация должна проактивно собирать объективные метрики и реагировать, чтобы APDEX оставался в установленных рамках.
12. YPermitin 4990 20.02.19 12:18 Сейчас в теме
(11)
но собирать объективные метрики и реагировать, чтобы APDEX оставался в установленных рамках.


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

Альтернативные варианты это сбор метрик инфраструктуры, есть также платные решения для замера времени операций в конфигурациях, которые лишены многих перечисленных в статье недостатков, но называть их не буду. А то будет реклама.
26. Sergey.Noskov 1077 24.06.19 15:10 Сейчас в теме
(6)
нагрузка на сеть, CPU, диски, время выполнения операций в секундах и др.

можно, но вы столкнетесь с тем, что эти параметры не статичны и иногда изменяются в довольно широких диапазонах и тут встанет вопрос, какие значения брать, средние? Тогда любой пик сразу вызовет нарушение SLA, если взять пиковые значения, тогда есть риск просто пропустить аварию.
Или, оговорили, что нагрузка на проц не должна быть выше 90%, но прикол в том, что и 91% на скорости работы может никак не отразиться, т.е. мы имеем нарушение договоренностей без влияния.
Ок, берем время выполнения, описываем какое оно должно быть. А если одна операция из ста будет выше нормы? а если из тысячи, тоже превышение?
7. sergathome 20.02.19 10:43 Сейчас в теме
Спасибо автору за ликбез. Подсистемой никогда не пользовался, хотя постоянно на неё натыкаюсь в типовых и тп. Примерно так всё и представлял. Сплошной маркетинг. В бух3, кстати, регулярно сыпятся ошибки из-за этой подсистемы ;))
wowik; YPermitin; +2 Ответить
9. YPermitin 4990 20.02.19 10:53 Сейчас в теме
(7) зато отчеты красивые :)
sergathome; +1 Ответить
8. Gilev.Vyacheslav 1836 20.02.19 10:48 Сейчас в теме
достаточно отказаться от оценки собранных времен через различные дополнительные формулы, а вручную оценивать собственно собранные времена, и делов то
неужели для этого надо статьи писать
Silenser; blackhole321; Vovan58; +3 Ответить
10. YPermitin 4990 20.02.19 10:56 Сейчас в теме
(8) все, конечно, так, но и замеры могут быть неадекватными из-за ошибок и особенностей алгоритмов сбора в подсистеме.

Статья для полноты и целостности. А так можно было просто написать: "Не используйте APDEX и замеры времени БСП. Лучше использовать альтернативные решения для мониторинга.".
for_sale; +1 Ответить
16. Gilev.Vyacheslav 1836 20.02.19 17:45 Сейчас в теме
(10) странный вывод, наоборот, доработайте стандартную подсистему - выкорчуйте оттуда индексы, оставьте время
по поводу ошибок замеров - ну во первых есть два подхода:
1. по подписке
2. в явном виде вручную время До и время ПОСЛЕ
первый способ применяется на первом этапе "ознакомления", второй соответственно последовательно на втором этапе, когда общая картина ясна и нужно работать точечно

кроме того, классический апдекс собирает только сервер, красиво доработать код и собирать время на клиенте - это конечно больше усилий, но тогда можно поймать "белый экран", который на стороне сервера 1С часто не ловится вообще
Vovan58; YPermitin; +2 Ответить
18. YPermitin 4990 20.02.19 19:24 Сейчас в теме
(16) Думаю, что все кто плотно работает с подсистемой "Оценка производительности" допиливают ее под себя. Ниже в комментариях я давал пример.

>> Лучше использовать альтернативные решения для мониторинга
Тут я имел ввиду, что на рынке есть альтернатива подсистеме "Оценка производительности" от известной компании, название которой не скажу, а то сочтут за рекламу. Их решение не нагружает основную систему для записи статистических данных, а передает их в другое место.

Плюс как не допиливай БСПшное решение, некоторые проблемы все равно не решить:
1. Например, замер заканчивается "После записи" документа и вроде бы все хорошо, но клиентское приложение продолжает "думать". Такое может произойти, когда форма после записи отправляет оповещения другим формам, а те начинают делать свои дела.
2. Потерянные замеры также не решаются, то о чем писал в публикации.
3. Не все операции можно замерять с помощью ОП, например пролистывание динамического списка и другие встроенные в платформу действия.

В идеале, если бы замеры были встроены в саму платформу, тогда и контроль за ними был бы куда больше. Хотя замеры в платформе есть, но в виде технологического журнала. Но для APDEX его данные трудно использовать.
13. capitan 1271 20.02.19 16:01 Сейчас в теме
1. APDEX хорош как метод грубой оценки, потому что если APDEX покажет отлично/хорошо, то навряд ли пользователи вообще захотят тестов, и навряд ли тестами вы выйдете на обратные результаты. И наоборот - APDEX 0.5 то навряд ли дело в замерах производительности.
2. С точки зрения общения с непрофессионалами вообще незаменим, он оттуда и вырос. К фин директору вы не придете с простыней где время выполнения запроса в микросекундах. А тут все понятно - плохо. хорошо. отлично

Ключевые операции конечно надо очень хорошо подбирать чтобы все заработало как надо, а не просто с настройками по умолчанию включать.
В принципе любую вещь не помешает настроить перед включением в продакт.
Запустите ТЖ с настройками по умолчанию и через час не только ошибки будут сыпаться как тут говорят, а просто сервер устанет.
Sergey.Noskov; YPermitin; +2 Ответить
14. Dach 279 20.02.19 16:35 Сейчас в теме
Мы слегка доработали в своей конфигурации инициализацию замеров.

Есть вот такая функция

ИмяКлючевойОперацииЗамераПроизводительности


Используем так:

Перем ВремяНачалаЗамера;
ВремяНачалаЗамера = 0;

Процедура модуля объекта документа ПередЗаписью


//Замер производительности инициализация
	ИмяОперацииЗамераПроизводительности = ОбщегоНазначения.ИмяКлючевойОперацииЗамераПроизводительности(ЭтотОбъект, СтрЗаменить(Строка(РежимЗаписи), " ", ""));
	ВремяНачалаЗамера = 0;
	
	Если ЗначениеЗаполнено(ИмяОперацииЗамераПроизводительности) Тогда 
		ВремяНачалаЗамера = ОценкаПроизводительности.НачатьЗамерВремени();
	КонецЕсли;	
	//Замер производительности инициализация

Показать


Процедура ПриЗаписи


//Замер производительности фиксация
	Если СтрНайти(ИмяОперацииЗамераПроизводительности, ".Запись") > 0 И ВремяНачалаЗамера <> 0 Тогда
		ОценкаПроизводительности.ЗакончитьЗамерВремени(ИмяОперацииЗамераПроизводительности, ВремяНачалаЗамера, Товары.Количество(), "РТиУ " + Номер + " от " + Строка(Дата));
	КонецЕсли;	
	//Замер производительности фиксация

Показать


Процедура ОбработкаПроведения


//Замер производительности фиксация
	Если ВремяНачалаЗамера <> 0 Тогда
		ОценкаПроизводительности.ЗакончитьЗамерВремени(ИмяОперацииЗамераПроизводительности, ВремяНачалаЗамера, Товары.Количество(), "РТиУ " + Номер + " от " + Строка(Дата));
	КонецЕсли;	
	//Замер производительности фиксация

Показать


В справочнике "Ключевые операции" созданы элементы с наименованием:

Документ.РеализацияТоваровУслуг.Проведение
Документ.РеализацияТоваровУслуг.Запись

Аналогично для любых произвольных алгоритмов

ПроизвольныйАлгоритм.СформироватьПрайсЛист

Пометив на удаление или сняв пометку - можно управлять запуском замера (не запускать - запускать).
Кроме того, если договориться, что во все существующие механизмы таким образом встраивать инициализацию и фиксацию - получается очень удобно. Нужно сделать замер - создал ключевую операцию, не нужно - удалил.
Дмитрий74Чел; YPermitin; +2 Ответить
15. YPermitin 4990 20.02.19 17:23 Сейчас в теме
(14) делал подобное, но дополнительно была возможность замеров создания форм.
То есть замер начинался при создании на сервере, а заканчивался после открытия формы.
На скорость открытия формы практически не влияло.

А так + :)
17. Shmell 257 20.02.19 18:51 Сейчас в теме
Статья как минимум будет полезна тем кто решает - поможет ли им ОП или стоит рассмотреть альтернативные подходы.
Что касается технических деталей - то действительно - ОП в БСП можно докрутить, тут фантазия ограничивается лишь ресурсами для реализации задуманного. Как вариант можно прикрутить платформенные механизмы записи действий пользователей, в некоторых случаях это осуществимо достаточно просто. С каждой ситуацией нужно разбираться индивидуально и искать индивидуальные подходы. По мне так интересен подход использования интегральной оценки совместно с пооперационным apdex.
YPermitin; +1 Ответить
19. DitriX 1713 21.02.19 00:04 Сейчас в теме
Тоже никогда не любил апдекс.
Я или использую гугл аналитикс фиксируя изменения в базе, или использую гугл аналитикс по анализу лога действий пользователей.
Так как показывает практика, что я могу, например ускорить отчет, который пользователь открывает 100 раз день с 10 секунд, до 5 секунд, что приемлемо.
В этом случае апдекс мне скажет - что все кул, ты вырулил. НО НИФИГА!
Ибо некие одаренные личности, для проверки остатка товара открывают чек, пробивают товар, заходят в него, открывают из него отчеты - отчет по остаткам, выбирают размер в отборах и строят его.
Т.е. по факту - проверка товара на остатке занимает не 10 секунд, а 30-40, и на фоне этого - ускорив отчет на 5 секунд, профит будет не в 2 раза, а всего на 10%. А почему так делают люди, а потому что им предыдущие показали, что они так делали, и что тот отчет самый правильный, и не верьте отчету, который находится ПО БОЛЬШОЙ КНОПКЕ НА СТОЛЕ!
Хотя, принципиально - это один и тот же отчет. А не доверяли ему, так как когда то сохранили настройки в отборе левые, и все :)

Я просто к чему - все эти показатели, это что то из области фантастики, ибо мерять ими можно только те вещи, которые делаются теми людьми, которым разработчик может доверять, или полностью автоматизированные вещи, типо регламентов.
YPermitin; +1 Ответить
20. YPermitin 4990 21.02.19 05:29 Сейчас в теме
22. DonAlPatino 128 26.02.19 11:38 Сейчас в теме
(19)А можно какие-то ссылки на тему прикрутить гугл аналитикс к 1С? Как-то даже в голову не приходило что так можно...
24. Sergey.Noskov 1077 24.06.19 15:00 Сейчас в теме
(19)
Т.е. по факту - проверка товара на остатке занимает не 10 секунд, а 30-40, и на фоне этого - ускорив отчет на 5 секунд, профит будет не в 2 раза, а всего на 10%.
а гугл аналитикс как тут поможет? Это пример из крайностей.
25. DitriX 1713 24.06.19 15:08 Сейчас в теме
(24) в гугл аналитикс вы можете построить юзер строрис. Типо такого как на картинке, и вы можете отследить - как туда попал пользователь.
28. Sergey.Noskov 1077 24.06.19 15:26 Сейчас в теме
(25) отследить да, но это анализ, а для оценки качества?
29. DitriX 1713 24.06.19 15:34 Сейчас в теме
(28) а для оценки качества чего?
Вы какую цель ставите - оценить нечто и как то, или сделать чтобы люди работали быстрее и "правильнее".
Если вы хотите просто что то замерять - то точно там же, в переходах на экранах, или в сценариях - вы делаете замер производительности.

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

https://analytics.google.com/analytics/web/demoAccount
21. geron4 132 22.02.19 08:59 Сейчас в теме
Приведу пример когда APDEX не хватает для понятия ситуации:

целевое время проведения документа "Х" = 10 сек,
все замеры попали в интервал 10.2 - 10.5 сек - APDEX равен 0.5, что "неприемлемо",
но превышение целевого времени 200-500 мс на самом деле не является проблемой для пользователя,
если он согласен на 10 сек, то 10.5 сек не будут проблемой.
Поэтому мы еще смотрим среднее, минимальное и максимальное.
Прикрепленные файлы:
YPermitin; +1 Ответить
23. FreeArcher 87 20.06.19 13:54 Сейчас в теме
- Алло! ИТ отдел? У нас жутко тормозит 1С, очередь уже на кассе.
- Что у вас тормозит конкретно. Что вы делаете?
- Ну реализацию проводим.
- Вот я смотрю по APDEX показатель 0,8. Это все очень хорошо. Что вы мне лапшу на уши вешаете идите работайте.

p.s. к сожалению усредненные данные порой показывают прекрасные результаты, а по факту у пользователей при некоторых неблагоприятных пересечений нагрузок действительно тормозит 1С.
stepan_s; YPermitin; +2 Ответить
30. stepan_s 05.09.19 06:51 Сейчас в теме
(23)хотелось бы поддержать желание конкретики :) оцениваем укрупнено, а вот деталей не найти :( Заказ стоимостью мильон и 100 руб по любому будут разное время проводится. Но мы их усредним, и уже допустимый показатель....
Но если больной жалуется на боль, а мы ее не видим - это не компетенция больного, это наша ...
27. Sergey.Noskov 1077 24.06.19 15:23 Сейчас в теме
1. APDEX не панацея, но без никак.
2. APDEX требует внедрения и сопровождения, как любой другой типовой учет. Включая какой-то универсальный замер, не ждите от него актуальной оценки. Особое внимание ключевому времени.
3. Шкала APDEX так же может кастомизироваться. Иногда и 0.9 это уже "плохо".
Оставьте свое сообщение

См. также

Набор скриптов для знакомства с SQL Server 195

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

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

30.09.2019    8433    YPermitin    10       

Мониторинг высоконагруженной системы 36

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

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    3291    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 72

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    6757    Sloth    11       

Руководство по SQL: Как лучше писать запросы (Часть 2) 33

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

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    3256    w.r.    1       

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    2545    93    YPermitin    7       

Руководство по SQL: Как лучше писать запросы (Часть 1) 59

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

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    4504    w.r.    0       

Использование Union вместо OR 5

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

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    1408    w.r.    35       

Тюнинг производительности запросов в PostgreSQL 33

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

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    3058    w.r.    5       

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    4058    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 37

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

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    3424    fhqhelp    0       

Настройка параметров PostgreSQL для оптимизации производительности 33

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

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    3102    w.r.    13       

Сравнительное тестирование работы PostgreSQL с большими страницами Linux 6

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

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    1600    w.r.    6       

Настройка параметров ядра Linux для оптимизации PostgreSQL 33

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

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    2211    w.r.    1       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 56

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

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

02.07.2019    5872    igordynets    119       

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE 7

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

Данная статья является переводом оригинальной статьи Martin Kov&#225;&#269;ik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    3335    w.r.    2       

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 65

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    4035    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

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

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    4012    Дмитрий74Чел    6       

Непридуманные истории по оптимизации. История 1 75

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    6758    Repich    117       

Оптимизация: неэффективные запросы 6

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

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

13.06.2019    2561    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

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

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    6927    ivanov660    5       

Не думать о секундах свысока... 55

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4282    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    3676    zhichkin    15       

Как работают управляемые блокировки 120

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

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

29.04.2019    12915    comol    198       

Странное потребление места на диске С 33

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

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10522    kuzyara    12       

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) 36

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

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    6942    Aleksey.Bochkov    7       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 49

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

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8070    Elf1k    26       

Мониторим тяжелые запросы 28

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

Мониторинг тяжелых запросов с сохранением результатов для истории.

22.04.2019    3864    ImHunter    8       

Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью 105

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

Способы создания копии базы 1С для отчетов. Бэкапирование, репликация, AlwaysOn и другие страшные слова.

22.04.2019    7966    YPermitin    47       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 201

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

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    17631    ivanov660    40       

Самый быстрый шринк на Диком Западе 67

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

Шринк (shrink) базы данных. Наглядное объяснение что это, зачем, когда применять и как это можно ускорить.

17.04.2019    7009    YPermitin    44       

Как разбить базу на файлы и не сойти с ума 108

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

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    8497    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    9664    w.r.    23       

Быстрее чем INSERT! BULK-операции и примеры использования 112

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка Внешние источники данных Перенос данных из 1C8 в 1C8

Microsoft SQL Server поддерживает так называемые BULK-операции, используемые для быстрого изменения больших объемов данных в базе. В статье пойдет речь о практических примерах их использования. Все примеры сделаны в контексте платформы 1С (а как иначе).

09.03.2019    9572    YPermitin    38       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    5760    dmitrydemenew    38       

Секционирование таблиц и индексов в мире 1С 157

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

Говорим о секционировании таблиц и индексов для баз 1С. Способы применения, подводные камни и прочее.

10.02.2019    10870    YPermitin    53       

Производительность сервера 1С и фоновые задания 63

Статья Системный администратор Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    10593    user715208    38       

Инструкция: ускоряем tempdb переносом в RAM диск 90

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

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.

29.01.2019    12688    MrWonder    79       

Управляемые блокировки по полям из свойства "Поля блокировки данных" 5

Статья Программист Нет файла v8::blocking Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

Добрый день, коллеги! Хотелось бы поделиться обнаруженной особенностью работы механизма управляемых блокировок, а именно блокировке по полям, указанным в свойстве «Поля блокировки данных».

24.01.2019    3839    mshumakov    1       

Элементарный способ ускорить вашу 1С в два-три раза 71

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

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

14.12.2018    27033    Aleksey81    43       

Создаем свои индексы для баз 1С. Со своей структурой и настройками! 123

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

Поговорим о неплатформенных индексах для информационных баз 1С. Об особенностях их использования, целесообразности и подводных камнях.

05.11.2018    11888    YPermitin    30       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 168

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

Данная статья скорее является заметкой и отчетом об успешном использовании нового механизма реструктуризации баз данных 1С. Актуально для больших баз данных.

31.10.2018    18130    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

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

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    10677    gallam99    31