ja:documentation:pandorafms:technical_annexes:03_capacity_planning

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン 前のリビジョン
次のリビジョン		 前のリビジョン
ja:documentation:pandorafms:technical_annexes:03_capacity_planning [2024/08/16 05:29] – [SNMP サーバ] junichija:documentation:pandorafms:technical_annexes:03_capacity_planning [2025/11/02 05:15] (現在) – [通常サーバ] junichi
行 9: 行 9:
 ===== 概要 ===== ===== 概要 =====
  
-[[en:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] is a complex distributed application that has different key elements, susceptible to represent a bottleneck if it is not sized and configured correctly. The purpose of this chapter is to help to carry out a capacity study, **to analyze the //scalability// of Pandora FMS according to a specific set of parameters**. This study will help to know the requirements that the installation should have to be able to support a certain capacity.+[[:en:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] is a complex distributed application that has different key elements, susceptible to represent a bottleneck if it is not sized and configured correctly. The purpose of this chapter is to help to carry out a capacity study, **to analyze the //scalability// of Pandora FMS according to a specific set of parameters**. This study will help to find out the requirements that the installation should have to be able to support a certain capacity.
  
 [[:ja:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] は、さまざまな主要要素を持つ複雑な分散アプリケーションであり、サイズと設定が適切でない場合、ボトルネックになりやすくなります。この章の目的は、キャパシティ スタディの実行、**Pandora FMS の //スケーラビリティ// を特定のパラメータ セットに従って分析する** ことです。このスタディは、特定のキャパシティをサポートするために必要なインストール要件を知るのに役立ちます。 [[:ja:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] は、さまざまな主要要素を持つ複雑な分散アプリケーションであり、サイズと設定が適切でない場合、ボトルネックになりやすくなります。この章の目的は、キャパシティ スタディの実行、**Pandora FMS の //スケーラビリティ// を特定のパラメータ セットに従って分析する** ことです。このスタディは、特定のキャパシティをサポートするために必要なインストール要件を知るのに役立ちます。
  
-The load tests are also used to observe the maximum capacity per server. In the current architecture model ([[en:documentation:pandorafms:technical_reference:10_versions|version 3.0 or later]]), with "N" independent servers and a **[[en:documentation:pandorafms:command_center:01_introduction|Command Center (Metaconsole)]]** installed, this //scalability //tends to be of linear order, while //scalability// based on centralized models is exponential.+Load tests are also used to see the maximum capacity per server. In the current architecture model ([[:en:documentation:pandorafms:technical_reference:10_versions|version 3.0 or later]]), with "N" independent servers and a **[[:en:documentation:pandorafms:command_center:01_introduction|Command Center (Metaconsole)]]** installed, this //scalability //tends to be of linear order, while //scalability// based on centralized models is exponential.
  
 負荷テストは、サーバあたりの最大容量を観察するためにも使用されます。現在のアーキテクチャモデル ([[ja:documentation:pandorafms:technical_reference:10_versions|バージョン 3.0 以降]]) では、"N" 台の独立したサーバと **[[ja:documentation:pandorafms:command_center:01_introduction|コマンドセンター (メタコンソール)]]** がインストールされている場合、この //スケーラビリティ // は線形になる傾向がありますが、単一サーバモデルでの //スケーラビリティ// は指数関数的になります。 負荷テストは、サーバあたりの最大容量を観察するためにも使用されます。現在のアーキテクチャモデル ([[ja:documentation:pandorafms:technical_reference:10_versions|バージョン 3.0 以降]]) では、"N" 台の独立したサーバと **[[ja:documentation:pandorafms:command_center:01_introduction|コマンドセンター (メタコンソール)]]** がインストールされている場合、この //スケーラビリティ // は線形になる傾向がありますが、単一サーバモデルでの //スケーラビリティ// は指数関数的になります。
行 81: 行 81:
 このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、"QUASAR TECNOLOGIES" という架空の会社の特徴を示しています。 このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、"QUASAR TECNOLOGIES" という架空の会社の特徴を示しています。
  
-  * 90% のモニタリングをソフトウエアエージェントで実施。+  * Monitoring 90% based on EndPoints. 
 +  * Homogeneous systems with a series of characterizations grouped into technologies / policies. 
 +  * Highly variable intervals between the different modules and events to be monitored. 
 +  * Large amount of asynchronous information (events, log items). 
 +  * Lots of process status information with very little probability of change. 
 +  * Little information on yields compared to the total. 
 + 
 +  * 90% のモニタリングをエンドポイントで実施。
   * 技術/ポリシーでグループ化できる似たようなシステムがある。   * 技術/ポリシーでグループ化できる似たようなシステムがある。
   * モニタするモジュールやイベント間で、実行間隔が異なる。   * モニタするモジュールやイベント間で、実行間隔が異なる。
行 310: 行 317:
 <WRAP center round tip 90%> <WRAP center round tip 90%>
  
-An installation of Pandora FMS with a GNU/Linux server installed "by default" in a powerful machine, can not pass from 5 to 6 packets per second, in a powerful machine well "optimized" and "conditioned" it can reach 30 to 40 packets per second. **This also depends a lot on the number of modules in each agent**.+An installation of Pandora FMS with a Linux server installed "by default" in a powerful machine, can not pass from 5 to 6 packets per second, in a powerful machine well "optimized" and "conditioned" it can reach 30 to 40 packets per second. **This also depends a lot on the number of modules in each agent**.
  
 </WRAP> </WRAP>
行 316: 行 323:
 <WRAP center round tip 90%> <WRAP center round tip 90%>
  
-これの重要性：強力なマシンに "デフォルト" でインストールされた GNU/Linux サーバ 1台で、Pandora は、毎秒 5〜6 データを超えることはできませんが、十分に "最適化" および "調整" された強力なマシンでは、毎秒 30-40 データまで処理することができます。**また、各エージェントに含まれるモジュールの数にも依存します**。+これの重要性：強力なマシンに "デフォルト" でインストールされた Linux サーバ 1台で、Pandora は、毎秒 5〜6 データを超えることはできませんが、十分に "最適化" および "調整" された強力なマシンでは、毎秒 30-40 データまで処理することができます。**また、各エージェントに含まれるモジュールの数にも依存します**。
  
 </WRAP> </WRAP>
行 381: 行 388:
 <wrap #ks3_2 /> <wrap #ks3_2 />
  
-==== ICMP サーバ ====+==== 高性能ネットワークサーバ ====
  
-It is specifically the [[en:documentation:pandorafms:introduction:02_architecture|ICMP network server]]. In case of testing for the network server Open version, see the point corresponding to the network server (generic).+It is specifically the [[:en:documentation:pandorafms:introduction:02_architecture#network_high_performance_server|Network High Performance Server]]. In case of testing for the network server Open version, see the point corresponding to the network server (generic).
  
-これは、[[:ja:documentation:pandorafms:introduction:02_architecture#icmp_サーバ|ICMPネットワークサーバ]]用です。オープンソースのネットワークサーバのテストを行う場合は、ネットワークサーバ(汎用)の対応する章を参照してください。+これは、[[:ja:documentation:pandorafms:introduction:02_architecture#高性能ネットワークサーバ|高性能ネットワークサーバ]]です。ネットワークサーバ（オープンソース版）のテストについては、ネットワークサーバ（汎用）の該当箇所を参照してください。
  
 Assume you already have the server up and running and configured. Some key parameters for its operation: Assume you already have the server up and running and configured. Some key parameters for its operation:
行 391: 行 398:
 サーバがすでに設定され動作していると仮定すると、そのパフォーマンスに関するいくつかの重要なパラメーターは次のとおりです。 サーバがすでに設定され動作していると仮定すると、そのパフォーマンスに関するいくつかの重要なパラメーターは次のとおりです。
  
-<file>+<code>
 block_size X block_size X
- +</code>
-</file>+
  
 Defines the number of pings that the system will do per run. If most pings will take the same amount of time, you can raise the number to a considerably high number, such as 50 to 70. Defines the number of pings that the system will do per run. If most pings will take the same amount of time, you can raise the number to a considerably high number, such as 50 to 70.
行 404: 行 410:
 逆に、ping モジュールが少なく、対象のネットワークが大きく異なり遅延時間もそれぞれ異なるような場合は、テストに遅い方の時間を要するため、大きな数値は設定しない方が良いです。15 から 20 などの非常に低い数を使用します。 逆に、ping モジュールが少なく、対象のネットワークが大きく異なり遅延時間もそれぞれ異なるような場合は、テストに遅い方の時間を要するため、大きな数値は設定しない方が良いです。15 から 20 などの非常に低い数を使用します。
  
-<file> +<code> 
-icmp_threads X +networkhpserver_threads X 
- +</code>
-</file>+
  
-Obviously, the more threads you have, the more checks you will be able to execute. If you add all the threads that Pandora FMS executes, they should not reach the range of 30 to 40. You should not use more than 10 threads here, although it depends a lot on the type of hardware and the GNU/Linux version you are using.+Obviously, the more threads you have, the more checks you will be able to execute. If you add all the threads that Pandora FMS executes, they should not reach the range of 30 to 40. You should not use more than 10 threads here, although it depends a lot on the type of hardware and the Linux version you are using.
  
-明らかに、スレッドが多いほど、実行できるチェックも多くなります。 Pandora FMS が実行するすべてのスレッドを追加しても、30〜40 を超えることはありません。利用している GNU/Linux バージョンとハードウェアの種類に大きく依存しますが、ここでは 10 を超えるスレッドは使用するべきではありませｎ。+明らかに、スレッドが多いほど、実行できるチェックも多くなります。 Pandora FMS が実行するすべてのスレッドを追加しても、30〜40 を超えることはありません。利用している Linux バージョンとハードウェアの種類に大きく依存しますが、ここでは 10 を超えるスレッドは使用するべきではありませｎ。
  
-Now, you must "create" a fictitious number of ping type modules to test. It is assumed that you will test a total of 3000 ping modules. To do this, it is best to take a system on the network that is capable of supporting all pings (any GNU/Linux server can handle the task).+Now, you must "create" a fictitious number of ping type modules to test. It is assumed that you will test a total of 3000 ping modules. To do this, it is best to take a system on the network that is capable of supporting all pings (any Linux server can handle the task).
  
-次に、テストする架空の数の ping モジュールを "作成" します。 ping タイプのモジュール合計 3000個をテストするとします。 これを行うための最良のオプションは、すべての ping をサポートするネットワーク内のシステムを選択することです(GNU/Linux サーバならどれでも大丈夫です)。+次に、テストする架空の数の ping モジュールを "作成" します。 ping タイプのモジュール合計 3000個をテストするとします。 これを行うための最良のオプションは、すべての ping をサポートするネットワーク内のシステムを選択することです(Linux サーバならどれでも大丈夫です)。
  
 Using the Pandora FMS CSV importer, create a file with the following format: Using the Pandora FMS CSV importer, create a file with the following format:
行 457: 行 462:
 その後、Pandora FMS はそれらのモジュールの処理を開始します。 前のケースと同じメトリックを測定し、それがどのように推移するかを評価します。 目的は、必要な ICMP タイプのモジュールの数に対して、不明状態にならずに処理できかです。 その後、Pandora FMS はそれらのモジュールの処理を開始します。 前のケースと同じメトリックを測定し、それがどのように推移するかを評価します。 目的は、必要な ICMP タイプのモジュールの数に対して、不明状態にならずに処理できかです。
  
-<wrap #ks3_3 /> 
  
-==== SNMP サーバ ====+**This specifically concerns SNMP checks**. Assuming you already have the server up and running and configured. Some key parameters for its operation:
  
-This is specifically about the SNMP Enterprise network server. In case of testing for the Open network server, see the section on the (generic) network server. +**ここからは SNMPチェックに関する内容です**。サーバーが既に起動し、設定済みであることを前提としています。動作に必要な主要なパラメータは以下のとおりです。
- +
-これは SNMP ネットワークサーバーに関するものです。 オープンソースのネットワークサーバのテストの場合は、(汎用の)ネットワークサーバの章を参照してください。 +
- +
-Assuming that you have the server already working and configured, we are going to explain some key parameters for its working: +
- +
-サーバがすでに設定され動作していると仮定して、サーバが機能するためのいくつかの重要なパラメーターについて説明します。+
  
 <file> <file>
行 474: 行 472:
 </file> </file>
  
-It defines the number of SNMP requests that the system will do for each execution. You should consider that the server groups them by destination dir IP, so this block is only indicative. It is recommendable that it wouldn't be large (30 to 40 maximum). When an item of the block fails, an internal counter does that the Enterprise server will try it again, and if after x attempts it doesn't work, then it will pass it to the open server. +It defines the number of SNMP requests that the system will make for each execution. Bear in mind that the server groups them by destination IP address, so this block is a guideline. It should not be too large (30 to 40 maximum). When a block element fails, an internal counter causes the PFMS server to retry it.
- +
-これは、システムが 1回に実行する SNMP リクエストの数を定義します。サーバが宛先 IP でグループ化することを考慮するため、このブロックは単なる指標です。 大きくしないことをお勧めします(最大 30〜40)。ブロック内の要素に障害が発生すると、内部カウンターは Enterprise サーバでそれを再試行し、試行回数が x 回を超えても応答がない場合は、オープンソースのサーバに処理を渡します。 +
- +
-<file> +
-snmp_threads X +
- +
-</file> +
- +
-It should not be too large (30 to 40 maximum). When an element of the block fails, an internal counter makes the Enterprise server retry it, and if after X attempts it does not work, it will be passed to the Open server. You shouldn't user more than 10 threads, though it depends on the kind of hardware and GNU/Linux version that you use.+
  
-使用するハードウェアの種類と GNU/Linux のバージョンによって異なりますが、10を超えるスレッドを使用しないでください。+システムが各実行時に行うSNMPリクエストの数を定義します。サーバはリクエストを宛先IPアドレスごとにグループ化するため、このブロックは目安です。あまり大きくしすぎないようにしてください（最大30～40）。ブロック要素が失敗すると、内部カウンターによってPFMSサーバはリクエストを再試行します。
  
 The faster way to test is through a SNMP device, applying all the interfaces, all the serial "basic" monitoring modules.This is done through the application of the Explorer SNMP (Agente → Modo de administracion → SNMP Explorer). Identify the interfaces and apply all the metrics to each interface. In a 24 port switch, this generates 650 modules. The faster way to test is through a SNMP device, applying all the interfaces, all the serial "basic" monitoring modules.This is done through the application of the Explorer SNMP (Agente → Modo de administracion → SNMP Explorer). Identify the interfaces and apply all the metrics to each interface. In a 24 port switch, this generates 650 modules.
行 513: 行 502:
 <wrap #ks3_4 /> <wrap #ks3_4 />
  
-==== プラグイン、ネットワーク(オープンソース)、HTTP サーバ ====+==== ヘビーサーバ ====
  
-Here is applied the same concept that above, but in a more simplified way. You should check:+The same concept applies here [[#ks3_2|as above]], but in a more simplified form. It will be necessary to control:
  
-前述と同じ概念を適用しますが、より単純化された方法です。 以下を確認する必要があります。+ここでも[[#ks3_2|上記と同じ]]概念が適用されますが、より簡略化された形で適用されます。以下の点を調整する必要があります。
  
   * Number of threads.   * Number of threads.
 +  * Timeouts to calculate the worst-case incidence.
 +  * Average check time.
  
   * スレッド数   * スレッド数
- 
-  * Timeouts (to calculate the incidence in the worst case). 
- 
   * タイムアウト(最悪の場合の発生率を計算するため)   * タイムアウト(最悪の場合の発生率を計算するため)
- 
-  * Check average time. 
- 
   * 平均時間の確認   * 平均時間の確認
  
-Scaling with these data a test group and check that the server capacity is constant over time.+Size a test set with this data, and verify that the server capacity is constant over time.
  
 これらのデータを使用してテストグループをスケーリングし、サーバ容量が時間の経過とともに一定であることを確認します。 これらのデータを使用してテストグループをスケーリングし、サーバ容量が時間の経過とともに一定であることを確認します。
 +
 +<wrap #ks3_5 />
  
 ==== トラップ受信 ==== ==== トラップ受信 ====
  
-Here, the case is more simple: ssume that the system is not going to receive traps in a constant way, but that it is about evaluating the response to a traps flood, from which some of them will generate alerts.+Here the assumption is simpler: it is assumed that the system is not going to receive traps constantly, but rather to evaluate the response to an avalanche of traps, some of which will generate alerts.
  
 このケースはより単純です。システムが一定量のトラップを受信するのではなく、一時的に大量のトラップが来た場合の応答を評価し、そこからアラートを生成することを想定します。 このケースはより単純です。システムが一定量のトラップを受信するのではなく、一時的に大量のトラップが来た場合の応答を評価し、そこからアラートを生成することを想定します。
  
-To do this, you will only have to do a simple script that generates traps in a controlled way and at hight speed:+To do this you simply need to make a script that generates traps in a controlled manner at high speed:
  
 それには、制御された方法で高速でトラップを生成する単純なスクリプトを実行するだけで済みます。 それには、制御された方法で高速でトラップを生成する単純なスクリプトを実行するだけで済みます。
  
-<file>+<code bash>
 #!/bin/bash #!/bin/bash
 TARGET=192.168.1.1 TARGET=192.168.1.1
行 553: 行 540:
 done done
  
-</file>+</code>
  
-Note: stop it with the CTRL+C key after a few seconds, as it will generate hundreds of traps quickly.+**Note**: stop it with the CTRL+C key after a few seconds, as it will generate hundreds of traps quickly.
  
-注: 数百のトラップがすばやく生成されるため、数秒後に CTRL+C キーで停止してください。+**注**: 数百のトラップがすばやく生成されるため、数秒後に CTRL+C キーで停止してください。
  
-Once the environment is set up we need to validate the following things:+Once the environment has been set up, the following assumptions must be validated:
  
 環境をセットアップしたら、次のことを検証する必要があります。 環境をセットアップしたら、次のことを検証する必要があります。
  
-  - Traps injection to a constant rate(just put one ''sleep 1''  to the previous script inside the loop **while**, to generate 1 trap/sec. Let the system operating 48 hours and evaluate the impact in the server. +  - Injection of traps at a constant rate (just enter a ''sleep 1'' command to the above script inside the **while** loop, to generate 1 trap per second. The system is left running for 48 hours and the impact on the server is evaluated. 
-  - Traps Storm. Evaluate moments before, during and the recovery if a traps storm occurs. +  - Trap storm. Evaluate the before, during, and recovery from a trap storm. 
-  - Effects of the system on a huge traps table ( more than 50 thounsand). This includes the effect of passing the DDBB maintenance.+  - Effects of the system on a very large table of traps (greater than 50 thousand). This includes the effect of passing the DB maintenance.
  
   - 一定速度のトラップを受信します(前述のスクリプトの **while** ループ内に ''sleep 1'' を設定するだけで、1トラップ/秒を生成します)。システムを 48時間稼働させ、サーバへの影響を評価します。   - 一定速度のトラップを受信します(前述のスクリプトの **while** ループ内に ''sleep 1'' を設定するだけで、1トラップ/秒を生成します)。システムを 48時間稼働させ、サーバへの影響を評価します。
   - 大量トラップ。大量のトラップ受信が発生した場合の、その前後、発生中の評価をします。   - 大量トラップ。大量のトラップ受信が発生した場合の、その前後、発生中の評価をします。
   - 巨大なトラップテーブル(5万以上)に対するシステム影響の確認。 これには、データベースメンテナンスへの影響も含みます。   - 巨大なトラップテーブル(5万以上)に対するシステム影響の確認。 これには、データベースメンテナンスへの影響も含みます。
 +
 +<wrap #ks3_6 />
  
 ==== イベント ==== ==== イベント ====
  
-In a similar way as with the SNMP, evaluate the PFMS system's [[:en:documentation:04_using:02_events|events]] in two cases:+Similar to SNMP, the [[en:documentation:pandorafms:management_and_operation:02_events|events]] of the PFMS system will be evaluated in two scenarios:
  
-SNMP の場合と同様に、次の 2つの場合の Pandora FMS システムの[[:ja:documentation:04_using:02_events|イベント]]を評価します。+SNMP の場合と同様に、次の 2つの場合の Pandora FMS システムの[[:ja:documentation:pandorafms:management_and_operation:02_events|イベント]]を評価します。
  
-1. Normal range of event reception. This has been already tested in the data server, so in each status change, an event will be generated.+  - Normal event reception rate. This has already been tested in the data server, since an event is generated at each state change. 
 +  - Event generation storm. To do this, we will force the generation of events via CLI. Using the following command (with an existing group called "Tests"):
  
-1. イベント受信の通常の範囲。 これはデータサーバですでにテストされているため、ステータスが変更されるたびにイベントが生成されます。+  - イベント受信の通常の範囲。 これはデータサーバですでにテストされているため、ステータスが変更されるたびにイベントが生成されます。 
 +  - 大量のイベント生成。これを行うには、CLI を介してイベントの生成を強制します。 次のコマンドを使用します(作成された "TestingGroup" を使用)。
  
-2. Event generation Storm. To do this, we force the generation of evets via CLI. Using the following command (with a created "TestingGroup"):+<code bash> 
 +pandora_manage /etc/pandora/pandora_server.conf --create_event "Event test" system Tests
  
-2. 大量のイベント生成。これを行うには、CLI を介してイベントの生成を強制します。 次のコマンドを使用します(作成された "TestingGroup" を使用)。+</code>
  
-<file>+That command, used in a loop like the one used to generate traps, can be used to generate dozens of events per second. It can be parallelized in a script with several instances to cause a higher number of insertions. This would serve to simulate the behavior of the system in an event storm. In this way the system could be tested before, during and after an event storm.
  
-/usr/share/pandora_server/util/pandora_manage.pl \ +このコマンドは、トラップの生成に使用したものと同様にループを使用し、1秒ごとに数十のイベントを生成するために使用します。発生数を増やすために、複数のインスタンスを使用して 1つのスクリプトを並列化することができます。 これは、大量のイベントが発生した場合にシステムのパフォーマンスをシミュレートするのに役立ちます。 このようにして、大量イベントの前後、最中にシステムをチェックできます。
-  /etc/pandora/pandora_server.conf --create_event "Event test" system TestingGroup+
  
-</file> +<wrap #ks3_7 />
- +
-This command, used un a loop as the one used to generate traps, it can be used to generate tens of events by second. It could be parallelize in one script with several instances to get a higher number of insertions. This will be useful to simulate the performance of the system if an event storm happens. This way we could check the system, before, during and after the event storm. +
- +
-このコマンドは、トラップの生成に使用したものと同様にループを使用し、1秒ごとに数十のイベントを生成するために使用します。発生数を増やすために、複数のインスタンスを使用して 1つのスクリプトを並列化することができます。 これは、大量のイベントが発生した場合にシステムのパフォーマンスをシミュレートするのに役立ちます。 このようにして、大量イベントの前後、最中にシステムをチェックできます。+
  
 ==== ユーザの同時アクセス ==== ==== ユーザの同時アクセス ====
  
-For this use another server, independent from Pandora FMS, using the WEB monitoring functionality. Do a user session where we have to do the following tasks in this order, and see how long they take.+For this, another server independent from Pandora FMS will be used, using the WEB monitoring functionality. In a user session where it will perform the following tasks in a specific order and measure how long they take to be processed:
  
 こにには、WEB 監視機能を使用して、Pandora FMS から独立した別のサーバを使用します。 次のタスクをこの順序で実行するユーザセッションを実行し、それらにかかる時間を確認します。 こにには、WEB 監視機能を使用して、Pandora FMS から独立した別のサーバを使用します。 次のタスクをこの順序で実行するユーザセッションを実行し、それらにかかる時間を確認します。
  
-  - Login in the console+  - Login to the web console.
   - See events.   - See events.
   - Go to the group view.   - Go to the group view.
-  - Go to the agent detail view. +  - Go to agent detail view 
-  - Visualize a report (in HTML). This report should contain a pair of graphs and a pair of modules with report type SUM or AVERAGE. The interval of each item should be of one week or five days. +  - Display a report (in HTML). This report should contain a couple of graphs and a couple of modules with SUM or AVERAGE type reports. The interval for each item should be one week or five days. 
-  - Visualization of a combined graph (24 hours). +  - Display of a combined graph (24 hours). 
-  - Generation of report in PDF (another different report).+  - Generation of PDF report (another different report).
  
   - コンソールへのログイン。   - コンソールへのログイン。
行 618: 行 605:
   - PDF でのレポート生成(他のレポートにて)。   - PDF でのレポート生成(他のレポートにて)。
  
-This test is done with at least three different users. This task could be parallelize to execute it every minute, so as if there are 5 tasks (each one with their user) we would be simulating the navigation of 5 simultaneous users.Once the environment is set up, we should consider this:+This test is performed with at least three different users. You can parallelize that task to run it every minute, so that if there are 5 tasks (each with its user), you would be simulating the navigation of five simultaneous users. Once the environment is established, it will take into account:
  
 このテストは、少なくとも 3人の異なるユーザを使用して行います。このタスクは並列化して毎分実行することができるため、5つのタスク(それぞれがユーザを含む)があるのであれば、5人のユーザの同時ナビゲーションをシミュレートします。環境をセットアップしたら、次のことを考慮する必要があります。 このテストは、少なくとも 3人の異なるユーザを使用して行います。このタスクは並列化して毎分実行することができるため、5つのタスク(それぞれがユーザを含む)があるのであれば、5人のユーザの同時ナビゲーションをシミュレートします。環境をセットアップしたら、次のことを考慮する必要があります。
  
-  - The average velocity of each module is relevant facing to identify " bottle necks" relating with other parallel activities, such as the execution of the maintenance script, etc. +  - The average speed of each module is relevant in order to identify "bottlenecks" related to other parallel activities, such as the execution of maintenance //script//, et cetera. 
-  - The impact of CPU and memory will be measured in the server for each concurrent session. +  - CPU and memory impact on the server will be measured for each concurrent session. 
-  - The impact of each user session simulated referred to the average time of the rest of sessions will be measured. This is, you should estimate how many seconds of delay adds each simultaneous extra session.+  - The impact of each simulated user session will be measured with respect to the average time of the rest of the sessions. That is, it should be estimated how many seconds of delay each simultaneous extra session adds.
  
   - 各モジュールの平均速度で、メンテナンススクリプトの実行など、他の平行して行われる処理に関連した "ボトルネック" を特定します。   - 各モジュールの平均速度で、メンテナンススクリプトの実行など、他の平行して行われる処理に関連した "ボトルネック" を特定します。
  • ja/documentation/pandorafms/technical_annexes/03_capacity_planning.1723786170.txt.gz
  • 最終更新: 2024/08/16 05:29
  • by junichi