‎最適化‎

‎一般的な概要

‎レンダリング速度は、デスクトップアプリケーションよりも、WebGISアプリケーションにとって非常に重要です。‎

  • ‎ウェブユーザーは、ほぼ即座に利用可能なことを期待しています‎

  • ‎各ユーザーは同じアプリケーションに要求を送信できます。数十人または数百人のユーザーがいる場合、Web アプリケーションの最適化が重要な作業です。‎

‎1 人のユーザーにマップを表示するのではなく、多数のユーザーに対して Web公開を考える必要があります。‎

‎デフォルトでは、Lizmapプロジェクトに追加する各QGISレイヤーのために、アプリケーションの起動時に(チェックボックス Toggled )にレイヤーの表示を切り替えるかどうかをLizmapプラグインから選択することができます。プロジェクトが30レイヤを含む場合、起動時にLizmapは、それらのそれぞれについてQGISサーバーに要求を送信するので、この地物を乱用しないように注意する必要があります。‎

‎チェックボックス :guilabel: ` 単一タイル ` がチェックされている場合、ブラウザウィンドウのサイズの30画像を要求します。存在しない場合、Lizmap は OpenLayers を通じて 30 シリーズのタイル (約 250 x 250 ピクセル) を要求します。各タイルはイメージであり、合計ウィンドウ サイズとズーム レベルの関数として作成されます。したがって、後続のユーザーは同じ領域をズームし、すでに生成されたタイルが再利用されます。‎

‎タイルは、2 つの非排他的なシステムでキャッシュできます。‎

  • ‎*サーバー側* 、QGISサーバーとLizmap がインストールされているマシン上でタイルが要求され、過去に生成され、期限切れでない場合、Lizmapはそれを再利用し、QGISサーバーに新しい要求を回避し、クライアントに送信します。‎

  • ‎*クライアント側* :タイルはブラウザキャッシュに保存され、期限が切れるまで再利用されます。これは、QGISサーバーとインターネットトラフィックへの要求の両方を回避します。‎

‎サーバー キャッシュを生成する必要があります。キャッシュの生成方法を知るためには、 管理者としてのキャッシュ管理 を読んでください。‎

‎パフォーマンスを最適化するには、表示するタイルを Lizmap がどのように使用するかを理解することが重要です。‎

‎1280 x 768 ピクセルの画面があるとします。すべてのレイヤーをタイル表示している場合、Lizmap では、レイヤーごとに約 5 x 3 = 15 のタイル (256 x 256 ピクセル) が表示され、より大きな画面の場合は、より多くのタイルが表示されます。周囲のタイルが部分的にしか表示されない場合、合計数はさらに大きくなります。レイヤーあたり平均 20 タイルが妥当な推定値です。30 のレイヤーでは、例のように、これは、ユーザーごとに、Lizmapの各起動時とすべてのズームとパンに対して、合計で約 20 x 30 = 600 のタイル (したがって、Lizmapサーバーに 600 要求) を意味します。10人の同時ユーザーがいる場合、キャッシュがすでに生成されていない場合、サーバーにとって非常に重くなり、QGISサーバーはそれらを作成する必要があります。各タイルに必要な時間は、サーバーのパフォーマンスとプロジェクトの複雑さに大きく依存します。‎

‎各タイルのサイズは、次の内容によって異なります。‎

  • ‎データのタイプ(単一のラスターまたはベクトル、または複数のレイヤーの組み合わせ)‎

  • ‎選択された画像形式 (PNG、JPEG)‎

‎一般的なタイルは約 30 Kb です。この例では、クライアントはレイヤーあたり約 20 x 30 = 600 Kb をダウンロードし、30 層の総計は約 18 Mb となり、サーバー (大量の接続帯域幅が消費) とユーザー (かなり高速な接続でも長い遅延) の両方が重くなります。‎

‎これらの計算は、Webマッピングで優れたパフォーマンスを達成するためには、選択を行い、可能な限り単純化する必要があることを明確に示しています。‎

‎たとえば、Googleマップや同様のサービスによって取られたアプローチで見ると、強力なサーバーを持つことに加えて、ベースレイヤーとして1つのタイルシリーズのみを、非常に少数の追加レイヤー(すべて同時に)を可能な限り簡素化していることは明らかです。このような単純なマップを作成できない場合でも、マップの最初の表示でどのレイヤーを絶対に表示し、どの妥協点がユーザーにとって許容可能かを知ることは重要です。‎

‎プロジェクトのオンとオフを切り替えるレイヤーが 50 個存在する場合、大半のユーザーがそれらのほとんどを選択することはありません。もちろん、個々のレイヤーを選択的に表示する必要があるため、レイヤーをグループ化して表示するレイヤーの数を減らすることはできません。‎

助言

‎アプリケーションをできるだけ最適化するために、以下の方法を推奨します。‎

  • ‎別々のQGISプロジェクトを作成し、異なる目的のために異なる Lizmapマップを、論理的なテーマでデータをグループ化します。たとえば、10 層の都市開発と、約 5 つのレイヤーを持つ環境に関する地図は、通常、すべてのデータを含む単一のオーバーコンプレックス プロジェクトよりも読みやすく、はるかに高速です。各プロジェクトに小さな画像を追加すると、ユーザーは一目で関連するプロジェクトを選択するのに役立ちます。また、QGISの埋め込みメカニズムを介して、異なるプロジェクト間でレイヤーの一部を共有することができます。‎

  • ‎管理者の Web インターフェイスでオプション Maps only を選択すると、ユーザーはボタン Home を使用して、あるマップから別のマップに自動的に切り替えることができ、ローカリゼーションとズームレベルを可能な限り維持できます。この場合、プロジェクトのリストとサムネイルを含む Lizmap ウェルカム ページは表示されず、ユーザーは管理者が選択したプロジェクトの 1 つに自動的に移動します。‎

  • ‎起動時にすべてのレイヤーを表示しないでください(上記の説明のように、チェックボックス Toggled を無効にします)。既定では、非常に重要なレイヤーのみが表示され、ユーザーは必要なレイヤーのみを有効にする必要があります。これにより、要求の数とネットワーク トラフィック全体が大幅に削減されます。‎

  • ‎レイヤーのグループを作成し、Lizmap プラグインでオプション :guilabel:` グループをレイヤーとして ` 使用します。一般的に、同じ一般的なテーマの一連のレイヤーを、スタイルの選択で表示することができます。この場合、Lizmap はグループ全体のチェックボックスを 1 つだけ表示し、さらに重要なことにグループ全体に対して 1 つのタイルのみの送信を要求するため、タイルとサーバー要求の数と、ダウンロードするデータの総量が減少し,グループの凡例が表示されます。‎

  • ‎いくつかのレイヤーに対しては、オプション :guilabel:` 単一タイル ` を使用します。この場合、Lizmap は一連のタイルではなく、画面のサイズに関する 1 つのレイヤーのイメージのみを作成します。これにより、サーバーへの要求数が大幅に減少します。たとえば、上記の例では、説明した最適化を行わずにすべてのレイヤーが表示される場合、すべてのユーザーは 480 ではなく、ズームまたはパンごとに 30 個の画像 (レイヤーごとに 1 つ) を要求します。ただし、ダウンロードするデータの合計サイズは似ています。一方、異なるユーザーがまったく同じイメージを要求する可能性は非常に低いため、キャッシュを使用することはこの場合は意味がなく、Lizmap では回避されます (2 つのオプションは相互に排他的です)。最適な選択 (単一タイルとタイル) は、レイヤーによって異なります。たとえば、15 個のレイヤーを組み合わせて作成された複雑なベース レイヤーは、グループ ( ‎ レイヤーとしてグループ化 ‎ )、タイル化、キャッシュとして最適です。一連のバス ラインのような単純な線形レイヤーは、単一のタイルとして表示できます。‎

  • ‎オプションを使用 :guilabel:` グループのチェックボックスを非表示にする ‎` : ‎これにより、ユーザーは不必要に20レイヤなどのグループを表示することを避け,5-10レイヤのグループとすることができます。

  • ‎データとQGISプロジェクトを最適化します。前述のように、インターネット上でマップを公開すると、多くのユーザーがサーバーを同時に閲覧できることを覚えておく必要があります。‎

    • ‎すべてのベクターレイヤーの空間インデックスを作成する‎

    • pyramidize all your raster layers (except the very small ones)

    • ‎適切な縮尺でデータを表示: 例えば、詳細な建物レイヤーを 1:500,000 に表示することは意味をなさ、 イメージはほとんど読み取り不可能であり、サーバーに多大な負荷をかける‎だけである。

    • ‎レイヤーの簡略化されたバージョンを使用して、異なる縮尺で表示します。次に、元のレイヤー(1:1,000前後)を単純化されたバージョン(1:10,000、1:50,000前後など)でグループ化し、 :guilabel:` Goupをレイヤーとして ` グループ化して、各縮尺で最も適切なデータを使用して、これを単一のレイヤーとして表示できます。‎

    • ‎On The Fly (OTF)の再投影に注意してください。たとえば、OpenStreetmapまたはGoogle(Pseudo Mercator,、EPSG:3857)からベースマップ上のLambert93(EPSG:2154)のデータを表示する場合、QGIS Serverは地図を生成する前にラスターとベクトルを再投影する必要があります。これは、大きなレイヤーや複雑なレイヤーのレンダリング時間に影響を与える可能性があります。フランスでは、EPSGで直接IGN Géoportail のベースマップを使用して再投影を回避することができます:EPSG:2154

    • ‎特定のレンダリング オプション (ラベル、式など) はサーバーに非常に負荷が大きいため注意してください。‎

    • ‎PostGISを使用する場合は、最適化します:常に空間インデックス、フィルタされたフィールドのインデックス、外部キー、PostgreSQLの設定に適切なパラメータ、TCP/IPの代わりにUnixソケット経由の接続(サービスの使用を通じてこれを行うことができます)などを追加します。‎

    • ‎適切なイメージ形式を使用します。透過性を必要としないベース レイヤーの場合、通常は最適なオプションは、タイルが小さくなり、ダウンロードが速くなります。他のレイヤーの場合は、より小さい Png(16 ビットまたは 8 ビット):いくつかのシンボルの場合、視覚的な結果が同じで、タイルが小さくなります。画質が許容できる範囲内かどうかを確認してください‎

    • ‎可能であれば、サーバー側の単純化を使用します。 ‎サーバー側の簡素化‎ 。‎

  • ‎サーバーをアップグレードします。これは常にオプションですが、上記のようにプロジェクトを最適化しなかった場合は、多くの場合役に立ちません。いずれにしても、ローエンドサーバー(例えば2 Gb RAM、2.2 GHzの2コア)は適していません。8 Gb RAM を搭載した高速クアッドコアが、妥当な最小値です。Windows上でQGISサーバーと Lizmap をインストールしないようにしてください、複雑で遅いです。‎

  • ‎Lizmap は、起動時およびすべてのズーム レベルでの凡例の自動ダウンロードを回避します。凡例が表示されている場合はオンデマンドでのみ行われ、各ズームのレイヤーごとに 1 つの要求が保存されます。‎

‎詳細: キャッシュをアクティブ化する方法‎

:menuselection:` Lizmap プラグイン --> レイヤー` では、生成されたイメージのキャッシュ (クライアント側とサーバー側) をレイヤーごとに有効にしたり、グループ化したりできます。‎

‎サーバー側‎

‎この地物は、オプション :guilabel:` 単一タイル ` と互換性がありません。Lizmap Webクライアントは、サーバー上にキャッシュタイルを動的に作成できます。このキャッシュは、サーバー上のQGIS-Serverによって既に生成された画像のストレージです。LizmapWebクライアントアプリケーションは、タイルが要求されるとキャッシュを自動的に生成します。キャッシュを有効にすると、すでに作られたQGIS-Serverタイルを作成しないため、サーバーの負荷を大幅に軽減することができます。‎

‎アクティブ化するには、次の手順を実行する必要があります。‎

  • :guilabel:` サーバータイルキャッシュ ` ‎‎チェックボックスをオンにします

  • ‎キャッシュ・サーバの有効期限を秒単位で指定します。 :guilabel:` 有効期限 (秒) ` 。0 はサーバーで有効期限が切れなければ、キャッシュがクリアされるまでタイルはサーバー上に保持されることを意味します。‎

Metatile オプションを使用すると、タイルを生成する画像サイズを指定できます。Metatile の原則は、サーバーに、要求のサイズに切り取って Web クライアントに返すように、期待したより大きなイメージを要求することです。このメソッドは、端で切り捨てられたラベルやタイル間の不連続を回避しますが、リソースを大量に消費します。既定値は「3,3」で、幅と高さが幅と高さの要求の 5 倍に等しいイメージです。このオプションはラスターでは役に立ちません。‎

注釈

‎メタスタイルを持つベクターレイヤーの場合、ラベルの位置を固定位置に設定する必要があります。ラベルが非常に長い場合は、ワードラップ機能を使用するか、またはメタタイルサイズを少し増やすことを忘れないでください。ラベルは同じ領域に表示されます。‎

‎クライアント側‎

:guilabel:` ブラウザクライアントキャッシュ ` オプションを使用すると、Webブラウザ(Mozilla Firefox、Chrome、インターネットエクスプローラ、オペラなど)キャッシュ内のタイルの有効期限を秒単位で指定できます。ブラウザで Lizmap マップを参照すると、表示されたタイルがキャッシュに格納されます。クライアント キャッシュを有効にすると、有効期限が切れていないキャッシュに既に存在するタイルのサーバーをブラウザが再要求しないため、Lizmap を大幅に最適化できます。‎

警告

‎値 '0' と '1' は同等であり、オプションは有効になりません。

‎データが頻繁に変更されるレイヤーを除き、最大値(1ヶ月 24 x 3600 x 30 = 2,592,000秒)に設定することをお勧めします。‎

注釈

  • ‎**プロジェクトをプロダクションに移動する場合** 、キャッシュは一度だけアクティブにする必要があります。‎

  • ‎**サーバとクライアントのこれら2つのキャッシュシステムは、互いに完全に独立しています** しかし、アプリケーションを最適化し、サーバーリソースを解放するために、この2つを組み合わせて使用することはとても重要です。

‎マスター プロジェクトのグループとレイヤーの統合によるキャッシュの集中管理‎

‎QGISでは、プロジェクト、グループ、または別のプロジェクトのレイヤー( 上位プロジェクト)に統合することが可能です。この手法では、プロジェクト内で一度だけレイヤーのプロパティを設定し、他の複数のレイヤー,例えばベースレイヤーなどで使用できます。これらのレイヤーを統合する下位プロジェクトでは、これらのプロパティを変更することはできません。‎

‎Lizmap はこの機能を使用して、タイル キャッシュを集中管理します。上位プロジェクトの統合されたレイヤーを使用してすべての下位プロジェクトのために、Lizmapは、上位プロジェクトからではなく、上位プロジェクトからQGIS-Serverタイルを要求します。キャッシュは上位プロジェクトに集中化され、レイヤーを使用するすべての下位プロジェクトは共有キャッシュに役立ちます。‎

‎この機能を使用するには、次の手順を実行する必要があります。‎

  • ‎lizmapでparent-QGISプロジェクトを公開‎

    • ‎メニュー選定の中から、 公開された正しい範囲 を選択する必要があります。:menuselection:` プロジェクトプロパティ --> QGIS サーバー ` 、この 範囲は、下位プロジェクトで同じように再利用されます 。‎

    • ‎レイヤーを統合するには、 キャッシュを設定 する必要があります。また、下位プロジェクトで使用するためにここで選択されたオプション(イメージ形式、メタタイル、有効期限)にも注意してください。‎

    • Lizmap のチェック ボックスを使用してプロジェクトを非表示にできます。:menuselection:` マップ‎‎--> Lizmap Web クライアントのプロジェクトを非表示にする ` 。

  • ‎下位プロジェクトを開き、例えば、オルソフォトなどこのプロジェクトのレイヤーまたはグループを統合できます。そのためには、次の手順を実行する必要があります。‎

    • ‎**公開された範囲** を確認する :menuselection:` QGISプロジェクトのプロパティ --> QGISサーバー ` は 上位プロジェクトとまったく同じです 。‎

    • ‎イメージサイズ、有効期限、メタタイル: 上位プロジェクトから選択したものとまったく同じオプションを使用 して、統合レイヤー**の cacheを設定 をする必要があります。‎

    • 上位プロジェクトの ソース リポジトリ の Lizmap id を設定する必要があります (Lizmap Web クライアント管理インターフェイスで設定されているもの)。‎

    • ‎「ソースプロジェクト」('qgs'拡張子のない上位QGISプロジェクトの名前)のコードは、レイヤーと統合グループに自動的に入力されます。‎

  • ‎通常どおり、下位プロジェクトを Lizmap Web クライアントに公開します。‎