Галактика в вопросах и ответах

Случайно не вы решали нашу проблему? А то звучит как обвинение - мол сами виноваты, что больше трех месяцев мучились.
Для решения подобных проблем, в первую очередь и существует ТП. И если она не справляется, должны подключаться разработчики. Этого не было сделано сразу. А по поводу передачи базы - только в этом году выложили утилиту обезличивания.
В итоге проблема решена (ПИРа под рукой нет). Разработчики признали ошибку. Режим работает 5 мин.
ЗЫ. Всегда работает терминал на тестовой базе. Но ТП и, тем более, разработчики не горят желанием удаленно проверить наши проблемы.

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

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

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

Традиционно к оптимизации тех или иных режимов, люди пытаются подойти примерно следующим путем:

- Вопрос, добрый день у нас проблема производительности "П1" факты которые ей сопутствуют "Ф1, Ф2, Ф3"
- Ответ, да с похожей проблемой уже сталкивались, попробуйте применить рецепты "Р1, Р2"
- Снова вопрос, рецепты "Р1, Р2" применили, но проблема "П1" осталась. Кстати мы заметили, что вместе с проблемой происходит факт "Ф4".
- Ах да факт Ф4 очень важный факт, он теоретически может повлиять на производительность, сделаем заплатку, примените ее вот вам рецепт "Р4"
- Применили "Р4" - не помогло, может что еще предложите .........?

Это процесс может длиться бесконечно. Повезет если на очередной итерации с рецептом угадают. Н если не угадают? Как понять сколько итераций нужно еще? Даже если угадали, как понять это все что может программа или можно еще ускориться?

Метод , основанный на измерении, работает по другому. Ели отчет работал до июля 30 мин., а сейчас 30-40 часов. То интересно узнать что же такое делает программа в каждую секунду (в каждое мгновение) из этого времени. Нужно произвести измерения, и замерить какие стоки кода при этом исполнялись и на какую строку кода пришлось более всего времени.

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

Т.е за одну итерацию сразу клиент гарантировано получит оптимизированное решение.

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

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

Все правильно пишите, только:
1. Анализ профайлера (об нем речь?) должен делать специалист ТП или разработчик. Что толку если я найду непонятные бесконечные выборки в профайлере? Без исходников я не смогу сделать никаких выводов. Кстати, профайлер был отослан в ТП через месяц после начала проблемы.
2. По поводу невозможности работы в терминальном режиме, можно подробней, почему не будет работать?

вообще-то Галактика должна иметь свой профайлер и trace logger. Мы уже несколько раз сигнализировали об этом! Скажем идет runtime error, нам говорят - рубите свои ресы по одному, а у нас их больше сотни. Отключение одного занимает минут 10-15, со всякими пересчетами. Хотя могли бы сделать специальный ресурс, который бы делал перехват критической ошибки, раскручивал стек вызовов, чтобы сразу понять в каком компоненте и в какой функции идет ошибка. Ну и как сахарок - автоматическая отправка лога разработчику. Сколько бы времени сэкономили и себе и нам.
А профайлер это уж будьте добры предоставьте. Сбор статистики по среднему времени вызова функции и кол-ву таких вызовов организовать несложно. Скажем поставил в настройках опцию и все обращения к функциям пошли через компонент диспетчеризации - в конце работы свод данных. Ну право смешно предлагать нам читать книги по оптимизации, если код чужой и возможности его исправить у нас нет

ну в галке много чего есть подводного - типа спец.dll для оракла с трасировщиков запросов. Да и секции разные с debug. Для своего кода можно отладчиком воспользоваться в сапорте - компилятор фейсов.

отладчик != профайлер
вот что примерно хотелось бы видеть: http://www.red-gate.com/products/ants_p ... /step9.htm

Polimer писал(а): 1. Анализ профайлера (об нем речь?)

Нет я не имел в виду профайлер MS SQL. Это вещь конечно хорошая, но только для того чтобы определить на чьей стороне проблема. На стороне софта или на стороне базы и железа. Для детализации проблем VIP, Pascal и C++ кода это не подходит. Проблема ведь не всегда в доступе к базе.

В поле может оказаться так, что из базы все данные в память закачиваются за 5 мин, а 40 частов в памяти методом пузырька обрабатываются, потом за минуту выдаются в отчет.

Я говорил о функции профилирования, которая встроена в отладчик VIP кода. И о специальном ПО для пофилирования кода Pascal и С++. http://www.automatedqa.com/products/aqtime

Polimer писал(а): 2. По поводу невозможности работы в терминальном режиме, можно подробней, почему не будет работать?

Работать будет но для этого на ваш сервер нужно закачать и установить ПО для профилировки. Исходные коды галактики. Отладочную информацию к Галактике. Если вы позволите хозяйничать на вашем сервере. То технических проблем нет. Был бы только канал толстый.

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

galover писал(а):отладчик != профайлер
вот что примерно хотелось бы видеть: http://www.red-gate.com/products/ants_p ... /step9.htm

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

LaaLaa
так у вас для Vip-а свой профайлер уже должен быть!

galover писал(а):LaaLaa
так у вас для Vip-а свой профайлер уже должен быть!

Профайлер VIP есть, а базы данных где наблюдаются тормоза нет.

Поверьте, на наших тестовых базах Галактика работает достаточно хорошо.

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

edward_K писал(а):ну в галке много чего есть подводного - типа спец.dll для оракла с трасировщиков запросов. Да и секции разные с debug. Для своего кода можно отладчиком воспользоваться в сапорте - компилятор фейсов.

К стати эта наша протокольная спец.dll для оракла и MS SQL, тоже не поможет если проблема производительности в VIP или Pascal коде :(

galover писал(а):Ну право смешно предлагать нам читать книги по оптимизации, если код чужой и возможности его исправить у нас нет

Полагаю это форум читают не только пользователи но специалисты галактики и партнеров. А в книге описан действительно хорошо работающий метод. Участниками этого метода являются как разработчика так и пользователи. Если сотрудничать вместе то метод будет действовать.

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

Вторая и третья часть этой книги, чисто справочная, интересна только ораклистам. Но первая часть будет интересна всем, первую очередь руководителям отделов АСУ на предприятиях пользователей.

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

Профайлер VIP есть

выложите, очень нужен!!!!