Часто в процессе оптимизации или логирования работы конфигураций 1С разработчики сталкиваются с необходимостью точного замера времени выполнения определенных участков кода. На первый взгляд кажется логичным использовать для этого функцию ТекущаяУниверсальнаяДатаВМиллисекундах. Однако, если мы замеряем время вызова серверной процедуры с клиента, нас поджидает множество неочевидных проблем. Давайте подробно разберем, как работает отсчет времени в платформе, почему возникают ошибки в измерениях и как правильно профилировать код.
Рассмотрим особенность функции ТекущаяУниверсальнаяДатаВМиллисекундах. Если вы попытаетесь вывести ее результат, то увидите огромное число (более 63 триллионов). Дело в том, что в отличие от многих других языков программирования, где отсчет "Unix-эпохи" начинается с 1 января 1970 года, платформа 1С считает миллисекунды, прошедшие с 1 января 0001 года (00:00:00 по UTC).
Так как функция возвращает универсальное время (по Гринвичу/UTC), для преобразования полученного значения обратно в локальное время пользователя нам нужно делать поправку на смещение часового пояса. В современных решениях для этих целей лучше использовать встроенный функционал Библиотеки стандартных подсистем (БСП) или метод УниверсальноеВремя.
Проанализируем частую ошибку разработчиков при замерах производительности. Допустим, мы пытаемся вычислить точное время работы алгоритма на сервере, фиксируя время до вызова на клиенте, а затем вычитая время, зафиксированное внутри самой серверной процедуры.
Делать так категорически нельзя. Как справедливо отмечается в обсуждениях, клиент и сервер — это "разные вселенные". Системные часы на компьютере пользователя (клиента) и на сервере 1С не синхронизированы с абсолютной точностью. Между ними всегда есть рассинхронизация на миллисекунды, секунды, а в запущенных случаях системного администрирования — даже на минуты. Вычислить точную аппаратную или сетевую задержку таким образом не выйдет, так как в результат вмешается погрешность времени между двумя физическими машинами.
Посмотрим на то, что мы на самом деле измеряем, если фиксируем время на клиенте до вызова серверной функции и после её возврата на клиент. В этом случае мы получаем общее время кругового обращения ("round-trip"). В эти миллисекунды входит сразу несколько этапов:
Поэтому огромная разница в миллисекундах не всегда означает, что тормозит именно код. Возможно, проблема в медленном сетевом канале между пользователем и сервером предприятия.
Хотя вычисление разницы через ТекущаяУниверсальнаяДатаВМиллисекундах отлично подходит для фонового программного логирования длительности ключевых операций в журнал регистрации, для реального поиска узких мест этот метод избыточен и неточен.
Для оценки скорости кода мы всегда рекомендуем использовать встроенный в Конфигуратор или 1C:EDT механизм «Замер производительности».
Разберем по шагам его преимущества:
Важный нюанс: чтобы встроенный замер показал длительность выполнения серверных строк кода, служба сервера 1С:Предприятия обязательно должна быть запущена в режиме отладки (с параметром -debug). Иначе платформа покажет вам только клиентскую часть вызова, скрыв истинные причины "тормозов" алгоритма внутри серверных модулей.