Toolkit の使用速度が低下することがあります。速度が低下する理由はさまざまです。サーバ速度やインターネット接続などのクライアント側インフラストラクチャの問題、Toolkit や Flow Production Tracking が高いパフォーマンスで実行されるように設定されていない設定ベースの問題、さらに最適化を行う余地があるコード上の問題などがあります。
次に、チェック項目のクイック リストを示します。これらのチェック項目については、以下で詳細に説明します。
Flow Production Tracking_HOME 環境変数を設定します。次に、適切な方法と、速度が低下する一般的なシナリオを示します。このリストは、まだすべてを網羅するものではありません。新しいパターンが見つかったときに、適宜追加されます。このガイドを参照しても、現在発生している問題の根本的な原因が見つからない場合は、サポート チケットを送信してください。担当チームがサポートします。
目次:
Flow Production Tracking Toolkit はデータをユーザのホーム ディレクトリにキャッシュします。このキャッシュには、さまざまな SQLite データベース、およびキャッシュされたアプリと設定を含めることができます。通常、ユーザのホーム ディレクトリはマシンのローカル ハード ドライブに保存されますが、スタジオでは、ネットワーク上のストレージにこれらをリダイレクトすることが一般的に行われています。この方法の場合、パフォーマンスが低下することがあります。特に大きな影響を受けるのが、ブラウザの統合やフォルダの作成/検索に使用される SQLite データベースです。
ユーザ ディレクトリがサーバの場所に保存されている場合は、Flow Production Tracking_HOME 環境変数を使用して Flow Production Tracking Toolkit キャッシュのパスを変更することをお勧めします。Flow Production Tracking_HOME 環境変数は、データおよびその他の項目の高速検索に使用されるバンドル キャッシュ、サムネイル、SQLite データベースなど、Toolkit がさまざまなデータをキャッシュする場所を設定する際に使用されます。
Flow Production Tracking Toolkit でデバッグ ログを有効にして、さまざまなプロセスから詳細な出力を取得することができます。このようにすると、問題を診断するときに非常に便利です。ただし、デバッグ設定は、通常の日常的な用途のときは有効にならないように設計されています。ログの出力量が増えると、パフォーマンスが大幅に低下することがあります。
パフォーマンスの問題が発生した場合、特に、特定のマシンやユーザに限定された問題が発生する場合は、最初にデバッグ ログが有効になっていないことを確認してください。
パフォーマンスの問題が発生した場合は、コア、アプリ、エンジン、およびフレームワークが最新状態になっていることを確認します。新しいリリースで修正プログラムや最適化が既に提供されていることがあります。
高度な Toolkit 設定を行う場合は、一元管理設定と分散設定の 2 つの異なる方法があります。主な違いは、一元管理設定は通常、スタジオのネットワーク ストレージに配置されていて、すべてのユーザがアクセスできることです。一方、分散設定は一般にクラウド内に保存されていて、ユーザ単位でローカルにキャッシュされます。
この 2 つの方法の違いはパフォーマンス以外にもありますが、パフォーマンスに関しては長所と短所の両面があります。次の表に、純粋にパフォーマンスの観点から見た長所と短所を示します。
| 利点 | 欠点 | |
|---|---|---|
| 一元管理設定 | - 初期設定プロセスが完了すると、必要なすべてのものが既にダウンロードされていて、すべてのユーザが使用できる状態になっています。 - 将来の更新は、一元管理された場所に 1 回ダウンロードするだけで済みます。 |
- 一元管理設定は通常、ネットワーク ストレージに保存されるため、Toolkit の一般的な用途のときにパフォーマンスが低下することがあります。 - Toolkit の設定には多数の小さなファイルが含まれています。多数の小さなファイルにメタデータ操作を行うと、処理速度が大幅に低下し、サーバの負荷が増大することがあります。また、Toolkit を使用する読み取り操作と、サーバの一般的な用途における読み取り操作の負荷が増大すると、設定をすばやく読み取ることができなくなって、Toolkit のパフォーマンスが低下することがあります。 |
| 分散設定 | - キャッシュされたアプリ、エンジン、フレームワーク、およびコアは、他のローカルにキャッシュされた設定と共有できるような方法で保存されます。つまり、複数のプロジェクトを今後ロードするときに、これらが同じ依存関係を共有していれば、キャッシュ速度が上がる可能性があります。 - これらはローカル ハード ドライブ上のユーザ キャッシュに保存されるため、通常はサーバ速度よりもパフォーマンスが向上します。つまり、最初のキャッシュ以降のパフォーマンスは一元管理設定よりも高くなります。 |
- 分散設定はユーザ単位でローカルにキャッシュする必要があります。この操作を行うには、通常、設定、および必要なすべてのアプリ、エンジン、フレームワーク、コアをダウンロードします。 - このプロセスはシーンの背後でシームレスに行われますが、これらをダウンロードする初期コストがかかります。 - 新しいバージョンの依存関係を指定するように設定を更新するたびに、設定と新しい依存関係の両方をキャッシュする必要があります。 |
手短に言えば、ストレージは低速だが妥当な速度のインターネット接続を使用している場合は、分散設定が最適な設定になる可能性がありますが、サーバ ストレージのパフォーマンスが高く、インターネットのパフォーマンスが低い場合は、一元管理設定が適している可能性があります。
分散設定に興味はあっても、マシンごとに依存関係をダウンロードすることについて懸念を抱いている場合は、バンドル キャッシュのみを一元管理して、すべてのユーザで共有することができます。
分散設定を使用している場合、ユーザはキャッシュ内にまだ保存されていないデータのみダウンロードする必要があります。ユーザがデータをダウンロードすると、他のユーザもそのデータを利用できるようになります。これを実現するには、各マシンで共有場所を参照するようにFlow Production Tracking_BUNDLE_CACHE_PATH 環境変数を設定します。
Maya、Nuke、Houdini などのソフトウェアを起動するときに、Flow Production Tracking を使用しない場合に比べて起動時間が長くなることがあります。Flow Production Tracking を使用しない場合に比べて起動時間が長くなるのは通常のことですが、これらの時間が許容できないレベルまで増大することがあります(ソフトウェアによって異なりますが、通常は起動時間が 1 分未満であると予測しています)。ソフトウェアの起動には多くのプロセスが関係しているため、この問題を診断するのは面倒なことがあります。
最初に行う必要があるのは、この問題が発生する場合の条件を特定することです。
before_app_launch.py、app_launch.py、およびコア フック engine_init.pyです。ときどき、新しいバージョンのソフトウェアがリリースされ、Toolkit の統合の起動速度が突然大幅に低下することもあります。この場合は、サポートに問い合わせて、この問題が認識されているかどうか、および既知の修正プログラムがあるかどうかを確認する必要があります。使用しているソフトウェア(パッチ/サービス パックが適用可能な場合は、これらを含む)のバージョン番号、および実行している Toolkit エンジンとコアのバージョンをお知らせください。上記の手順を行っても原因を絞り込むことができなかった場合は、次に、起動プロセスのどの段階で速度が低下するのかを確認します。Toolkit を介してソフトウェアを起動している場合は、一般に起動プロセスを 2 段階のプロセスにまとめることができます。
最初の手順では、いくつかの初期操作を実行します。たとえば、ソフトウェアの起動に必要な情報を収集したり、コンテキストからフォルダを自動的に作成し、その後でソフトウェアを実際に起動したりします。次に、起動プロセスの 2 番目の手順が行われ、ソフトウェアの起動後に Toolkit の統合が起動されます。
通常は、ログを調べなくても、プロセスの最初の手順と 2 番目の手順のどちらでパフォーマンスの問題が発生しているのかを確認できます。
この情報を把握しておくと、この次の作業でログを確認する際に役立ちます。
起動の最初の手順または 2 番目の手順のどちらで問題が発生しているのかを確認したら、調査対象のログを特定することができます。ログはエンジンごとに分かれているため、問題が起動前の段階で発生している可能性がある場合は、SG Desktop から起動しているのか、それとも SG サイトから起動しているのかに応じて、tk-desktop.log または tk-Flow Production Tracking.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.時間が急に変化している場所を特定したら、そのログの行を調べると、その段階で何が起こっていたのかを把握することができます。たとえば、フォルダの作成中や、Flow Production Tracking の接続の取得中に問題が発生していることがあります。
ただし、ログを参照するのは面倒な作業であり、内容に意味があるとは限らないため、サポートに問い合わせて、この作業のサポートを依頼することができます。
| インターネットの速度低下 | Toolkit のほぼあらゆる使用状況において Flow Production Tracking サイトに接続して通信する必要がありますが、インターネットの速度が低下すると、この動作が影響を受けます。この場合は通常、ソフトウェアの起動だけでなく、他の状況においても、速度に関する問題が発生します。ただし、接続速度が低下するのではなく、接続が不安定になる場合は、起動時にパフォーマンスの問題が生じる可能性があります(大量の Flow Production Tracking 通信がプロセスを通して行われるためです)。 |
| サーバ アクセス速度の低下 | この問題は確実に起動時間に影響します。一元管理設定を使用している(設定が中央サーバに保存されている)場合は、設定ファイルを読み取るときに大量の I/O が発生することがあります。特に、ソフトウェアを起動すると、起動時の状況に応じてフォルダが作成されます。つまり、フォルダが作成されているかどうかが確認され、作成されていなければ作成されます。 |
| フォルダの作成 | 上記のように、フォルダ作成が速度低下の一般的な原因になることがあります。詳細については、以下のフォルダ作成時のパフォーマンスに関するトラブルシューティングを参照してください。 |
最初に、問題となっているアプリの速度が低下する状況を絞り込んで、特定します。
hld)や[最終] (Final) (fin)などの特定のステータスを持つタスクを除外できます。このようにすると、パフォーマンスが向上するだけでなく、アーティストは自分が必要としている情報のみを表示することができます。Loader アプリと Workfiles アプリの両方を除外できます。現在のところ、Workfiles にはフィルタに関する特定のドキュメント セクションはありませんが、階層設定時にフィルタを適用することができます。フォルダの作成は多くの要素で構成されていて、問題が発生したときに処理速度が低下する原因となることがあります。
フォルダの作成では、次の処理が行われます。
つまり、フォルダを作成すると、ディスクの I/O 使用量が大幅に増えるとともに、ローカル データベースへの書き込みと SG サイトとの通信が必要になります。
多数の小規模な読み取り/書き込み操作を処理するときに、ストレージの速度や効率が低下することがあるため、インフラストラクチャの効率化に役立つ手順を行うと、フォルダ作成の処理時間を短縮できます。ただし、できるだけ負荷を軽減するために Toolkit 設定側で試行できる手順があります。
最初に行うのは、この状況、および作業中の環境にとって重要なフォルダのみが作成されるように制限することです。たとえば、Maya でタスクやショットを操作している場合は、特定のショットおよびソフトウェアのフォルダのみを確認して、作成することが理想的です。
基本的に、作品を保存およびパブリッシュするのに最低限必要なフォルダを作成するようにします。
スキーマ フォルダに適用できるcreate_with_parent 設定があります。これを true に設定すると、フォルダが親フォルダであるときにそのフォルダが作成されるようになります。この設定を 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")詳細な例
フォルダを遅延することにした場合、プロジェクトのルートに動的でないフォルダが複数あれば、通常はこれらを 1 回のみ作成する必要があります。たとえば、「editorial」および「reference」フォルダが既定の設定スキーマのルートにある場合は、プロジェクトの開始時に一度だけ作成する必要がありますが、既定ではフォルダの作成時に毎回フォルダの有無が確認されます。
これを制限するには、yml ファイルを作成して defer キーワードを設定し、フォルダの作成が特定のエンジンで実行された場合やキーワードが渡された場合にのみ作成されるようにします。遅延キーワードを tk-shell に設定して、tank folders のような tank コマンドを使用してフォルダ作成を実行することができます。
これは、これらのフォルダ作成が tank コマンドを介して実行された場合に限り実行されることを意味します。tank コマンドは、プロジェクトを初めて設定するときに Toolkit 管理者が実行することができます。また、上の例のようなカスタム キーワードを使用してフォルダ作成を実行する、小規模なスクリプトを記述することもできます
フォルダの作成中にフォルダが登録されるため、後でコンテキストを調べる際に登録されたパスを使用することができます。上記のように、この処理中に、レジストリが保存されている一元的な場所である Flow Production Tracking サイトと通信する必要があります。ただし、ツールによる高速検索を有効にするために、これらのレジストリもローカルにキャッシュされます。
ローカルなパス キャッシュは SQLite データベースを使用してデータを保存します。ネットワーク上のストレージにデータベースが保存されている場合は、データベースに対する読み取りおよび書き込みのパフォーマンスが大幅に低下することがあります。
プロジェクトに多数のフォルダが登録されている場合は(進行中のプロジェクトに新しいユーザが参加する場合など)、状況に応じて、ローカル キャッシュをゼロから生成しなければならないことがあります。この処理には非常に長い時間がかかることがあるため、このようなプロジェクトにはこの処理が 1 回だけ行われるように効率化されました。
以降の同期では、ローカル キャッシュとサイトのレジストリの間の差分のみが取得されます。ユーザがプロジェクトを操作する頻度が少なく、セッションの合間に多数のフォルダが作成されている場合は、すべてのデータをキャッシュする間の待ち時間が非常に長くなることがあります。
この場合にユーザが使用してきた方法の 1 つは、ローカル キャッシュの最新と見なされるバージョンをユーザのマシンに転送することでした。
この方法は、プロジェクトにきわめて多数のフォルダが作成されている場合に限って必要となります。
この更新プロセスは、コア フック cache_location.py を使用して自動的に実行できます。このフックを使用してキャッシュの場所を設定できますが、場所を変更しなくても、このフックを使用して path_cache.db ファイルの特定のバージョンを一元管理された場所からユーザの既定の場所にコピーして、負担のかかる完全同期を不要にすることができます。
一元的に保存されたパス キャッシュを定期的に更新するには、他のユーザのキャッシュから手動でコピーすることができますが、通常はスクリプトを使用して定期的に転送します。
cache_location.py フックを使用するとキャッシュの場所を設定できますが、すべてのユーザに単一の場所を指定する設定は避けてください。1 つまたは複数のプロセッサがデータベースを同時に編集しようとすると、データベースがロックされることがあります。