Skip to main content
OutSystems

パフォーマンスのベストプラクティス - インフラ

高速に実行されるようにアプリケーションを設計したにもかかわらず、不適切な構成やハードウェアの性能不足/サイズ不足のために低速で動作が重い場合、ソフトウェア開発者は非常にフラストレーションがたまります。

OutSystemsプラットフォームをインストールする際に以下のベストプラクティスを必ず適用し、データベース管理者がプロセスに常に参加するようにします。 

データベースの保守計画を立てる

説明

インデックスが作成されたアトリビュートに対するデータベースクエリが依然として低速で、フラグメント化が進んでいるためにデータベースエンジンがインデックスを使用せず、テーブル全体のスキャンが実行されている形跡があります。インデックスをデフラグする必要があります。

ソリューション

通常の最適化を適用し、既存のインデックスを再編成または再構築します。また、データベース統計を更新します。これによってインデックスがデフラグされ、データベース全体のスキャンを行う代わりにインデックスを使用するために必要な情報がデータベースエンジンに提供されます。時間経過に伴うフラグメント化のレベルに応じて、これらの計画を週1回以上スケジュール設定します。

重要事項

OLTP(オンライントランザクション処理)では、作成済みのインデックスを使用しないSQLクエリ、テーブル挿入、更新、削除によってテーブルのインデックスがフラグメント化しやすく、テーブル統計においてテーブル全体のスキャンがクエリ実行の最適なオプションであると示されるようになります。インデックスの再編成と統計の更新によってインデックスのデフラグが維持され、これにより、テーブル全体のスキャンを行う代わりにインデックスが使用される確率が高くなり、全体的なクエリパフォーマンスが向上します。

注意事項

インデックスの再編成や再構築には時間とリソースがかかるため、負荷が少ない期間に実行するようにスケジュール設定します。社内のデータベース管理者が参加するようにしてください。

Webサーバーのメモリ設定を構成する

説明

推奨される調整設定を適用し、ワーカープロセスのリサイクル数を減らします。ただし、メモリの限界に達しないようにします。

ソリューション

フロントエンドサーバーのカーネルCPUの使用率が高く、全体的なパフォーマンスが低下しています。

重要事項

ワーカープロセスのリサイクル頻度が多いと、アプリケーションがメモリからアンロードされ、ASP.NETアプリケーションの実行時再コンパイルやアセンブリおよびキャッシュの再読み込みが必要になります。このため、パフォーマンスが低下します。

注意事項

推奨される調整設定を適用し、ワーカープロセスのリサイクル数を減らします。ただし、メモリの限界に達しないようにします。

データベースのトランザクションログをこまめにバックアップする

説明

大量のデータが変更されるデータベースに、トランザクションログの定期的なバックアップを設定します。

ソリューション

ファイルが増大しすぎないようにするため、トランザクションログファイルを定期的にバックアップする保守計画を立てます。

重要事項

トランザクションログのバックアップを行わないと、ディスク空き領域の不足やファイルのフラグメント化の原因となります。定期的なバックアップにより、新しいトランザクション情報のための空き領域が確保されます。このため、通常、ログファイルは同じサイズに保たれ、大幅に増大することはありません。

注意事項

社内のデータベース管理者が参加するようにしてください。なお、このプラクティスは開発環境とQA環境を含むすべての環境を対象とします。

データベースファイルの増大を調整する

説明

データベースのデータファイルとログファイルを別の物理ストレージに配置し、ファイルの増大を適切に構成します。

ソリューション 

データベースに推奨される調整設定を適用します。たとえば、以下のように設定します。(a)データファイルおよびログファイルの増大を確実で大きい値(512MBなど)に設定し、(b)データファイルとログファイルを別のディスクに分離します(同じディスク上でパーティションを分離するだけでなく、物理的に異なるディスクまたは異なるストレージパーティションに分離します)。

重要事項

負荷が高いデータベースの最も一般的なボトルネックはI/O(入出力)です。メモリは無限に増やすことができないため、データベースのI/Oは一定です。データベースファイルを最適化してフラグメント化を少なくし、I/Oアクセスを最適化することにより、I/Oに関するボトルネックの問題を最小限に抑えます。

注意事項

データベースに関する他のベストプラクティスと同様、このプラクティスを実践する際は社内のデータベース管理者に相談してください。

仮想メモリとシステム設定を適用する

説明

仮想メモリおよびシステムパフォーマンスの設定を調整し、インデクサなどのサードパーティアプリケーションを無効化/構成します。

ソリューション

仮想メモリの初期サイズと最大サイズの同一化、サービスパフォーマンスの最適化、システムキャッシュメモリの優先順位などのシステム設定を調整します。また、すべてのプログラムのDEP(データ実行防止)や、Windowsデスクトップ、Google Search、Microsoft Indexerといったインデクサのように、重いシステムやサードパーティの分析機能/ツールを無効にします。

重要事項

DEPやインデクサのようなコンポーネントは、ファイルをディスクから読み取ったりディスクに書き込んだりするたびに負荷を増やします。これにより、常に自動化されたプロセスでファイルの作成や書き込みを行う環境では、過負荷が深刻になります。

注意事項

DEPに関する問題は、ハードウェアでネイティブにサポートされていない場合やハードウェアが過小評価されていた場合に特に重要です。仮想メモリとシステムパフォーマンスについては、ページファイルの増大を避けるため、使用を最小限に抑えることが重要です。なお、これは開発サーバーでも非常に重要です(これらの制限が設定されていない場合、開発サーバーでSystemOutOfMemoryエラーが何度も発生することがあります)。

タイマーには専用サーバーを使用する

説明

タイマーを利用する重いバックグラウンド処理アプリケーションについて、タイマーをeSpaceで分離するようにします。タイマーを実行するための専用サーバーを構成します。

ソリューション

ユーザーがWebアプリケーションにアクセスするサーバーと同じサーバー上で、大きいタイマー処理を実行しないようにします。eSpaceでタイマーを分離し、複数のゾーンを使用して専用サーバーでタイマーを実行させます。または、タイマー専用のサーバーでスケジューラサービスのみをアクティベートします。

重要事項

タイマーを分離して専用サーバーで実行することで、アプリケーションを提供するフロントエンドサーバーの負荷が増えないようにします。これにより、画面の読み込みパフォーマンスも向上します。

注意事項

上記のソリューションを適用できない場合や最適な結果が得られなかった場合は、「Max. Concurrent Timers」の構成や適切なスケジュール時刻の設定を検討するか、場合によってはそのためのeSpaceおよびアプリケーションプールの作成も検討してください。

64ビットアーキテクチャを優先する

説明

負荷が高い環境では、32ビットアーキテクチャではなく、64ビットアーキテクチャのサーバーとオペレーティングシステムを使用するようにします。

ソリューション

64ビットアーキテクチャでは、サーバーのメモリリソースをより効率よく管理でき、32ビットアーキテクチャ環境のメモリ使用量の制限不足が解消されます。

重要事項 

32ビットアーキテクチャ環境のメモリ管理では、ワーカープロセスごとにメモリの制限があり、ユーザーのVAS(仮想アドレス空間)は最大2GB、さらにカーネルのVASは2GBに制限されます。つまり、サーバーの物理RAMが2GB以上ある場合であっても、VASメモリのフラグメント化によってすぐに2GBの制限に達し、システムのメモリに十分な空きがあってもOutOfMemory例外が発生してしまいます。64ビットアーキテクチャではVASメモリの制限が非常に増えるため(16TB)、利用可能なメモリサイズをワーカープロセスで十分に活用できます。

注意事項

64ビットのWebサーバーの調整設定を使用した場合、唯一の制限は、ワーカープロセスが最大物理メモリに達しないようにすることです。

一部のフォルダをウイルススキャンから除外する

説明

OutSystemsのオンプレミス環境でCPU使用率が最大値に達し、Windows Serverオペレーションの実行が遅くなることがあります。システムパフォーマンスへのウイルス対策ソフトウェアの影響を最小限に抑える必要があります。

ソリューション

Windows Defenderまたはその他のウイルス対策ソフトウェアが有効になっている場合、以下のパスのリアルタイムスキャンを無効にします。

  • OutSystems Platform Serverのインストールフォルダ(デフォルトではC:\Program Files\OutSystems\Platform Server\
  • ASP.NETの一時ファイルの場所(%WINDIR%\Microsoft.Net\framework64\v<バージョン>\Temporary ASP.NET Files(64ビットシステム))
  • .NET Frameworkの構成ファイル(%WINDIR%\Microsoft.Net\framework64\v<バージョン>\Config(64ビットシステム))
  • (オプション)システムの一時フォルダ(通常は%TEMP%またはC:\Windows\Temp

重要事項

ウイルス対策ソフトウェアのリアルタイムスキャン機能では、ファイルシステムの変更とアクセスを監視します。サーバーで処理中に大量のファイルの生成やアクセスが実行されると、ウイルススキャンがトリガーされ、その結果としてシステムリソースが消費され、サーバーのパフォーマンスが大幅に低下します。

注意事項 

ウイルス対策ソフトウェアを手動で実行し、除外したフォルダのスキャンを行うことができます。.NET Frameworkとウイルス対策ソフトウェアの詳細については、MicrosoftサポートWebサイトの「Folders to exclude from antivirus scanning in ASP.NET apps」の記事をご覧ください。