성능 문제 해결

툴킷 사용 시 속도가 느려지는 문제가 발생할 수 있습니다. 이러한 문제의 원인으로는 서버 속도, 인터넷 연결 등의 클라이언트 측 인프라 문제부터 툴킷 또는 ShotGrid 구성 시 성능이 고려되지 않은 구성 관련 문제, 그리고 최적화를 추가적으로 적용할 코드 영역까지 다양할 수 있습니다.

다음은 확인해야 할 사항의 목록으로, 아래에서 자세히 살펴보겠습니다.

• 앱, 엔진, 프레임워크, 코어 및 ShotGrid 데스크톱이 최신 상태인지 확인합니다.
• 일반적인 사용 중에 디버그 로깅이 활성화되지 않았는지 확인합니다.
• 필요한 폴더만 생성하며 폴더가 실제로 필요할 때만 생성되도록 제한합니다. 너무 많은 폴더를 스키마에 추가하면 속도가 느려집니다.
• 서버에 사용자 캐시를 저장하면 속도가 느려질 수 있습니다. 로컬 드라이브 위치를 가리키도록 ShotGrid ShotGrid_HOME 환경 변수 를 설정하여 사용자의 캐시를 리디렉션할 수 있습니다.
• 아티스트에게 필요하지 않은 컨텐츠는 필터링하여 제외하도록 Workfiles 및 Loader 앱을 구성합니다. 엔티티 목록을 아티스트의 현재 태스크와 관련이 있는 항목으로 간결하게 유지하려면 상태를 기준으로 필터링해 보십시오.
• 커스텀 후크가 있는지 그리고 이러한 커스텀 후크로 인해 오버헤드가 증가하지는 않는지 확인하십시오.

아래 목록에는 모범 사례와 속도 저하 문제가 발생하는 일반적인 사례가 정리되어 있습니다. 전체 사례가 수록된 완전한 목록은 아니며 새로운 패턴이 발견되는 대로 목록에 추가하겠습니다. 이 안내서가 문제 원인을 파악하는 데 도움이 되지 않을 경우 언제든지 지원 티켓을 제출해 주십시오. Shotgun 팀이 도와드리겠습니다.

목차:

• 일반적인 모범 사례
  • 캐시 위치
  • 최신 버전 유지
  • 중앙 집중식 구성과 분산 구성 비교
  • 디버깅
• 소프트웨어의 시작 속도가 느림
  • 진단
  • 문제가 시작 전에 발생합니까? 아니면 시작 후에 발생합니까?
  • 로그 확인
  • 소프트웨어의 실행 속도가 느려지는 일반적인 원인
• File Open, File Save 또는 Loader 앱의 속도가 느립니까?
• 폴더 생성 속도가 느림
  • 입출력량 문제 해결
  • 폴더 등록

일반적인 모범 사례

캐시 위치

ShotGrid 툴킷은 사용자의 홈 디렉토리에 데이터를 캐시합니다. 이 캐시에는 여러 가지 SQLite 데이터베이스와 캐시된 앱 및 구성이 포함될 수 있습니다. 대개 사용자의 홈 디렉토리는 시스템의 로컬 하드 드라이브에 저장되지만, 스튜디오에서 이를 네트워크 저장소로 리디렉션하는 경우가 많습니다. 이렇게 되면 성능에 영향을 미칠 수 있습니다. 특히, 브라우저 통합 및 폴더 생성/조회 등에 사용되는 SQLite 데이터베이스에 주로 영향을 미칩니다.

사용자 디렉토리가 서버 위치에 저장되는 경우 ShotGrid_HOME 환경 변수를 사용하여 ShotGrid 툴킷 캐시의 경로를 변경하는 것이 좋습니다. ShotGrid_HOME 환경 변수는 툴킷이 번들 캐시, 썸네일, 그리고 데이터의 빠른 조회에 사용되는 SQLite 데이터베이스 등과 같은 다양한 데이터를 캐시하는 위치를 설정하는 데 사용됩니다.

디버깅

ShotGrid 툴킷에서 디버그 로깅을 활성화할 수 있습니다. 그러면 다양한 프로세스에 대한 출력을 더욱 상세하게 얻을 수 있습니다. 문제를 진단하는 데 아주 유용한 기능이지만, 디버그 설정은 일상적인 사용 중에는 활성화되도록 설계되지 않았습니다. 로깅 출력이 늘어나면 성능에 상당한 영향을 미칠 수 있습니다.

성능 문제가 발생하면, 특히 특정 시스템 또는 사용자에 국한되어 성능 문제가 발생하는 경우 먼저 디버그 로깅이 활성화되지 않았는지 확인합니다.

최신 버전 유지

성능 문제가 발생하면 코어, 앱, 엔진 및 프레임워크가 최신 상태인지 확인하십시오. 최신 버전에서는 이미 수정 사항 또는 최적화 기능이 제공되었을 수 있습니다.

중앙 집중식 구성과 분산 구성 비교

고급 툴킷 구성은 중앙 집중식 구성과 분산 구성이라는 두 가지 방법으로 설정할 수 있습니다. 주된 차이점은 중앙 집중식 구성의 경우 일반적으로 모든 사용자가 액세스할 수 있는 스튜디오의 네트워크 저장소에 저장되며, 분산 구성의 경우 대개 클라우드에 저장되고 사용자별로 로컬로 캐시된다는 점입니다.

이러한 차이점은 성능 이외의 측면에도 영향을 미치지만 성능 차원에서도 각기 다른 장단점을 가집니다. 다음 표에는 성능 측면의 장단점이 정리되어 있습니다.

요약하자면 저장 장치의 속도는 느리지만 인터넷 연결 속도가 괜찮다면 분산 구성이 가장 좋은 선택이 될 수 있고, 서버 저장 장치 성능은 좋지만 인터넷 속도는 좋지 않을 경우에는 중앙 집중식 구성이 적합할 수 있습니다.

분산 구성을 사용하는 경우 사용자는 캐시에 없는 항목만 다운로드하면 되며, 한 사용자가 다운로드한 항목을 다른 사용자도 활용할 수 있게 됩니다. 이렇게 하려면 각 시스템에서 공유 위치를 가리키도록 ShotGrid_BUNDLE_CACHE_PATH 환경 변수를 설정하면 됩니다.

소프트웨어의 시작 속도가 느림

Maya, Nuke, Houdini 등의 소프트웨어를 시작할 때 ShotGrid 없이 시작할 때보다 시간이 오래 걸리는 것을 알아차리셨을 것입니다. ShotGrid 없이 시작하는 경우보다 시간이 약간 더 오래 걸리는 것은 당연하겠지만, 용납할 수 없을 정도로 오래 걸리는 경우도 있을 수 있습니다. 소프트웨어에 따라 다르지만 대개 1분 안에 시작되어야 합니다. 소프트웨어를 시작하는 데는 많은 프로세스가 관련되기 때문에 이 문제를 진단하는 것은 더 어려울 수 있습니다.

진단

먼저, 이 문제가 어떠한 상황에서 발생하는지 파악해야 합니다.

1. ShotGrid 없이 시작할 때도 속도가 느립니까? - 뻔한 이야기일 수 있지만 ShotGrid와 함께 시작할 때만 문제가 발생하는지 확인하는 것이 좋습니다.
2. 시작 방법에 상관없이 동일하게 속도가 느립니까? 즉, SG 데스크톱에서 시작할 때나, 브라우저 통합을 사용하여 SG 사이트에서 시작할 때 느린 속도에 차이가 없습니까? - ShotGrid 사이트에서 시작할 때는 속도가 느리지만 SG 데스크톱에서 시작할 때는 속도가 느리지 않은 경우 브라우저 통합 문제이거나 디스크에 폴더를 생성하는 것과 관련한 문제가 있음을 나타낼 수 있습니다. 프로젝트 이외의 컨텍스트에서 시작하는 경우 디스크에 추가로 폴더를 생성해 보면 시간이 어디서 많이 걸리는지 확인할 수 있습니다. 소프트웨어가 시작될 때마다 필요한 폴더가 존재하는지 확인한다는 사실도 주목해야 합니다.
3. 모든 프로젝트에서 이 문제가 발생합니까? - 그렇지 않다면 구성이 설정된 방식과 관련하여 문제가 있을 가능성이 큽니다.
4. 하루 중 특정 시간에만 이 문제가 발생합니까? - 그렇다면 하루 중 특정 시간에 서버 사용량이 많은 경우와 같이 인프라에 대한 수요가 높다는 것을 나타낼 수 있습니다.
5. 모든 시스템/OS에서 이 문제가 발생합니까? - 특정 시스템에서만 속도가 느린 경우 툴킷 외부에 문제의 원인이 있을 가능성이 있습니다. 이 경우, 먼저 해당 시스템에서 툴킷 캐시를 지우는 것이 좋습니다. OS마다 제공되는 소프트웨어 버전 및 Python 패키지가 다르며, 특정 빌드에서 성능 문제가 발생하는 경우가 있을 수 있습니다. 특히, Samba(SMB) 공유를 사용하는 Windows에서 성능 문제를 확인했습니다. 이러한 문제에 대한 수정 사항은 없지만, Windows를 사용하는 경우 유의하시기 바랍니다. 문제가 특정 OS, Python 패키지 또는 소프트웨어 버전으로 국한된다고 판단되는 경우 Shotgun 지원 팀에서 추가적인 조사를 진행할 수 있도록 알려주시기 바랍니다.
6. 모든 사용자에게 이 문제가 발생합니까? - 위와 마찬가지로 동일한 시스템의 다른 사용자에게는 이 문제가 발생하지 않을 수 있습니다. 이 경우, 사용자의 로컬 ShotGrid 캐시를 먼저 지우십시오. 또한, 정상적으로 프로덕션 환경에서 사용할 때 디버그 로깅이 활성화되지 않은 것을 확인하십시오. 활성화할 경우 성능에 영향을 미치게 됩니다.
7. 느린 시작 문제가 특정 앱/소프트웨어에만 국한됩니까? 아니면 모든 앱/소프트웨어가 비정상적으로 느리게 시작됩니까? - 특정 소프트웨어만 느리게 시작되는 경우 구성 문제가 있을 수 있습니다. 성능에 영향을 미칠 수 있는 커스텀 후크가 시작 전이나 후에 실행되도록 설정되었는지 확인하는 것이 좋습니다. 시작에 사용되는 일반 후크는 before_app_launch.py, app_launch.py이며 코어 후크는 engine_init.py입니다. 최신 버전의 소프트웨어가 출시될 때 Shotgun 통합이 갑자기 훨씬 더 느리게 시작되는 등의 문제가 발생할 수도 있습니다. 이러한 경우 지원 팀에 문의하여 이에 대해 알고 있는지, 그리고 알려진 수정 사항이 있는지 확인해야 합니다. 이때 현재 사용 중인 소프트웨어의 버전 번호(해당하는 경우 패치/서비스 팩 포함)와 현재 실행 중인 tk 엔진 및 코어의 버전을 알려 주십시오.

문제가 시작 전에 발생합니까? 아니면 시작 후에 발생합니까?

위의 방법으로 문제의 원인이 좁혀지지 않을 경우 다음 단계로 시작 프로세스가 언제 느려지는지 파악해야 합니다. 툴킷을 통해 소프트웨어를 시작하는 경우 대개 두 단계 프로세스로 간추릴 수 있습니다.

첫 번째 단계에서는 소프트웨어를 시작하는 데 필요한 정보를 수집하고 컨텍스트에서 폴더를 자동으로 생성한 후 소프트웨어를 실제로 시작하는 등의 초기 작업을 수행합니다. 소프트웨어가 시작된 후 두 번째 단계에서는 툴킷 통합을 시작합니다.

일반적으로, 성능 문제가 프로세스의 첫 번째 단계에서 발생하는지 아니면 두 번째 단계에서 발생하는지는 로그를 확인하지 않고도 알 수 있습니다.

• 소프트웨어의 시작 화면이 시작하는 데 오래 걸리는 경우 첫 번째 단계에 문제가 있을 가능성이 큽니다.
• 소프트웨어가 시작 과정의 초반에는 상대적으로 속도가 빨랐다가 초기화가 완료되고 ShotGrid 메뉴가 표시된 후 느려지는지 확인하십시오. 이 경우 두 번째 단계에 문제가 있는 것입니다.

이를 파악하고 나면 로그에서 무엇을 확인해야 할지 알 수 있습니다.

로그 확인

이제 이 문제가 시작의 첫 번째 단계에서 발생했는지 아니면 두 번째 단계에서 발생했는지 파악되었을 것이므로 이에 따라 로그에서 확인할 부분을 결정할 수 있습니다. 로그는 엔진별로 나뉘어 있으므로 문제가 시작 전 단계에서 발생한 경우 SG 데스크톱에서 시작했는지 아니면 SG 사이트에서 시작했는지에 따라 각각 tk-desktop.log 또는 tk-ShotGrid.log를 확인해야 합니다.

다음으로 수행해야 하는 작업은 디버그 로깅을 활성화하는 것입니다.

디버그 로깅을 활성화하고 나면 기존 로그를 지운 후 시작 프로세스를 다시 실행해야 합니다. 그런 후에는 로그의 타임스탬프를 조사하여 시간이 갑자기 건너뛴 부분을 확인할 수 있습니다.

예를 들어, 다음은 폴더 생성 중에 시간이 5초 이후로 건너뛴 행을 보여줍니다.

2019-05-01 11:27:56,835 [82801 DEBUG sgtk.core.path_cache] Path cache syncing not necessary - local folders already up to date!
2019-05-01 11:28:01,847 [82801 INFO sgtk.env.asset.tk-shotgun.tk-shotgun-folders] 1 Asset processed - Processed 66 folders on disk.

시간이 건너뛴 부분을 찾고 나면 해당 로그 행에서 폴더를 생성 중이었는지 아니면 ShotGrid에 연결 중이었는지와 같이 해당 단계에서 어떠한 작업이 수행 중이었는지 확인할 수 있습니다.

로그를 읽는 것이 어렵거나 내용이 이해되지 않는 경우에는 지원 팀에 문의하여 도움을 받으십시오.

소프트웨어의 실행 속도가 느려지는 일반적인 원인

File Open, File Save 또는 Loader 앱의 속도가 느립니까?

가장 먼저 문제가 있는 앱에서 어느 부분이 느려지는지 확인해야 합니다.

• 앱을 시작할 때 속도가 느립니까? 아니면 탭을 탐색할 때 속도가 느립니까?
  • 앱이 너무 많은 정보를 표시하도록 구성되어 있는 것일 수 있습니다. 이 경우 목록에서 불필요한 엔티티를 필터링하여 제외하도록 내 태스크(My Tasks) 탭 및 기타 탭을 구성할 수 있습니다. 예를 들어, 대기 중(hld) 또는 최종(fin)과 같은 특정 상태의 태스크를 필터링하여 제외할 수 있습니다. 이렇게 하면 성능이 향상되고 아티스트는 중요한 정보만 볼 수 있게 됩니다. Loader 앱 및 Workfiles 앱에서 모두 필터링이 가능합니다. 단, Workfiles에는 현재 필터링에 대한 특정 섹션이 없으며, 계층 설정을 통해 필터링을 적용할 수 있습니다.
  • File Open 앱에서는 계층의 하위 항목이 확장될 때까지 하위 항목의 로드를 유예하도록 구성할 수 있습니다. 현재, 기본 구성 설정이지만 이전 구성을 사용하는 경우에는 이 설정을 사용하도록 전환할 수 있습니다.
  • 디버그 로깅이 활성화되지 않은 것을 확인하십시오. 활성화되어 있으면 추가 입출력이 많이 발생하며, 이에 따라 속도가 느려질 수 있습니다. 이 앱은 많은 디버깅 출력을 포함합니다.
• 새 파일을 열거나 저장하거나 생성할 때 속도가 느립니까?
  • 씬 작업 또는 액션 후크를 인계받았는지 확인하고 이러한 기능과 관련하여 속도를 저하시킬 수 있는 커스텀 동작이 있는지 확인합니다.
  • 파일을 만들거나 저장할 때 Workfiles는 컨텍스트에 필요한 모든 폴더가 생성되었는지 확인합니다. 폴더 생성은 성능 문제가 흔히 발생하는 부분입니다.

폴더 생성 속도가 느림

폴더 생성은 여러 가지 부분으로 구성되기 때문에 문제가 발생하는 경우 프로세스 속도 저하가 나타날 수 있습니다.

폴더 생성 과정은 다음과 같습니다.

• 로컬 경로 캐시를 동기화합니다.
• 구성 스키마를 읽어옵니다.
• 특정 컨텍스트에 따라 만들어야 하는 경로 목록을 생성합니다.
• 로컬로 저장된 경로 레지스트리와 비교하여 경로를 확인합니다.
• 아직 등록되지 않은 경우 SG 사이트와 로컬 모두에 새 경로를 등록하려고 시도합니다.
• 폴더의 등록 여부에 상관없이 폴더가 실제로 디스크에 있는지 확인하고 없는 경우 폴더를 생성합니다.

정리하면, 폴더 생성 시 로컬 데이터베이스에 기록하고 SG 사이트와 통신하는 외에도 디스크에서 상당한 양의 입출력이 발생할 수 있습니다.

입출력량 문제 해결

저장 장치가 대량의 작은 읽기-쓰기 작업을 처리하기에 느리거나 비효율적일 가능성이 있으므로 인프라를 개선하기 위해 수행하는 작업이라면 무엇이든 폴더 생성 속도를 높이는 데 도움이 됩니다. 하지만, 최대한 부담을 줄이기 위해 툴킷 구성 측면에서 수행할 수 있는 단계가 있습니다.

첫 번째 단계는 해당 컨텍스트와 작업 환경에 중요한 폴더만 생성되도록 폴더를 제한하는 것입니다. 예를 들어, Maya의 샷에 대한 태스크를 진행하는 경우 해당하는 샷과 소프트웨어에 대한 폴더만 확인하고 생성하는 것이 바람직합니다.

기본적으로, 작업물을 저장하고 게시하는 데 필요한 최소한의 폴더만 생성하는 것이 좋습니다.

상위 폴더와 동시에 생성

스키마 폴더에 적용될 수 있는 create_with_parent 설정이 있습니다. 이 설정을 True로 설정하면 폴더와 상위 폴더가 동시에 생성됩니다. 이 설정을 True로 설정하면 대량 폴더에 대해 확인 및 생성 작업이 수행되지 않도록 주의해야 합니다.

예시

시퀀스/샷 폴더 계층이 있고 샷 폴더를 상위 폴더인 시퀀스 폴더와 함께 생성하도록 설정한 경우 시퀀스 폴더가 생성될 때마다 연결된 모든 샷에 대해 확인 작업이 수행되고 이에 대한 폴더가 생성됩니다.

때로는 이러한 동작이 편리할 수 있지만 이로 인해 더 많은 폴더가 확인 작업을 거쳐 동시에 생성되는 문제가 발생합니다. 이러한 경우, 샷에 대한 태스크의 작업 파일에 새 파일을 생성하려고 하면 샷의 상위 폴더인 시퀀스 폴더의 생성 작업이 트리거되고, 이에 따라 현재 작업하는 샷만이 아니라 모든 하위 폴더인 샷 폴더가 생성됩니다.

생성 유예

defer_creation 설정을 사용하면 특정 엔진이 실행 중일 때에만 폴더 생성이 발생하도록 제한하여 폴더가 생성되는 경우를 세부적으로 조정할 수 있습니다. 커스텀 이름을 사용하여 sgtk API를 통해 이에 대한 생성 작업을 트리거할 수도 있습니다.

예시

게시 단계에서만 생성해야 하는 폴더가 여러 개 있을 수 있습니다. 이 경우, maya_publish의 유예 키워드로 커스텀을 설정한 후 API를 사용하여 이 키워드를 엔진 이름으로 사용하여 폴더를 만들 수 있습니다. 스키마 내 폴더는 다음과 같습니다.

# the type of dynamic content
type: "static"
# defer creation and only create this folder when Photoshop starts
defer_creation: "publish"

그런 다음, 다음과 같은 스크립트를 사용하여 폴더를 만듭니다.

sgtk.create_filesystem_structure(entity["type"], entity["id"], engine="publish")

확장된 예시

폴더를 유예하는 방법에서 더 나아가 프로젝트의 루트에 동적이 아닌 폴더가 여러 개 있는 경우 일반적으로 한 번만 생성하면 됩니다. 예를 들어, 기본 구성 스키마의 루트에 있는 “editorial” 및 “reference” 폴더는 프로젝트 시작 시 한 번만 생성하면 되지만, 기본적으로 폴더 생성 작업 시 항상 이 폴더의 존재 여부를 확인합니다.

이 폴더에 대해 yml 파일을 생성하여 이를 제한할 수 있습니다. 이 yml 파일에서는 폴더 생성이 특정 엔진에서 실행되거나 유예 키워드가 전달되는 경우에만 폴더가 생성되도록 유예 키워드를 설정할 수 있습니다. 유예 키워드를 tk-shell로 설정한 후 tank folders와 같은 tank 명령을 통해 폴더 생성을 실행할 수 있습니다.

그러면 폴더 생성이 tank 명령을 통해 실행되는 경우에만 폴더가 생성됩니다. 이 작업은 툴킷 관리자가 처음으로 프로젝트를 설정할 때 수행할 수 있습니다. 또는, 위의 예시와 같은 커스텀 키워드를 사용하여 폴더 생성을 실행하는 간단한 스크립트를 작성할 수도 있습니다.

폴더 등록

향후 컨텍스트를 조회할 때 경로가 사용될 수 있도록 폴더 생성 프로세스 중에 폴더가 등록됩니다. 위에서 설명한 대로 이 프로세스 부분을 실행하기 위해서는 레지스트리가 저장된 중앙 위치인 ShotGrid 사이트와의 통신이 필요합니다. 하지만, 도구에서 더욱 신속하게 조회할 수 있도록 이러한 레지스트리는 로컬로도 캐시됩니다.

SQLite 데이터베이스

로컬 경로 캐시에서는 데이터를 저장하기 위해 SQLite 데이터베이스를 사용합니다. 데이터베이스가 네트워크 저장소에 저장되는 경우 데이터베이스 읽기 및 쓰기 관련 성능이 심각한 영향을 받을 수 있습니다.

초기 동기화

많은 폴더가 등록된 프로젝트에 대해 로컬 캐시를 처음부터 생성해야 하는 경우가 있을 수 있습니다(예: 이미 진행 중인 프로젝트에 새 사용자가 참여하는 경우). 이 프로세스는 아주 긴 시간이 걸릴 수 있지만, 다행인 점은 이러한 현상이 해당 프로젝트에 대해 한 번만 발생한다는 것입니다.

후속 동기화에서는 로컬 캐시와 사이트 레지스트리 사이의 차이점만 가져옵니다. 사용자의 프로젝트 작업 빈도가 낮고 세션 간에 많은 폴더가 생성되는 경우 모든 항목이 캐시되는 동안 대기하는 시간이 길어질 수 있습니다.

사용자가 이러한 문제에 사용하는 것으로 확인된 한 가지 방법은 최신 버전의 로컬 캐시를 사용자 시스템으로 전송하는 것입니다.

이 업데이트 프로세스는 코어 후크 cache_location.py를 사용하여 자동으로 수행될 수 있습니다. 위치를 변경하는 대신 이 후크를 사용하여 캐시 위치를 설정할 수 있으며, 이 후크를 사용하여 비용이 많이 드는 전체 동기화를 수행할 필요 없이 중앙 위치의 path_cache.db 파일을 사용자의 기본 위치로 복사할 수 있습니다.

이렇게 중앙에 저장된 경로 캐시는 작업자의 캐시에서 수동으로 복사하거나 정기적으로 이러한 캐시를 전송하는 스크립트를 작성하여 주기적으로 업데이트할 수 있습니다.