ArcMapのレイヤーは何層ですか？

私は職場でCitrix仮想ソフトウェア接続を使用してArcGISで作業しています。時々非常に遅く、作業中のMXDに変更を加えることなく、ArcMapが1分で妥当な速度で動作し、次の1分でクロールが遅くなる場合があります。IT部門は、問題の原因がマップ内のレイヤーが多すぎると考えています。問題は、ハードウェアまたはソフトウェアの構成、または最初にCitrixを使用しているという事実だけかもしれません。

とにかく、編集に使用する標準MXDには、57個のSDEレイヤーと2個のファイルジオデータベースレイヤーがあります。大部分は、編集のためにチェックする必要があるレイヤーです。パイプライン建設プロジェクトごとにデータを編集およびQCする必要があるため、各レイヤーにデータが存在するかどうかを確認する必要があります。いくつかのレイヤーだけがベースマップレイヤーであり、定期的に参照する必要があります。

IT部門は、使用しているレイヤーの数を10に減らすことを望んでいます。理想的な世界では、これで問題ありません。しかし、現実の世界では、実際的ではありません。このような提案では、特定のプロジェクトの編集タスクを実行するために、5つの異なるMXDを使用する必要があります。私は10層のみを使用して実験しましたが、それは厳しく制限されています。他のデータとの関係でデータのコンテキストが不足しており、すべてのデータが更新されたことを確認するために、同じ領域を何度も再確認する必要があります。これはすべて、パフォーマンスのわずかな向上と、編集中のクラッシュの数のわずかな減少にすぎません。

だから私は尋ねなければなりません、理想的な数の層がありますか？多すぎますか？

以前はまったく同じ環境（まったく同じ環境）で作業していました。ベンチマークテストを行ったことはありませんが、これに対する私の感覚では、プロジェクト内のレイヤーの数はそれ自体ではあまり効果がありません。

私の経験では、ラベル付けとフィーチャの数は、レイヤーの数よりもはるかに大きな問題です（特に多くのレイヤーがオフになっている場合）。以前はラベル付けツールバーを有効にしていたため、ラベル付けを一時停止することがよくありました。それは信じられないほどパフォーマンスを改善するようです。TOCでチェックされていないレイヤーがプロジェクトに含まれていても、パフォーマンスに悪影響はないようです。私は間違っている可能性がありますが、IMOのレイヤー数は一種のニシンです。

ラベル付けを一時停止する（これが最も便利な方法です）か、機能のラベル付けを完全にオフにすることをお勧めします。

最初に、ESRIがまとめたガイドであるCitrix XenAppとArcGISを使用したベストプラクティスを確認します。

以前のクライアントの場合、ESRIとCitrix環境を使用して、かなりのパフォーマンスのトラブルシューティングを行いました。これらの会話のハイライトは次のとおりです。

狭いエリアで編集を行うことを想定しています（かなり近くでズーム）。そのレベルの近くまでズームインするまで、ほとんどのレイヤーをオフにするようにマップを設定すると、パフォーマンスが向上します。

MXD Doctorは、問題を引き起こしている可能性のあるアイテムを確認するために実行する必要がある別のツールです。

ArcGISがミラーリングまたはストリーミングだけでなく、Citrixサーバー自体に実際にインストールされていることを確認してください。

私たちの最大のスローダウンはプリンターが原因であると思われました。プリンター機能を無効にすると（および自動接続）、より速く接続し、遅延時間が少なくなりました（詳細については、このESRIニュースレターを参照してください）。ただし、これにより、最初にマップをpdfにエクスポートしてから印刷する必要がありましたが、作業の90％が編集と分析であるため、誰も気にしなかったようです。

59層は非常に多く、それをノックダウンできるなら、それは助けになるでしょう。@jbchurchillが示唆するように、ラベルを見てください。また、カスタムシンボル体系も確認する必要があります。

citrixを含む、GISシステムのパフォーマンスのトラブルシューティングの経験があります。問題はどこにでもあり、おそらく要因の組み合わせになります。ポインターについては、Esri担当者にお問い合わせください。

これを読むことをお勧めします：http : //www.wiki.gis.com/wiki/index.php/Software_Performance#Use_MXDPerfStat_to_measure_display_complexity

ラベル付け、フィーチャキャッシュおよびキャッシュされたベースマップの使用はすべて良い習慣です。

また、perfqanalyzer https://blogs.esri.com/esri/supportcenter/2014/02/03/calibrating-arcgis-performance-with-perfqanalyzer-new-build-と呼ばれる、よりユーザーフレンドリーな新しいツールを試すこともできますダウンロード可能/

私は、MXDをデータのほとんどのファイルサーバーとして使用しているという悪い習慣のある会社で働いているという点で、飛び込んでみようと思いました。アイデアを提供するために、1000層以上のMXDがあります。地図を開くのにレイヤあたり650ミリ秒を推奨するコンサルタントと協力しました。それは良くなく、間違いなく最適ではありませんが、私はあなたにも苦しむ人がいることを知らせたいと思いました！

私たちは最近EGDBに移行しましたが、それはパフォーマンスに大きな打撃を与えました。機能のキャッシュを有効にすると、EGDBに適切なメンテナンス（分析、インデックス、圧縮など）を確保することと大きく異なることがわかりました。

2番目のMXD医師は、データに接続している古いパスをすべて削除し、テンプレートマップを削除してみます。MXD perf statは強力なツールであり、cmdスキルが不足しているため、半分しか使用していないと感じています。