node_profiling_example

nodejs 프로파일 링 예

내장 Nodejs 프로파일러 사용의 예. 나는 성능을 향상시키지 않았지만 몇 가지를 배웠습니다.

프로파일이 진행되고있는 것

LUNR을 사용하여 로컬 파일 시스템에 텍스트 파일의 전체 텍스트 검색 색인 구축. 현재 1000 파일을 색인하는 데 약 3 초가 걸립니다.

앱을 프로필하십시오

./profile.sh

파일 profile_output.txt 출력합니다. 이 파일을 해석하는 방법은 아래의 'Nodejs 프로파일 러 출력 읽기'섹션을 참조하십시오.

성능 문제를 식별하고 수정합니다

프로세스 시간의 81%가 '공유 라이브러리'에 소비되는 것을 알 수 있습니다.

 [Summary]:
   ticks  total  nonlib   name
    315   18.6%   96.6%  JavaScript
      0    0.0%    0.0%  C++
     80    4.7%   24.5%  GC
   1369   80.8%          Shared libraries
     11    0.6%          Unaccounted

 [Shared libraries]:
   ticks  total  nonlib   name
   1303   76.9%          C:Program Filesnodejsnode.exe
     65    3.8%          C:WINDOWSSYSTEM32ntdll.dll
      1    0.1%          C:WINDOWSSystem32KERNEL32.DLL

이 온라인 프로필 Visualiser를 사용하면 노드에 대한 대부분의 호출은 Builder.add에 기인 한 것으로 보입니다. 이는 약간 혼란 스럽습니다. 나는 이것이 파일 시스템에서 파일을 읽는 데 소요되는 시간 동안 'Blaming Builder.add 인 Async ReadFile Calling Add 때문일 수 있다고 생각합니다. 두 작업을 분리합시다.

LUNR 색인 구축에서 파일 읽기를 분리합니다

읽기 파일이 매우 빠릅니다. 앱 시간의 대부분은 Builder.add에 소비됩니다. 그러나 builder.add는 node.exe를 호출하고 그 이상으로 정보를 얻지 못합니다.

TODO

• Spy-JS가 유용합니까? 몇 분 동안 시도했는데 실제로 '예, builder.add가 많이 불립니다'라고 말해 줄 수있었습니다.

• 노드에서 무엇이 호출되는지에 대해 더 많이 볼 수있는 방법이 있습니까? 그리고 무엇으로?

---

Nodejs 프로파일 러 출력 해석

기본 프로파일 러는 샘플링 프로파일 러이므로 특정 간격으로 현재 명령어 포인터를 기록합니다.

어휘

• 진드기 : 녹음 된 명령어 포인터 위치 수
• 비정치 : 알려진 기능으로 거슬러 올라갈 수없는 지시 포인터 위치 수
• lib :?
• LazyCompile : 기능은 게으르게 편집되었습니다. 컴파일러에 소비 된 진드기의 수는 아닙니다!
• *: 최적화 된 기능
• ~ : 최적화되지 않은 기능

하단 업 섹션

• 부모 라인에 의해 "호출 된"인장 라인을 읽으십시오.
• 나는 이것에 대한 시각적 표현을 추천한다

프로파일 러 출력 시각화

여러 가지 도구가 있습니다. 여기에 편리한 온라인 도구가 있습니다 : https://mapbox.github.io/flamebearer/# profile_output.json 파일을 해당 사이트로 끌어 프로파일러 데이터를 시각화하십시오.

참조

• nodejs 문서
• Dude는 프로파일 러 출력을 설명합니다
• V8 프로파일 러 문서
• 온라인 프로필 Visualiser