Я использую Node Profiler для отслеживания скачка загрузки процессора. Первоначально при запуске команды docker stats мне удалось обнаружить контейнер, который вызывал всплеск. Мне удалось настроить профилировщик и сгенерировать необходимый файл .txt в соответствии с do c. После просмотра файла, просматривая множество строк "LazyCompile ...." для MongoDB и Mon goose, я смог найти строки, ссылающиеся на файлы в моей фактической базе кода.
Проблема в том, что что он указывает на номера строк, которые находятся за пределами длины строки файла, что не помогает. Есть ли способ, которым я могу найти или получить доступ к скомпилированной версии файла, которая содержит номера строк, на которые указывает эта ссылка?
У меня есть теория о том, где может быть проблема. У меня есть функция, которая возвращает массив, который будет служить параметром для агрегатной функции MongoDB. Тело этой функции очень большое из-за сложности этого агрегата. Кажется, что компиляция этого массива в вызов агрегата может стать узким местом.
Существует ли альтернативный способ работы с большими параметрами агрегата по сравнению с этим подходом, т. Е. Способ принудительной предварительной компиляции и избежание Компиляция каждый раз, когда нужно запустить. В настоящее время я использую обозначение функции стрелки es6 вместе с синтаксисом "=> ([...])" для возврата массива, но не уверен, что это может вызвать проблему, в отличие от "=> {return [... ]} "?