タグ付けされた質問 「performance」

パフォーマンスは、コンピューティングシステムがリソースをいかに効率的に使用するかに関係します。

2
非常に遅いArcSDE 10.1データ表示の回避策はありますか
ArcgisエンジンアプリケーションからのデータとArcSDEデータベースの表示が非常に遅いので、SDEデータベースはローカルホストにあるため、ネットワークの問題はありません。しかし、私はまだこの問題を解決する方法も理由もわかりません。 2 CPUのXeon 3.4 GHzと2 GbのRAMを搭載した64ビットマシンで作業しています。 データベースには20のフィーチャクラスが含まれていますが、一部のフィーチャクラスではフィーチャの最大数が100 000を超えていません。データの表示を待つ場合、10分間待つ必要があります。 データベースのインデックスを圧縮して再構築しようとしましたが、改善はまったくありません。 ArcMapからデータを表示しようとしましたが、同じ問題が見つかりました。 パフォーマンスモニターを使用して、CPUとネットワーク側のいくつかのボトルネックを指摘しました。 SDEINTERCEPTの詳細: @travisアドバイスを試したので、Arcmapを使用してsdeでmxd参照データを開き、この部分に7分かかると述べました。 [W 10:34:37.710] Command: QueryWithInfo [R 10:34:37.710] Long: 1 [R 10:34:37.710] Query Info: Num Columns: 1 Columns: "shape" SQL_Construct: [1] Tables: "gebase.sde.point" WhereClause: "type_point_id<3" Query Type: 4 Num Hints: 0 Num Parameter markers: 0 Logfile: <null> [W 10:34:37.718] …

2
ShapefileとPostGISとGeoServerのパフォーマンス?
GeoServerを使用して約10個のマップをレンダリングするWebアプリケーションを構築します。一部のレイヤーのアプリケーションで属性データも変更します。 パフォーマンスと配置に推奨される選択肢は何ですか:ShapefileまたはPostGISデータベースを使用してGeoServerからレンダリングされたマップ?(または、それらは本当に重要ではありません) 私は空間クエリを扱いません。

1
GDALでFileGDBのパフォーマンスが遅い
GDAL 1.9.2のコンパイルを使用して、ESRIファイルジオデータベースに多くのASPRS LASポイントファイルを書き込もうとしています。GDAL / OGRのFileGDBドライバーは、大きなファイルを書き込むときに信じられないほど遅く、800万ポイントのレコードを書き込むのに45分もかかります。SATA3ドライブでGDALを使用するFileGDBの書き込み速度は、毎秒200キロバイト程度であり、テラバイトのデータを変換しようとすると許容できないほど低速になります。 FileGDBのドキュメントで、FGDB_BULK_LOADマクロを定義すると大規模なデータセットのパフォーマンスが向上することに気付きましたが、FGDB_LIBの直後に「FGDB_BULK_LOAD = YES」というテキストを含む行を「nmake.opt」ファイルに書き込んだとき、パフォーマンスに変化はありませんでした。ライン。 確かに、FileGDBは何十億ものポイントデータレコードを格納するための理想的な方法ではありませんが、それは別の時代には不便です。FGDB_BULK_LOAD機能を正しく使用しましたか?これは、GDALビルドではなく、私のソースコードにあるはずですか? ありがとう。 更新:適切な使用法:(チャットで回答) FGDB_BULK_LOAD設定が正しくGDAL / OGR・プロセスの環境変数として格納されます。これは、Ragiが示すように、ogr exe呼び出し中にコマンドラインで設定されます。GDAL機能を使用すると、プログラムで設定することができ、全体のプロセスのために CPLSetConfigOption("FGDB_BULK_LOAD", "YES"); または現在のスレッドだけを使用して CPLSetThreadLocalConfigOption("FGDB_BULK_LOAD", "YES"); FGDB_BULK_LOADを呼び出す前に設定する必要がありますFGdbDataSource::CreateLayer()。OGRCleanupAll()この変数の設定を解除するかどうかは明確ではありませんでしたが、念のため複数回呼び出しても安全です。 このオプションを使用すると、数百万から数千万のポイントを書き込む場合のパフォーマンスが約5.5倍速くなりました。

2
MXDとMSDのパフォーマンスのベンチマーク?
MSDとMXDの公的に利用可能なベンチマークを見た人はいますか? MSD公開プロセスの一環として、マップサービス公開ツールバーを使用して一部のバリデーターを実行するという事実を無視すると、レンダリングに関して、MSDはどれだけ速くレンダリングできますか? これをさらに分解できますか?MSDはレンダリングが高速であることを知っていますが、MSDが大幅に高速でレンダリングされる特定の状況はありますか? 基本的なベクターレイヤーと画像 シンプルシンボルとマルチレイヤーシンボル 多くのレイヤーと多くの機能など キャパシティプランニングツールwikiに何かがあると思いましたが、MSDがMXDより優れている状況について詳しく説明しているものは何も見つかりませんでした。 MXDとMSDの統計とグラフを確認したい。 補足として、10.1では、MSDのオプションしかありません。

1
マルチポリゴンをポリゴンに分割する必要がありますか?
私が実装しているシステムには、関連するジオメトリを持つテーブルT1があります。ほとんどのジオメトリは、10 <n <100のn個のポリゴンのセットです。現在、テーブルT1には、GiSTインデックスを持つMultiPolygonタイプのジオメトリ列があります。 テーブルT1が大きくなるので、Polygonタイプの列を持つ2番目のテーブルT2との1対多のリレーションを作成し、各MultiPolygonをいくつかのポリゴンに分割する方が良いと思います。 しかし、テーブルT1に検索を実装する必要があるため、2番目のアプローチの欠点は、処理する追加の結合があることです。さらに、テーブルT1の単一のレコードのジオメトリを挿入することはより複雑になります。 誰かがそのような問題の経験を持っているのか、その人が何か光を放つことができるのかと思っています。

1
何百もの属性がArcGIS Serverレイヤーでパフォーマンスの問題を引き起こしますか?
これは、ファイルジオデータベースポリゴンフィーチャクラスからデータが提供されるArcGIS Server 10.0 SP1に関連しています。 1)パフォーマンス上の理由から、何百もの属性を持つフィーチャクラスを持つことは悪い考えですか? 2)このフィーチャクラスからArcGIS Serverマップサービス(数百の属性を含む)を作成することは悪い考えですか? 3)JS APIでfeatureLayerを構築し、現在必要な属性のみを指定すると、パフォーマンスに影響がありますか? たとえば、マップサービスには500個の属性が含まれている可能性がありますが、フィーチャレイヤーは featureLayer.fields = [x、y、z] アドバイスありがとうございます。詳細が必要な場合はお知らせください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.