Случайно не вы решали нашу проблему? А то звучит как обвинение - мол сами виноваты, что больше трех месяцев мучились.
Для решения подобных проблем, в первую очередь и существует ТП. И если она не справляется, должны подключаться разработчики. Этого не было сделано сразу. А по поводу передачи базы - только в этом году выложили утилиту обезличивания.
В итоге проблема решена (ПИРа под рукой нет). Разработчики признали ошибку. Режим работает 5 мин.
ЗЫ. Всегда работает терминал на тестовой базе. Но ТП и, тем более, разработчики не горят желанием удаленно проверить наши проблемы.
Быстродействие
Модераторы: m0p3e, edward_K, Модераторы
-
LaaLaa
Нет, нет ни в коем случае, я никого не хотел обидеть. Просил извинить за то что встреваю в разговор не имея никакой конкретной информации об отчете который тормозит. Т.е. конкретно с вашей проблемой дела не имел. Но имел опыт как провалов так и успехов в борьбе с производительностью галактики в других местах.
-
LaaLaa
Попытайтесь отнестись к информации которую озвучил в этой ветке форума чисто с технической стороны дела. Цель моего сообщения не только для клиентов, но и для служб поддержки и для программистов.
И книгу которую рекомендовал, нужно почитать всем. Автор книги довольно популярно описывает в чем слабые стороны традиционного подхода в борьбе с проблемами производительности. И в чем сильные стороны в подходе основанном на измерении времени отклика (профилировании, построении профиля ресурсов)
Традиционно к оптимизации тех или иных режимов, люди пытаются подойти примерно следующим путем:
- Вопрос, добрый день у нас проблема производительности "П1" факты которые ей сопутствуют "Ф1, Ф2, Ф3"
- Ответ, да с похожей проблемой уже сталкивались, попробуйте применить рецепты "Р1, Р2"
- Снова вопрос, рецепты "Р1, Р2" применили, но проблема "П1" осталась. Кстати мы заметили, что вместе с проблемой происходит факт "Ф4".
- Ах да факт Ф4 очень важный факт, он теоретически может повлиять на производительность, сделаем заплатку, примените ее вот вам рецепт "Р4"
- Применили "Р4" - не помогло, может что еще предложите .........?
Это процесс может длиться бесконечно. Повезет если на очередной итерации с рецептом угадают. Н если не угадают? Как понять сколько итераций нужно еще? Даже если угадали, как понять это все что может программа или можно еще ускориться?
Метод , основанный на измерении, работает по другому. Ели отчет работал до июля 30 мин., а сейчас 30-40 часов. То интересно узнать что же такое делает программа в каждую секунду (в каждое мгновение) из этого времени. Нужно произвести измерения, и замерить какие стоки кода при этом исполнялись и на какую строку кода пришлось более всего времени.
Получив информацию об распределении времени по строчкам кода, можно понять какая сточка или фрагмент кода больше всех тормозит. Какую часть в общем времени это занимает. Насколько ускориться отчет в целом если оптимизировать это фрагмент кода.
Этот метод гарантировано и однозначно покажет ту причину тормозов которую нужно устранять.
Т.е за одну итерацию сразу клиент гарантировано получит оптимизированное решение.
И книгу которую рекомендовал, нужно почитать всем. Автор книги довольно популярно описывает в чем слабые стороны традиционного подхода в борьбе с проблемами производительности. И в чем сильные стороны в подходе основанном на измерении времени отклика (профилировании, построении профиля ресурсов)
Традиционно к оптимизации тех или иных режимов, люди пытаются подойти примерно следующим путем:
- Вопрос, добрый день у нас проблема производительности "П1" факты которые ей сопутствуют "Ф1, Ф2, Ф3"
- Ответ, да с похожей проблемой уже сталкивались, попробуйте применить рецепты "Р1, Р2"
- Снова вопрос, рецепты "Р1, Р2" применили, но проблема "П1" осталась. Кстати мы заметили, что вместе с проблемой происходит факт "Ф4".
- Ах да факт Ф4 очень важный факт, он теоретически может повлиять на производительность, сделаем заплатку, примените ее вот вам рецепт "Р4"
- Применили "Р4" - не помогло, может что еще предложите .........?
Это процесс может длиться бесконечно. Повезет если на очередной итерации с рецептом угадают. Н если не угадают? Как понять сколько итераций нужно еще? Даже если угадали, как понять это все что может программа или можно еще ускориться?
Метод , основанный на измерении, работает по другому. Ели отчет работал до июля 30 мин., а сейчас 30-40 часов. То интересно узнать что же такое делает программа в каждую секунду (в каждое мгновение) из этого времени. Нужно произвести измерения, и замерить какие стоки кода при этом исполнялись и на какую строку кода пришлось более всего времени.
Получив информацию об распределении времени по строчкам кода, можно понять какая сточка или фрагмент кода больше всех тормозит. Какую часть в общем времени это занимает. Насколько ускориться отчет в целом если оптимизировать это фрагмент кода.
Этот метод гарантировано и однозначно покажет ту причину тормозов которую нужно устранять.
Т.е за одну итерацию сразу клиент гарантировано получит оптимизированное решение.
-
LaaLaa
Все правильно пишите, только:
1. Анализ профайлера (об нем речь?) должен делать специалист ТП или разработчик. Что толку если я найду непонятные бесконечные выборки в профайлере? Без исходников я не смогу сделать никаких выводов. Кстати, профайлер был отослан в ТП через месяц после начала проблемы.
2. По поводу невозможности работы в терминальном режиме, можно подробней, почему не будет работать?
1. Анализ профайлера (об нем речь?) должен делать специалист ТП или разработчик. Что толку если я найду непонятные бесконечные выборки в профайлере? Без исходников я не смогу сделать никаких выводов. Кстати, профайлер был отослан в ТП через месяц после начала проблемы.
2. По поводу невозможности работы в терминальном режиме, можно подробней, почему не будет работать?
вообще-то Галактика должна иметь свой профайлер и trace logger. Мы уже несколько раз сигнализировали об этом! Скажем идет runtime error, нам говорят - рубите свои ресы по одному, а у нас их больше сотни. Отключение одного занимает минут 10-15, со всякими пересчетами. Хотя могли бы сделать специальный ресурс, который бы делал перехват критической ошибки, раскручивал стек вызовов, чтобы сразу понять в каком компоненте и в какой функции идет ошибка. Ну и как сахарок - автоматическая отправка лога разработчику. Сколько бы времени сэкономили и себе и нам.
А профайлер это уж будьте добры предоставьте. Сбор статистики по среднему времени вызова функции и кол-ву таких вызовов организовать несложно. Скажем поставил в настройках опцию и все обращения к функциям пошли через компонент диспетчеризации - в конце работы свод данных. Ну право смешно предлагать нам читать книги по оптимизации, если код чужой и возможности его исправить у нас нет
А профайлер это уж будьте добры предоставьте. Сбор статистики по среднему времени вызова функции и кол-ву таких вызовов организовать несложно. Скажем поставил в настройках опцию и все обращения к функциям пошли через компонент диспетчеризации - в конце работы свод данных. Ну право смешно предлагать нам читать книги по оптимизации, если код чужой и возможности его исправить у нас нет
отладчик != профайлер
вот что примерно хотелось бы видеть: http://www.red-gate.com/products/ants_p ... /step9.htm
вот что примерно хотелось бы видеть: http://www.red-gate.com/products/ants_p ... /step9.htm
-
LaaLaa
Нет я не имел в виду профайлер MS SQL. Это вещь конечно хорошая, но только для того чтобы определить на чьей стороне проблема. На стороне софта или на стороне базы и железа. Для детализации проблем VIP, Pascal и C++ кода это не подходит. Проблема ведь не всегда в доступе к базе.Polimer писал(а): 1. Анализ профайлера (об нем речь?)
В поле может оказаться так, что из базы все данные в память закачиваются за 5 мин, а 40 частов в памяти методом пузырька обрабатываются, потом за минуту выдаются в отчет.
Я говорил о функции профилирования, которая встроена в отладчик VIP кода. И о специальном ПО для пофилирования кода Pascal и С++. http://www.automatedqa.com/products/aqtime
Работать будет но для этого на ваш сервер нужно закачать и установить ПО для профилировки. Исходные коды галактики. Отладочную информацию к Галактике. Если вы позволите хозяйничать на вашем сервере. То технических проблем нет. Был бы только канал толстый.Polimer писал(а): 2. По поводу невозможности работы в терминальном режиме, можно подробней, почему не будет работать?
Но еще одна загвоздка в том что не все исходные коды и отладочную информацию мы можем вам открыть, из за соображений нашей безопасности.
-
LaaLaa
galover писал(а):отладчик != профайлер
вот что примерно хотелось бы видеть: http://www.red-gate.com/products/ants_p ... /step9.htm
Именно об этом я и говорил, в отделах разработки подобное ПО есть и мы им пользуемся. Но дистанционно его применить невозможно.
-
LaaLaa
Профайлер VIP есть, а базы данных где наблюдаются тормоза нет.galover писал(а):LaaLaa
так у вас для Vip-а свой профайлер уже должен быть!
Поверьте, на наших тестовых базах Галактика работает достаточно хорошо.
Периодически приходят проблемные от различных пользователей. Их проблемы решаются. А там где нет доступа к реальным данным, решение проблем длиться годами.
-
LaaLaa
К стати эта наша протокольная спец.dll для оракла и MS SQL, тоже не поможет если проблема производительности в VIP или Pascal коде :(edward_K писал(а):ну в галке много чего есть подводного - типа спец.dll для оракла с трасировщиков запросов. Да и секции разные с debug. Для своего кода можно отладчиком воспользоваться в сапорте - компилятор фейсов.
-
LaaLaa
Полагаю это форум читают не только пользователи но специалисты галактики и партнеров. А в книге описан действительно хорошо работающий метод. Участниками этого метода являются как разработчика так и пользователи. Если сотрудничать вместе то метод будет действовать.galover писал(а):Ну право смешно предлагать нам читать книги по оптимизации, если код чужой и возможности его исправить у нас нет
Прочитайте первую часть этой книги, где описан сам метод. Где описаны организационные походы к решению проблем производительности.
Вторая и третья часть этой книги, чисто справочная, интересна только ораклистам. Но первая часть будет интересна всем, первую очередь руководителям отделов АСУ на предприятиях пользователей.
Повлиять на исправление проблемы производительности вы можете путем правильной постановки задачи перед разработчиком. Выделить критически важные для вашего бизнеса функции только вы можете, а не кто то со стороны.