Оценка производительности Axapta Object Server

[Kabardian]

Цитата:

Сообщение от gl00mie

А вообще, на счет мониторинга: зачем что-то делать, если все устраивает?

gl00mie, по-моему, не стоит запускать вопросы, связанные с производительностью системы AX-СУБД. Объясню на примере двух сценариев почему я так думаю.

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

• новая модификация
• увеличившееся количество конкурентных пользователей
• увеличившаяся нагрузка на СУБД
• изменение настроек системы (AX-СУБД)
• другие факторы.

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

Более жизненный сценарий
Cпустя год-два после внедрения AX, когда уже cоздана хренова туча модификаций, в системе одновременно работают много пользователей (ближе к 100, а может и больше), параметры системы AX-СУБД неоднократно менялись, нагрузка на СУБД тоже менялась, пытаются точечными ударами повысить производительность.

[gl00mie]

Цитата:

Сообщение от Kabardian

gl00mie, по-моему, не стоит запускать вопросы, связанные с производительностью системы AX-СУБД.

Не стоило понимать все буквально Я лишь хотел подчеркнуть, что сперва надо определиться с тем, по каким критериям качественно и количественно оценивать производительность системы и приемлемость текущего уровня производительности, а уже после этого думать, что нужно мониторить, где что подкручивать, etc. С точки зрения специалистов, занимающихся той же Аксаптой или базами данных, разумеется, очень часто есть желание улучшить тот или иной аспект работы системы, поскольку даже без всяких оценок, чисто аналитически реализация может быть неоптимальной. Но тут все же, по-моему, надо в первую очередь думать о том, какой эффект это даст с точки зрения бизнеса; в этом плане мне очень понравилась аналогия Дениса Федотенко - "синдром родителей дауна":

Цитата:

Сообщение от fed

если пообщаться с человеком, у которого два ребенка, один нормальный, а второй - с синдромом Дауна (ну или каким-то другим пороком развития), то можно с интересом заметить, что это родитель гораздо охотнее хвалится тем что "Петенька научился застегивать пуговки" (Это в 15 лет), чем тем что Васенька учится на отлично, ходит на спорт и популярен в классе
Вообще - оценка людьми результатов своей деятельности, зачастую основана не на объективной картине их достижений, а на том - сколько времени они на эту деятельность затратили.

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

Цитата:

Сообщение от Kabardian

Объясню на примере двух сценариев почему я так думаю.
Нереальный сценарий мониторинга (не замечен на реальных проектах)
С самого начала внедрения производят эталонные замеры производительности. Затем идет процесс постоянного мониторинга производительности системы в рабочей среде. Когда производительность системы заметно отклоняется от эталона определяются факторы, влияющие на производительность системы.

Более полно и системно подобный подход рассмотрен в статье Сергея Котова Обеспечение надежности работы Microsoft Axapta

Цитата:

Сообщение от Kabardian

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

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

• Время открытия формы "Заказы" - до 3 сек.
• Скорость работы скрипта, моделирующего цикл ввода и обработки заказа, - от 200 строк/мин.
• Время работы скрипта, моделирующего последовательный расчет трех наиболее популярных отчетов с типичными условиями выборки, - до 10 мин.

Цитата:

Сообщение от Kabardian

Более жизненный сценарий
Cпустя год-два после внедрения AX, когда уже cоздана хренова туча модификаций, в системе одновременно работают много пользователей (ближе к 100, а может и больше), параметры системы AX-СУБД неоднократно менялись, нагрузка на СУБД тоже менялась, пытаются точечными ударами повысить производительность.

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