Максим Старков. Рецепты приготовления технологического журнала.

Поділитися
Вставка
  • Опубліковано 21 бер 2021
  • Понимание принципов событий технологического журнала позволяет решать многие проблемы производительности и стабильности работы платформы 1С. О том, как взаимосвязаны события технологического журнала и как с их помощью можно анализировать серверные вызовы 1С на INFOSTART MEETUP Ekaterinburg.Online рассказал программист 1С из компании ДНС-Ритейл Максим Старков.
    Доклад в виде статьи: infostart.ru/1c/articles/1407...
  • Наука та технологія

КОМЕНТАРІ • 7

  • @karliam_v
    @karliam_v 3 роки тому +7

    Доклад огонь) Спикер ТОП)

  • @You2Ber42
    @You2Ber42 3 роки тому

    Отдельное спасибо, даже не спасибо, а отдельная благодарность за проект на github, очень интересный проект, буду изучать, может быть удастся что то привнести свое.

  • @vista77219
    @vista77219 Рік тому

    Автор пересказал нам то, что рассказывают на курсе "Применение методик." Мог бы и ссылку дать.

  • @You2Ber42
    @You2Ber42 3 роки тому

    Пересмотрел еще раз и не пойму на 34:20 почему отмена транзакции 9,5 секунд?
    Обычно же фиксируется время выполнения операции. Трназакция у нас установилась за 0, потом работал код 1С не имеющий вообще отношения к СУБД, потом мы откатываем транзакцию, я ожидал там увидеть 0.
    Т.е. например с hold понятно мы вошли в серверный сеанс, в момент первого запроса к СУБД (установка транзакции) захватили соединение, затем не важно что там происходило, при завершении серверного вызова мы освобождаем сеанс. Всего занимали его 9,5 секунд.
    Но почему отмена транзакции пишет не время потраченное на отмену а время жизни отменяемой транзакции не пойму.
    Как тогда будет выглядеть событие отмены если мы например 10 минут писали данные, а потом решили отменить транзакцию и PG еще 1 минуту чистил журнал?
    Я ожидал увидеть там одну минуту. Нет ли у вас тут ошибки?

    • @user-vz4pp6ju2k
      @user-vz4pp6ju2k Рік тому +2

      Извиняюсь за "некропостинг", но могу сказать, что: ошибки нет, сеанс все это время удерживал соединение с СУБД и, в итоге, откатил транзакцию. Смысл в том, что не само событие отката транзакции заняло 9,5 секунд, в удержание соединения с СУБД заняло 9,5 секунд. Сколько за это время мог накопить блокировок сеанс в рамках этого соединения - неизвестно. В докладе был примитивный пример, но суть должна быть понятна: длительные события SDBL с rollback transaction, это потенциальное зло

  • @You2Ber42
    @You2Ber42 3 роки тому

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