хочется замерить удельный вес отдельных документов и отчетов в системе.
идея какая.
сделать "замер" операций (открытие, запись) каждого документа, открытия форм списков, отчётов на чистой, отдельной базе без нагрузки нескольких сотен пользователей (что бы избежать неправильных оценок из-за блокировок, очередей ожидания и прочее). далее ежедневно считать кол-во открытий, записи документов, открытий списков справочников, формирование отчётов. после этого (я предполагаю) буду иметь картину "веса" каждого документа, операции в системе.
покритикуйте? предложите? я понимаю, что скорее всего изобретаю велосипед, но хочется понять что грузит систему. КАК грузит. не "много/сильно/мало/быстро", а конкретные цифры.
для того, что бы переписав какие-то части я мог сказать не "быстрее, лучше, красивее", а конкретные цифры - на сколько уменьшилась машинная нагрузка, на сколько "человеко-часов" сократилось время ожиданий/простоя.
видятся два пути:
1) какие-то штатные средства получения "количества вызовов"?
2) вставка вызова функции (предполагаемый вид УвеличитьСчетчик("ИмяОбъекта", "Операция")), которая будет увеличивать ежедневный счетчик каждого объекта по каждой операции.

по п.2 как лучше будет сделать? регистры? прямая запись в отдельную таблицу SQL(через ADO)? запись в текстовые файлы с последующим парсингом?(тут проблема видится в том, что много терминальных пользователей)

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

1С 8.1, самописка. 116 гиг база, 600 пользователей
с ув. наутилус

Господин ПЖкое что из инфы может дать правильно настроенный технологический журнал... что-то Центр Управления Производительностью ну и сайт Гилева www.gilev.ru
как меня убедили коллеги (сам я не считаю себя спецом в архитектуре и технологических моментах 1С) - в журнале (он ведётся у нас) можно получить только кол-во записей документов, но не их открытия. форм списков точно нет (у нас есть очень "тяжелый" раскрашенный список контрагентов), так же можно узнать сколько раз открывали отчет, но не сколько раз его формировали (реальная нагрузка)
Гилева читаю.

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

Программист 1сКак делается в теории. ... Перемножаете и сортируете по максимуму времени.

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

Программист 1сАнализ взаимоблокировок. Кому как - можно и цупом. Мне проще скулем - влючили на день журнал (это много достаточно и полчаса в пиковые моменты) и потом анализируете сколько было блокировок и кто и кого блокировал.
у нас очень сложно включать профайлер. пару раз пробовал, 2-3 минуты - сервер падал на колени. но мы отлавливаем процедуры, выполняемые более Х секунд. а так же блокировки продолжительные.
очень помогает для понимания "куда копать"

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

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

спасибо, Программист 1с!

Товарищ ЖоПэ,

спасибо!

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

Программист 1сСходите на экзамен (только в москве). 1 день - экзамен. Остальные 2-3 - рассказ о методике работы.
живу далеко =(...

Программист 1сА оценить уровень улучшений - мне кажется врятли можно кроме как тормозит и не тормозит. Потому что вызывают только когда тормозит . А когда не томозит - то зачем оптимизировать?
Не волнуйся, если что-то работает не так. Если бы все работало как надо - ты сидел бы без работы. =))
ну оценивать надо как-то. есть же разница как говорить:
1) мы делали-делали и вот стало "быстрее, лучше, красивее". дай денег
2) было так (ожидание проведения документа 5 минут, 1000 документов, ХХХ человеко-часов). стало - в 5 раз быстрее. ваша выгода - ХХХ рублей "условно" на освободившихся часах. дай денег.

AHDPнаутилус[
ну оценивать надо как-то. есть же разница как говорить:
1) мы делали-делали и вот стало "быстрее, лучше, красивее". дай денег
2) было так (ожидание проведения документа 5 минут, 1000 документов, ХХХ человеко-часов). стало - в 5 раз быстрее. ваша выгода - ХХХ рублей "условно" на освободившихся часах. дай денег.

1) А зарплату Вам за что платят и кто перед этим сделал плохо? ;)
2) В общем случае не совсем верно, т.к. условно-быстрые куски кода могут затормозиться одним медленным. Если вы ускорите быстрые документы в 10 раз, но они все будут тормозиться одним медленным документом, толку от такой оптимизации для пользователей не будет :( От понимания архитектуры вам никуда не деться.
1) ну не совсем верно. было 150 пользователей. потом 300. теперь 600. понятно, что архитектурное решение на 600 должно быть лучше и оптимальнее чем на 150. не закладывались такие нагрузки. в этом прощёлкали. да.
2) вобщем случае может и не верно. но! имеется надежда, что можно создать "ощущение" убыстрения, что бы выиграть время на массивное и тяжёлое переписывание главных кусков.

и самое важное (для меня сейчас) мне бы хотелось цифрами оперировать. для себя. быстрее или не быстрее. лучше или хуже. соотносимы две недели переписывания документа с выигрышем в 5% скорости? (а может будет 200% прироста). да и заказчикам (точнее людям, которые платят деньги, а соответственно умеющие их считать) проще показать "результат" работы

AHDP1) И что? У вас производительность упала в 4 раза или больше? Или вы знаете универсальный алгоритм повышения быстродействия любой системы для большого количества пользователей ;)
стало "медленнее" на сколько - никто сказать не может.

AHDP2) Поверьте, Ваши 20% выйгрыша производительности пользователи не заметят. И продолжат жаловаться. В лучшем случае вы сможе доказать вашему финику, что теперь можно добавить ещё 10% пользователей.
ну отчего же 20% не заметят? мне кажется это значительный скачок будет. да, на секунде-полсекунды не заметят. на более больших будет заметней. но это опять же "предположительно"

AHDPЗЫ А архитектурное решение должно быть оптимальным сразу.
должно, но не обязано ))) и как грил наш президент "маемо тэ шо маемо"

AHDPЗЗЫ Условно-быстрые документы оптимизировать труднее, чем медленные. Время затрачиваемое на обработку документа стремиться не к нулю, а к архитектурно-техническим ограничениям вашей системы.
пнимаете, что если список контрагентов открывается секунд 20-30 и его вызывают нуууу очччень много раз, то оптимизировав его, я надеюсь, мы получим хорошие отзывы.

AHDPЗЗЗЫ Ещё вы обещались отписаться о результатах разделения массива с темпдб на два диска, моделях контроллеров и структуре базы применительно к вашему многотабличному документу.
не хотят падлы делить. админы заказчика. теоретически согласны, практически чего-то ждут.
структура да, обещал. =/ подскажите как это быстрее сделать?

AHDPТогда всех в сад. Типа так и работало и работатть должно. За дополнительные деньги потом улучшим ;)
да деньги они не против платить. только вот я бы на их месте спросил "на сколько вы улучшили и почему я должен платить"


AHDPВы замечеате разницу между минутой и 48ю секундами? Уверен, что нет. Сравнивайте с другими операциями пользователей. Соберите время простоя пользователя в одно место. Сделайте так, чтоб он мог продуктивно поработать, и передохнуть во время работы системы. А чтоб Пользователь что-то замети улучшать надо минимум процентов на 30-50.
наверное вы правы, при разовой операции я этого не замечу.. но собирать, имхо, надо не на одно место, а на операцию. если одну операцию в 2 минуты делают тысячи раз, то прирост даже 20% освободит ресурсы сервера значительно (изза общего "веса" операции), соответственно остальное тоже должно "шевелиться" быстрее. хотя бы из-за меньшего кол-ва блокировок, очереди записи и т.п.

AHDPА вы уверены, что сможете улучшить этот показатель хотябы на 5%? Сначала посмотрите какие операции у вас просаживаются при большом числе активных пользователей и что служит тому причиной.
не уверен. но если вообще не мерять - то непонятно на 5% улучшили или на 50%

AHDPДля начала посмотреть на алгоритмы при сохранении и проведении документа, потом на количество и размер обрабатываемых ими данных. Может у Вас там при рассчётах вся информационноя база перелопачивается и надо вводить регистры.
ну вот и переписывают ща документ на регистры.

AHDP,

заказчик не может озвучить что для него "приемлемо". он хочет большую синюю кнопку "пыщ" - и шоп работало.

AHDP,

собрали. прислали

отчёт. вызывается часто. выполняется долго. нужен редко

10 строк. =((((((((
толку.

правильно выше говорили. нет архитектора. нет понимания "куда двигаться".

AHDP,

второй есть. первый уже не силён...

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

AHDPЭто у вас финдир не вменяемый? Так покажите ему эту выкладку как обоснование покупки супер-пупер сервера ;)
финдир заказчика, как раз вменяемый (ну если фирма так растёт и развивается).... а вот ИТ-отдел... или КТО-ТО, кто бы понимал куда двигаться и зачем и каким образом - с этим немного туго.
но это отдельная тема... немного не кошерно её здесь обсуждать.

спасибо за участие ;)