Форум казахстанского налогоплательщика

Часто приходится слышать, что одна программа тормозит, а другая работает быстрее. Одна программа удовлетворительно обрабатывает данные, а другая просто "летает". Но на деле, если мы хотим сказать, что одна программа быстрее или медленнее другой, нам мало знать, что в одном месте программа работает быстрее, а в другом медленнее.

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

Например, есть две программы (или одна программа до и после изменений): одна запускается, быстрее, зато в другой форма открывается быстрее, а вот разные отчеты за разное время составляются. Как выбрать систему?

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

Вот для этого несколько иностранных компаний объединились, чтобы принять единый стандарт замера производительности систем. Новую систему назвали Apdex (Application Performance Index) и ей измеряют насколько качественно быстро или медленно выполняются операции.

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

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

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

Для каждой операции мы можем выделить хорошее время выполнения. Положим, нам достаточно, чтобы программа запустилась за 5 секунд, форма ввода открывалась за 2 секунды, проведение товара за 4 секунды, ежемесячный отчет за 60 секунд и т.д.

Это время примем за Т. Если программа выполнит операцию за время Т, то это замечательно. Далее положим, что если программа выполнит за время не более 4*Т, то это удовлетворительно. Если более 4*Т, то программа работает неудовлетворительно медленно.

Далее мы берем не среднее время выполнения операции, а каждый замер проверяем в какой интервал он входит. Положим, мы провели 250 замеров, за сколько времени делается проведение товара в базе, притом, что хорошим временем является 4 секунды.

И так за время меньшее чем Т (до 4 секунд) выполняется 180 замеров. Хорошо.
За время от Т до 4*Т (от 4 до 16 секунд) выполняется 50 замеров. Удовлетворительно.
И больше чем 4*Т (более 10 секунд) выполняется 10 замеров. Плохо.

И чтобы понять насколько это хорошо или медленно посчитаем индекс Apdex, который измеряется как:

Apdex = (Замеров Хорошо + Замеров Удовлетворительно/2)/количество измерений

Т.е. в нашем случае:

Apdex = (180 + 50/2)/ 250 = 0.82

И также мы можем составить таблицу и по другим значениям:

• запуск программы 0.99
• открытие окна ввода данных 0.95
• подготовка ежедневного отчета оператора 0.86
• подготовка ежемесячного отчета для руководителя 0.56
• за какое время проходит реализация товара 0.81

Как уже становится понятно, чем выше число, тем лучше. В идеале, если Apdex = 1, то значит, программа эту операцию выполняет успешно быстро.

В стандартах Apdex принято выделять такие интервалы:

0.94 – 1.00 Замечательно (Отлично)
0.85 – 0.93 Хорошо
0.70 – 0.84 Удовлетворительно
0.50 – 0.96 Плохо
От 0 до 0.49 Неприемлимо.

Как мы видим в нашем примере оценку Отлично получает "запуск программы", "открытие окна ввода данных". Оценку Хорошо получает "подготовка ежедневного отчета оператора". Оценку Удовлетворительно получает " реализация товара" и "проведение товара". И наконец, Оценку Плохо получает "подготовка ежемесячного отчета для руководителя".

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

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

Еще раз вернемся к примеру. Часто когда пытаются оптимизировать что-то, смотрят на время выполнения и неверное расставляют приоритеты. Положим смотрят, что среднее время реализации товара составляет 6-9 секунд и считают это нормальным. Зато другая операция выполняется 10-15 секунд и ее пытаются оптимизировать и снизить до 5 секунд. Во-первых, надо смотреть, возможно эти 10 секунд это приемлемо, даже хорошо (Apdex = 0.97), а вот реализация товара имеет индекс 0.81, хотя и делается быстрее.

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

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

Положим, пусть будет такая важность (по-убыванию):

за какое время проходит реализация товара 0.81
открытие окна ввода данных 0.95
подготовка ежедневного отчета оператора 0.86
акт сверки 0.96
акт списания 0.76
расчет себестоимости 0.85
подготовка ежемесячного отчета для руководителя 0.56
запуск программы 0.99

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

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

("Считают товар отличным" + "Считают товар приемлемым"/2 )/количество опрошенных покупателей

Или срок, за какой Ваш отдел доставки поставляет на Ваше производство те или иные комплектующие.

("Имелось на складе" + "Доставлено в срок" + "Задержка была небольшой, чтобы вызвать проблем"/2)/"количество поставок"

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

Я видел много программистов, которые обслуживают, настраивают, устраняют проблемы в 1С, SAP, Dynamics, других бухгалтерских, ERP, CRM программ в Казахстане, но, ни разу не видел, чтобы кто-то подсчитывал индекс производительности. В лучшем случае скажут: до изменений отчет готовился 50 секунд, а теперь 30. Но этого мало, чтобы понять хорошо это или плохо.

Кайрат-F2 писал(а): но, ни разу не видел, чтобы кто-то подсчитывал индекс производительности.

Индекс не считают, но при отладке в конфигураторе 1С 8 есть режим замера производительности. Например, отчет выполняется слишком медленно, и с помощью этого режима можно определить самое узкое (медленное) место в этом отчете.

А может кто-нибудь из программистов написать тему, как таким образом определять узкие места? Понимаю что это слишком просто, но всё-таки.

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

Я как раз на тему отличия качественных показателей от количественных написал тему:
Оценка работы компании: не путаем качество и количество

Превосходный материал по вышеупомянутым вопросам содержится в следующих курсах Майкрософт :
"Проектирование серверной инфраструктуры баз данных SQL Server" 70-443
"Проектирование и оптимизация доступа к базам данных SQL Server" 70-442.
Выпущены и доступны официальные пособия для самоподготовки на русском языке.

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

Я, кстати, только начал изучать один из них. Так что в этих вопросах я тоже не специалист.

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

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

с базой работают 10-15 человек и она стала тормозить. Перевели сеть на гигабайт, отключили антивирус, сделали еще что-то и теперь стало лучше

Это разве разве отчет о производительности? Где-то стало видно, что программа стала удовлетворять требованиям?

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

Вот и вопрос: у кого ниже квалификация?

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

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

вот тут заменить надо жесткий диск, а еще надо использовать терминал для доступа к серверу. А еще я вот перенес базу, поставил новый релиз и теперь отчет делается не за 5 минут, а за 3 минуты

Да директору не зачем знать, сколько делается отчет. У него своих дел хватает. Ему нужно держать в голове партнеров, поставки, кадры и т.д. Какое ему дело, сколько теперь делается отчет?

Что ему скажем, что теперь отчет делается на 2 минуты быстрее? А ведь именно так говорят 1С-ники. Бухглатера, скажите я не прав? Они как-то по-другому говорят?

Вот поэтому и придуман Apdex. С помощью него, любой человек, который даже в глаза не видел 1С будет знать: чем ближе значение к 1, тем лучше. А маленький Apdex - это значит, что надо исправлять, значит эта часть работает медленно.

Просто даете директору отчет и говорите:

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

• по открытию программы: с оценки Удовлетворительно, на оценку Хорошо (с 0.76 до 0.91)
• по подготовке отчета: с оценки Хорошо на оценку Отлично (с 0.88 до 0.97)

до сих пор низкая оценка производительности программы по показателям:

• проводка товара - Удовлетворительно (индекс 0.77)
• подготовка Акта сверки - Хорошо (оценка 0.87)

При этом на Вашем предприятии считается приоритетным является производительности по подготовке Акта сверки, согласно переданного нам списка приоритетов
P.S. для справки, индекс производительности может колебаться от 0 до 1, где 0 - значит, что программа работает неудовлетворительно, а 1 - работает 100% отличной производительностью

Вот такой отчет понятен любому человеку, а не как обычно: пробормочет 1С-ник кучу непонятных слов себе под нос и уйдет взяв с собой кучу денег непонятно за что.

Вообще, вопросы производительности лучше разбирать на конкретном примере. Общие разговоры здесь бесплодны.

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

Наверное, это я и хотел сказать, упомянув отсутствие квалификации.

У меня были случаи, разные.
Ну вот например. 30 пользователей в 15 ГБ базе. Отчеты тормозят, постоянно переписываем алгоритмы. Улучшаем на 2-3-5 процентов скорость отчетов и скорость работы. Перепроведение доков тормозит. Запускаем на ночь и к утру еще не готово. Что делать? До посинения переписывать алгоритмы, запуская каждый раз Апдексы и фиксируя копеечный прирост?
Рекомендовал сменить сервер. Долбил эту мысль полгода, не меньше. Пока не продолбил. Пока не устали отвечать - "нам головная организация не позволяет купить новый сервер". Стал отвечать - вот когда база рухнет, то и отсылайте ее в вашу головную, пусть восстанавливают. Составил акт-прогноз, расчет убытков от сбоя, расчет времени простоя, дал на ознакомление всем ЛПР. Ходил и долбил, как упомянутый Вами нудный, противный 1С-ник, который ходит, берет деньги, и что-то бормочет. А как иначе было поступать? Есть такой самый страшный у нас враг оптимизации - "суровые головные организации".

Продолбил. Сменили сервер. Производительность выросла в разы. Без всякого переписывания алгоритмов. И это даже на встроенном дисковом массиве Рэйд5, а не на внешнем.

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

Вывод1: Без привязки к аппаратной базе и объему БД индексы Апдекс для конкретной проги не имеют смысла.
Вывод2: Вопросы производительности желательно обсуждать на конкретных примерах.

Курсаков_С_А писал(а):Производительность выросла в разы

производительность выросла как? В 10 раз, в 2 раза, в 15 раз, в 50 раз?
Даже если Вы скажите, что выросла в 3.53 раза, то что она везде выросла одинаково? Т.е. и запускается она в 3.53 раза быстрее и окно ввода данных в 3.53 раза быстрее открывается, и отчет делается в 3.53 раза быстрее?

Вряд ли. Скорее одно делается быстрее, другое также, а что-то медленнее. И что?

Положим Вы можете сказать: теперь в 3.53 раза быстрее делается импорт данных из баз филиалов. Раньше импорт делался за 3 минуты 30 секунд, сейчас меньше минуты. И что? Это много? Или это мало? Может пускай бы она хоть за 40 минут бы делала импорт.

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

Вы уверены, что Вы правильно понимаете, где "тормозит, а где нет". Вот ускорили в одном месте, Вы могли потратить кучу своего времени и сил. А в на деле: да и черт с ним, что импорт делается 3 минуты. Хоть и можно ускорить его до минуты. Если мы ожидаем, что импорт может делать 3 минуты, то и незачем его ускорять, это не проблемное место.

А то, что у нас окно ввода данных открывается не за 2-3 секунды, за 15 секунд это может оказаться большей проблемой. Реально, кажется, что лишние 10 секунд на каждом окне. Но это приоритетная задача, индекс Apdex на которой 0.4 - т.е. в 60% окно показывается медленнее чем нужно. А с учетом, того, что и работают с ней чаще и важнее она для предприятия, то именно исправлять медленное открытие окна надо, а во все не импорт базы, за что обычно берутся 1С-ники.

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

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

Вывод3 : рассчитывать производительность "окна", или индекс производительности отдельного диалога, или отдельно взятого отчета - отдельно, в отрыве от всего остального приложения, по крайней мере, некорректно.

Еще практич. пример.
Многие используют 1С8. При накоплении больших объемов она ощутимо тормозит. Встает вопрос - как улучшить это? Да, до какого-то предела это можно улучшить. Но только до какого-то.

Можем ли мы улучшить (изменить) способ доступа к данным, которым пользуется 1С8? Нет, не можем. А кто знает, каким способом доступа к данным пользуется движок 1С8? Этот способ - OLE DB, или COM. Он универсальный. С одной стороны, это хорошо - универсальный способ можно легко переориентировать на другой источник данных - СКЛ, Оракл, ДВ2, и т.д. Но, с другой стороны, в любом учебнике по методам доступа к данным разъсняется, что, чем универсальнее способ доступа к данным, тем медленее он работает. Это раз.
Также в любом учебнике написано, что, фирма Майкрософт, единственный поставщик способов доступа к данным для Виндоуз, прекратила развитие способов ОЛЕ ДБ, ДАО, и ОДБС (перечислены в порядке возрастания времени нахождения на рынке). И основные усилия МС сейчас сосредоточены на способе доступа к данным - АДО/АДО.НЕТ (в 1С8 не используется). Возникает вопрос - как движок 1С8 может не тормозить, используя устаревший способ доступа к данным, от развития которого уже лет 5-10 как отказались? Учитывая то, что фирма 1С не производит собственных способов доступа к данным и не встраивает их в Виндоуз.

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

Да, если окно ввода данных открывается 15 секунд, а даже не 2-3 секунды - да им это важно. А что думает конкретный программист о Microsoft, 1C или политике Соединённого королевства Великобритании и Ирландии в области лечения простуды - это уже его личные проблемы. Предприятию важно знать конкретные узкие места, которые выполняются медленнее, чем нужно компании, а во все не то, что считает медленным программист.

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

А теперь представьте, что на предприятии несколько десятков, сотен, даже тысяч рабочих мест, которые выполняют разные задачи. И вот как понять, что делается медленно, а что нормально? Положим выборка товара делается 5 секунд, печать ТТН делается 20 секунд, а объединение данных по поставщикам выполняется 3 часа. Вопрос: что из этого надо исправлять?

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

Знаете, еще на территории ТС бытует вот такое заблуждение. Вот, купили программу (пусть даже ЕРП). Вот, не работает, тормозит. Ну, так нужно оптимизировать, и/или переделать программу....О том, что программу для такого уровня предприятия просто купить - это мало, никто почему то не думает...Фактически с покупкой программы типа ЕРП предприятие вынуждено полностью отказаться от старых методов работы и принять, просто принять логику этой программы (а иначе никак). А у нас по-прежнему норовят вызвать программиста и "....дописать вот тут "галочки и кнопочки".

Может быть, в этом проблема?

shurik_kz писал(а):

Кайрат-F2 писал(а): но, ни разу не видел, чтобы кто-то подсчитывал индекс производительности.

Индекс не считают, но при отладке в конфигураторе 1С 8 есть режим замера производительности. Например, отчет выполняется слишком медленно, и с помощью этого режима можно определить самое узкое (медленное) место в этом отчете.

Не знал такого, надо поэкспериментировать. Спасибо за сообщение.

Кстати, насчет аппаратной части, конечно, это тоже одно из узких мест. При переводе базы на сервера и SQL скорость возрастает, но есть и предел, что обусловлено самим движком 1С 7. Тогда уже никакая оптимизация не поможет. Вот у нас в торговле есть такая длительная операция "Формирование прайса", когда все записи справочника удаляются, а затем переписываются заново товаром, который фактически есть по данным учета. И вот как его не переписывай, все равно при наличии 20-30 тысяч товаро в базе, быстрее он не заработает. А так, конечно идея насчет индекса интересная, особенно если говорить с пользователями о скорости и т.п., т.к. это все субъективно. В общем, если возникнет надобность, буду расчитывать по этому индексу производительность программы.