ある環境から別の環境にアセットを公開しようとしていました。それはほとんど非常に遅く、それ以上進んでいませんでした。何が問題であるかを示唆する機関はありますか？
4 に答える
1
アセットをセグメント化して、小さなグループで公開してみてください
于 2012-01-28T03:31:14.540 に答える
1
場合によっては、バッチ全体を停止させる原因となる資産を見つけることになります。これが、遅い公開をセグメント化することが問題を絞り込むのに役立つ理由です。また、ターゲットの宛先にチェックアウトされているアセットがあるかどうかも確認してください。
于 2012-01-28T03:36:31.107 に答える
1
確認事項がいくつかあります
パブリッシュ先の構成で VERBOSE=TRUE を設定して、UI がより詳細なログを書き込むようにすることができます。ターゲットへのアセットの移動であるか、ターゲットでのキャッシュ フラッシュ/潜在的な再構築であるかにかかわらず、何が遅いのかを正確に把握することが重要です。
ソースとターゲットの futuretense.txt をチェックして、明らかなエラーや奇妙なメッセージがないか確認してください。そこに何も表示されていない場合は、ロギングが抑制されている可能性があります。ほとんどのロガーはデフォルトで INFO レベルになっているはずです。それでも何も表示されない場合は、com.fatwire.logging.cs=DEBUG を設定して再試行してください。
一般的に言えば、これが本番システムであり、パブリッシュされるアセットの数がそれほど多くない場合、キャッシュ フラッシュに最も時間が費やされます。また、そうするように構成されている場合は、キャッシュを再生成します。詳細なパブリッシュ ログは、フラッシュされている量を示します。
ログを調べても速度低下の原因を特定できない場合は、パブリッシュ中に定期的にスレッド ダンプ (ソースとターゲット) を取得して、内部で何が起こっているかを確認することを検討してください。共有ディスクなどのリソースでのシステムの待機が遅い可能性があります (一般的な問題)。
フィル
于 2012-02-06T00:25:22.363 に答える
0
理解を深めるには、公開プロセスがどの段階で停止しているかを調べる必要があります。ご存知のように、パブリッシュのプロセスは 5 つのステップで構成され、最初の 2 つ (データ収集とシリアル化) はソースで行われ、3 つ目 (データ転送) はソースと宛先の間で行われ、最後の 2 つ (デシリアライゼーションとキャッシュ クリア) が行われます。配達時に発生します。
私が遭遇した奇妙な状況の 1 つは、リアルタイム パブリッシュのたびに Locale ツリーを更新しようとしていたデシリアライゼーション ステップです。当時の Fatwire サポートは、&PUBLISHLOCALETREE=false を追加することを提案しました。これにより、パブリッシュのパフォーマンスが大幅に向上しました。繰り返しますが、これはサイトでロケール/翻訳を使用している場合にのみ適用されます。
于 2013-03-12T01:51:41.890 に答える