小テストの負荷に着目した Moodle 用 Web サーバの性能比較
齊藤 智也 1) , 王 躍 1) , 久長 穣 1) , 西村 世志人 1) , 末長 宏康 1) , 金山 知余 1) ,大平 康旦 1) , 爲末 隆弘 1) , 江口 毅 1) , 今岡 啓治 1) , 岡田 耕一 1 , 多田村 克己 1)
1) 山口大学 情報基盤センター
info-cc@ml.cc.yamaguchi-u.ac.jp

Performance Comparison between Web Servers for Moodle:
Focusing on Simultaneous Quiz Load
Tomoya Saito1) , Yue Wang1) , Yutaka Hisanaga1) , Yoshito Nishimura1) ,Hiromichi Suenaga1) , Chiyo Kaneyama1) , Yasuaki Ohira1) , Takahiro Tamesue1) ,Tsuyoshi Eguchi1) , Keiji Imaoka1) , Koichi Okada1 , Katsumi Tadamura1)
1) Center for Information Infrastructure, Yamaguchi Univ.

概要
山口大学情基盤センターでは授業支援システムとして Moodle を運用しているが，以前のシステムではバックエ
ンド側のデータベース・システムの性能不足が顕著であった．特に，100 名以上の学生が一斉に小テストを受験する
時にはデータベースの書き込みエラーが発生し，一部の学生の解答が保存されない問題が生じていた．新たなデー
タベース・システムの導入に伴い，我々は Apache JMeter を用いて多人数が一斉に小テストを受験する動作を模倣し，Moodle システムの応答時間を計測することとした．しかし，Moodle システムの性能は HTTP サービス・
ソフトウェアによって異なることが示唆されている. そこで我々は，一斉小テストにおける解答送信時の応答時間に着目し，各種 HTTP サービス・ソフトウェアの性能を比較した．

1 はじめに山口大学情報基盤センターは授業支援システムとし分な性能を得られなくなった．そこで我々は，2019 年

10 月に，非同期型レプリケーションを採用した新たなデータベース・システムを導入した [2]．

て Moodle [1] を運用している．Moodle は通常の授業

国内における新型コロナウィルス感染症の拡大にのほか，各種の行事・研修会等にも活用されている．

より，2020 年度には Moodle システムの利用科目数，

山口大学の Moodle システムは，フロントエンド側

及び同時利用者数が著しく増加した．そこで我々は，の Web システムとバックエンド側のデータベース・シ2020 年 5 月に，Web サーバの増強を行った．図 1 は，ステムから構成される．システムを構成するサーバは

現行の Moodle システムの構成を示している．Web

すべて，大学内のプライベート・クラウド上に構築さサーバは 3 台から 6 台に増強され，個々の Web サー

れた仮想サーバである．以前のシステムでは 2017 年

バの仮想 CPU は 4 コアから 8 コア，仮想メモリは頃より，データベースの性能不足が顕著となった．特4GB から 32GB にそれぞれ増強されている．

に，100 名以上の学生が一斉に小テストを受験する時

2019 年 10 月のデータベース・システムの移行に際にはデータベースの書き込みエラーが発生し，一部のし，我々は Apache JMeter [4] を用いた負荷テストを

学生の解答内容が記録されない問題が生じていた．当行った．多人数が一斉に小テストを受験する動作を模時のデータベース・システムでは，複数のサーバ間で倣するための JMeter テストプランを作成し，Moodle

データを同期させる仕組みとして，同期型レプリケー

システムの応答時間を計測することとした．しかし，ションを採用していた．同期型レプリケーションはMoodle システムの性能は，Web サーバとして採用す

データの整合性の維持や耐障害性に優れている反面，る HTTP サービス・ソフトウェアの種類よって異なデータの書き込み性能が低い．Moodle システムの利ることが示唆されている [3]．そこで我々は，一斉小用者の増加，並びにデータベースへの書き込み処理をテストにおける解答送信時の応答時間に着目し，各種伴う利用形態の増加に伴い，本学のサーバ環境では十HTTP サービス・ソフトウェアの性能を比較した．

い．特定の教材の活用に関する負荷を計測するため，独自のテストプランを用いて Moodle サイトの負荷を計測した事例も報告されている [10, 10, 11]．しかし，いずれにおいても，各スレッドが生成直後から間断なく処理を進めるテストプランが採用されている．そのため，特に JMeter のスレッド数が多い時には教材のアクセス時刻に大きなばらつきが生じ，その教材の同時利用に関する負荷を計測しているとは言えない．
本稿では，多数の利用者が一斉に小テストを受験する条件下における負荷テストを対象としている．そのため，スレッドの進捗状況を同期させる仕組みを加えた独自のテストプランを作成し，使用することとした．
最初に，山口大学の Moodle サイトにアクセスし，ロ
図 1: 現行の Moodle システム

グイン，共通教育科目のコースへのアクセス，小テス
トの受験，及びログアウトといった一連の操作を行った．JMeter が内蔵するプロキシを経由して Moodle
サイトにアクセスすることにより，一連の操作にお2 JMeter テストプラン

いて生成された HTTP リクエストを記録し，テスト

テストプランの作成

プランの原型とした．続いて，テストプランから不要

2.1

JMeter は，クライアント・サーバシステムの負荷テ

な HTTP リクエストを削除した．例えば，Moodle のスト及び性能計測を行うための Java アプリケーショ

キャッシュに配置される JavaScript ファイルや CSSンである [4]．JMeter は，予め指定された実施計画

ファイル等の URL は，その時点での一時的なもので（テストプラン）に基づいて各種プロトコルのリクエ

ある．負荷テストにおいてはこれらの URL が存在せストを送信し，サーバから返信されるレスポンスを受ず，エラーメッセージが返信される．これらのファイ

信する．Moodle 等の Web サイトの負荷テストにおルは Web ページのレイアウトや外観の調節に使用さいては HTTP リクエストを送信する．Moodle にはれ、各種操作の成否には影響を及ぼさない．このよう「JMeter Test Plan Generator」が付属している [5]．

な HTTP リクエストはテストプランから削除した．

JMeter を活用した Moodle サイトの負荷テスト事例

解答を送信する HTTP リクエストでは，パラメータの多くは，このツールによって生成されたテストプラとして sesskey，attempt，及び qubaid が必要である．

ンを活用している [6–8]．これらのテストプランでは，これらの値は，ユーザ認証，サイトホーム，小テスト

JMeter により生成された各々のスレッド（利用者のの概要といった各 Web ページに含まれている．そのWeb ブラウザに相当）は生成直後から順次，ログイン，

ため，Web ページの中からこれらの値を抽出して変数

コースの表示，ページの表示，フォーラム内の記事のに格納する動作をテストプランに追加した．また，テ表示，記事への返信の投稿，及びログアウトといった

ストプラン中の各 HTTP リクエストの URL 及びパ操作を間断なく実行し，処理を終了する．JMeter はラメータの記述を修正し，前述した各変数の値を使用

予め指定された時間内にすべてのスレッドを生成する

するようにした．

が，生成後に実際の処理が開始されるまでの時間には最後に，実行時パラメータの読み込み，スレッドの予期せぬばらつきが生じる．また，スレッド数（即ち作成，外部ファイルからのユーザ情報の読み込み，ス

同時利用者数）の増加に伴い，ログインやコースの表

レッド間の進捗状況の同期といった各種の動作を追加示といった前半の処理における応答時間にばらつきがした．

生じる．応答時間のばらつきの累積により，スレッド

テストプランを作成後，前述した共通教育科目の間で処理の進捗状況に差異が生じる．コース内に配置

コースをテスト環境（3.1 節を参照）の Moodle サイ

された教材へのアクセス開始時刻のばらつきは数十秒

トにコピーし，テスト用コースとした．このコースにを超える場合があり，多数の利用者が特定の教材を一テスト用の学生ユーザを登録し，テストプランを実行

斉に活用する条件下における負荷計測には適していな可能とした．

2.2

テストプランの動作

前節で作成したテストプランの動作を以下に示す．

(1) 指定された数のスレッドが 60 秒間で生成される．
(2) 生成されたスレッドは，Moodle サイトへのログ
イン，テスト用コースの表示，小テストへのアクセスを行う．

(3) 小テストの概要ページにおいて，各スレッドは他のすべてのスレッドがこの段階に到達するまで待機する．

(4) 各スレッドは 5 秒以内でランダムな時間だけ待機した後，小テストの受験を開始する．

て HTTP リクエストを送信し，レスポンス（Web ペー
ジやエラーメッセージ等）を受信する．プロキシ・サー
バは，Web サーバへの HTTP リクエストの振り分け，
並びにレスポンスの転送を行う．加えて，HTTPS 通信の暗号化／復号化も担当する．なお，一斉小テスト
における HTTP サービス・ソフトウェアの性能に焦点を当てるため，キャッシュ・サーバ等は実装していない．
プロキシ・サーバ及び Web サーバは，大学内のブ
レード・サーバ上に仮想サーバとして構築されている．
これらの仮想サーバの諸元は次の通りである.

(5) 各スレッドは受験開始から 5 分間待機する．

• CPU: 4 コア（合計 8.0 GHz 相当）(6) 各スレッドは小テストの解答内容を保存した後，• メモリ: 4 GB

すべてのスレッドがこの段階に到達するまで待機• ディスク: 100 GB

する．

• ネットワーク・インターフェース: 10 Gbps

(7) 各スレッドは 30 秒以内でランダムな時間だけ待機した後，小テストの解答を送信し，レビュー・ページ（採点結果等）を受信する．

(8) 各スレッドは 60∼120 秒の間でランダムな時間だ
け待機した後，Moodle からログアウトする．

• OS: CentOS 7.7 1908
バックエンド側のデータベース・システムは，現行の Moodle システムのものをそのまま利用している．
システムは 2 台のデータベース・サーバから構成さ
れ，マスタとスレーブが明確に区別されている．SQL

上記 (3) 及び (6) の処理では同期タイマ（Synchro-

クエリはマスタ DB サーバにおいて処理される．まnized Timer）を使用した．同期タイマが設置された

た，データベース・システムでは，相互監視デーモン箇所では，指定された数のスレッドがその箇所に到着（keepalived）を用いたフェイルオーバーの仕組みを導するまで待機し，その数のスレッドが一斉に次の処理入している．

を開始する．本研究ではすべてのスレッドの到着を待ち合わせ，一斉に次の処理に進むように設定した．学生が受験開始ボタンをクリックする時刻のばらつきは最大 5 秒と仮定した．学生による解答の送信は試験終了時刻の直前に集中するが，混雑等のトラブルを予想して早めに解答を送信する学生もいると考えられる．
そのため，解答送信時刻のばらつきは最大 30 秒と仮定
した．負荷テストに使用した小テストは，多肢選択形式が 5 問，穴埋め形式が 8 問の計 13 問から構成されている．穴埋め問題の解答欄は 31 個であるため，小テスト全体では 36 個の解答欄が配置されている．また，
この小テストではすべての問題が１つの Web ページに一括して表示される．

3 負荷テスト3.1

テスト環境

図 2 に，性能評価に用いたテスト環境を示す．フロ

データベース・サーバの諸元を以下に示す．

• CPU: 8 コア（合計 16.0 GHz 相当）• メモリ: 58 GB• ディスク: 250 GB• ネットワーク・インターフェース: 10 Gbps
• OS: CentOS 7.7 1908
• データベース管理システム: MariaDB 10.3.13• 相互監視デーモン: keepalived 1.3.5
また，仮想サーバの基盤となるブレード・サーバの諸元は次の通りである．

• CPU: Intel Xeon E4-24700 2.3 GHz（8 コア）×2• メモリ: 128 GB• ディスク・インターフェース: FC-SAN 8 Gbps
• ネットワーク・インターフェース: 10 Gbps
• 仮想化ハイパーバイザ: VMWare ESXi 5.5.0

ントエンド側の Web システムは，1 台のプロキシ・

プロキシ・サーバ及び Web サーバは，2 台のブレーサーバ及び 3 台の Web サーバから構成されている．

ド・サーバに分散配置されている．各々のブレード・

クライアント PC では，JMeter がテストプランに従っ

サーバでは他のシステムも動作しているため，それら

MaxRequestWorkers

150

MaxConnectionsPerChild

0

続いて，Lighttpd における主要なパラメータ値を以下に示す．

server.max-keep-alive-idle

3

server.max-keep-alive-requests 16
server.max-read-idle

60

server.max-write-idle

360

最後に，nginx における主要なパラメータ値を以下に示す．

図 2: テスト環境

keepalive_timeout

5

client_header_timeout

60

client_body_timeout

60

reset_timedout_connection onの仮想サーバとの間で相互排他的にブレード・サーバのリソースを利用する．データベース・サーバは 1 台のブレード・サーバに配置され，この 2 台の仮想サー
バのみでブレード・サーバを占有している．

send_timeout

60

fastcgi_connect_timeout

10

fastcgi_read_timeout

60

fastcgi_send_timeout

360

テスト環境で使用した各種ソフトウェアのバージョン等は，JMeter 5.0.2，HAProxy 2.0.6，PHP 7.4.3，

これらのパラメータ値は，負荷テストを通じて，応及び Moodle 3.8.2 である。Web サーバ 1 台あたりの答時間が小さくなるように試行錯誤的に調節した結果

最大接続数は 500，プロキシ・サーバの最大接続数はとして得られたものである．

2000 とした．

3.2

テスト結果

HTTP サ ー ビ ス・ソ フ ト ウ ェ ア と し て Apache

小テストの同時受験者数の影響について把握するた2.4.6 [12]，Lighttpd 1.4.54 [13]，及び nginx 1.16.1 [14]め，JMeter のスレッド数を変動させながら負荷テスを使用し，これら 3 種類の HTTP サービス・ソフト

トを実施した。プロキシ・サーバが負荷分散の対象とウェアの性能を比較した．また，PHP の実行形態とするサーバ数を変更することにより，サーバ数の影響して PHP FPM（FastCGI Process Manager）を採用についても計測した．Web サーバごとの最大接続数

し，Web サーバごとに起動可能な PHP の最大プロセ

を 500 としたため，サーバが 1 台のときは，スレッド

ス数は 300 とした．

数が 500 以下の範囲のみ計測した．また，今回の負荷

Apache MPM（Multi Processing Module）にはい
くつかの種類が存在するが，今回は event を採用した．
また，Apache の設定における主要なパラメータ値をテストでは 10 回の負荷テストにおける計測結果の平均値をグラフに示している．
図 3 及び 4 はそれぞれ，スレッド数の変動に対する平均応答時間を示している．ここで応答時間とは，ス以下に示す．

レッドが解答を送信してからレビュー・ページ（採点結TimeOut

60

果等）を受信するまでに経過した時刻である．多人数

KeepAliveOnが一斉に小テストを受験する状況においては一般に，MaxKeepAliveRequests

1000

受験する学生ユーザへの応答時間を一定の範囲内に収KeepAliveTimeout

5

めることが求められる．JMeter は受信したコンテン

StartServers

10ツの解釈や画面への表示は行わないが，実際の Web

MinSpareThreads

50

ブラウザでは，コンテンツの解釈と表示に要する処理

MaxSpareThreads

50

時間が応答時間として加算される．本稿では，Web ブ

ThreadLimit

64

ラウザの処理を含む応答時間の上限を 10 秒，Web ブ

ThreadsPerChild25

ApacheLighttpd
nginx

0

100

200

300

99 percentile response time [sec]Average response time [sec]

5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5
0.0

400

500

600

5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5

ApacheLighttpd
nginx

0.0

700

0

100

Number of threads

100

200

300

400

500

400

500

600

700

図 5: スレッド数に対する 99% 応答時間（1 サーバ）

99 percentile response time [sec]Average response time [sec]ApacheLighttpd
nginx

0

300

Number of threads

図 3: スレッド数に対する平均応答時間（1 サーバ）
5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5
0.0

200

600

700

5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5

ApacheLighttpd
nginx

0.0
0

Number of threads

100

200

300

400

500

600

700

Number of threads

図 4: スレッド数に対する平均応答時間（3 サーバ）

図 6: スレッド数に対する 99% 応答時間（3 サーバ）

ラウザにおける処理時間を 5 秒と仮定した．従って，ワップ領域（仮想ディスクの一部）が使用される．ス

JMeter における応答時間の上限は 5 秒とした．

ワップ領域のアクセス速度はメモリに比べて極めて低

図 3 及び 4 より，すべての HTTP サービス・ソフ

速であるため，スワップ領域を使用しているプロセス

トウェアに共通した傾向として，スレッド数の増加にが増加すると，Web サーバの応答時間は著しく増加

伴い，平均応答時間は増加する．

する．今回の負荷テストでは，小テストの問題文及び図 3 より，Web サーバが 1 台の環境下においては，

選択肢はテキスト情報のみで構成されている．図表な

スレッド数が 300 を超えると平均応答時間は急激に増

どの画像情報を含む小テストを使用する環境において加する．これは，今回のテスト環境では PHP FPM

は，さらに記憶容量の大きなメモリが必要になる．

の最大プロセス数を 300 に設定したためである．例え

図 3 及び 4 より，3 種類のサービス・ソフトウェア

ば，400 個のスレッドから一斉に HTTP リクエストが間では平均応答時間に大きな差異は見られないことが送信された場合，300 個のリクエストについては即座示された．ただし，Lighttpd は Apache 及び nginx にに処理が開始されるが，残りの 100 個のプロセスにつ比べてグラフのゆらぎが小さい．これは，Lighttpd はいては処理を待機する状態となる．そのため，スレッ

他の 2 つのサービス・ソフトウェアに比べて負荷テス

ド数が 300 を超えると応答時間は著しく増加する．

トの各回における応答時間のばらつきが小さいためで

PHP FPM の最大プロセス数を大きな値に設定するある．

ことにより，スレッド数の増加に伴う応答時間の増加

図 5 及び 6 はそれぞれ，スレッド数の変動に対するを抑制することが出来る．ただし，同時に起動可能な

99 パーセント応答時間を示している．ここで 99 パー

プロセス数の増加は，Web サーバのメモリの不足をセント応答時間とは，各スレッドにおける応答時間を招く恐れがある．今回のテスト環境では，Web サーバ

サンプル値とした場合の 99 パーセント値である．理の仮想メモリは 4GB としている．接続スレッド数が論的な最大応答時間は，最小応答時間 （システムの300 を超えると Web サーバの仮想メモリが不足し，ス

サービス時間に相当）と学生数（負荷テストにおいてMaximum / 99 percentile response time

Maximum / average response time

5.0

ApacheLighttpd
nginx

4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5
0.0
0

100

200

300

400

500

600

5.0

ApacheLighttpd
nginx

4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5
0.0

700

0

100

Number of threads

1.0
0.5
0.0
100

200

300

400

400

500

600

700

図 9: スレッド数に対する最大-99% 比率（1 サーバ）
Maximum / 99 percentile response time

Maximum / average response time

ApacheLighttpd
nginx

0

300

Number of threads

図 7: スレッド数に対する最大-平均比率（1 サーバ）
5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5

200

500

600

700

Number of threads

5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5

ApacheLighttpd
nginx

1.0
0.5
0.0
0

100

200

300

400

500

600

700

Number of threads

図 8: スレッド数に対する最大-平均比率（3 サーバ）

図 10: スレッド数に対する最大-99% 比率（3 サーバ）はスレッド数）を乗算した値である．テスト環境におPHP の最大プロセス数を 300 に設定したためである．

ける最小応答時間は 0.5 秒程度であったため，例えば，

図 3∼6 より，サービス・ソフトウェア間では応答時間

スレッド数が 500 のときの最大応答時間は 250 秒程度に大きな差異は見られないことが示された．ただし，となる．実際のシステムにおける最大応答時間は，ま

平均応答時間に関する計測結果と同様に，Litghttpd

ず，学生間での解答送信時刻の重複度合いにより，最は他のソフトウェアに比べて各回の負荷テストにおけ

小応答時間から理論的な最大応答時間の間のさまざまる応答時間のばらつきが小さいことが分かった．

な値をとり得る．この値に，その時々におけるネット

続いて，応答時間のばらつきについて考察する．図

ワーク転送の遅延時間，及び他の仮想サーバの影響に7 及び 8 は，スレッド数の変動に対する最大-平均比率

よるリソース割り当ての待ち時間などが加算されるたの特性を示している．ここで最大-平均比率とは，最大め，正確な計測・予測は困難である．そのため，本稿応答時間を平均応答時間で除した値である．

では 99 パーセント遅延時間を性能の指標とした．

図 7 及び 8 より，すべてのサービス・ソフトウェア

図 5 及び 6 より，すべてのサービス・ソフトウェアに共通の傾向として，最大-平均比率はスレッド数のに共通した傾向として，スレッド数の増加に伴って 99

増減の影響を受けにくいことが分かる．ただし，Webパーセント応答時間は増加する．99 パーセント応答時

サーバが 3 台の環境下では，1 台の時に比べてテスト

間が 5 秒未満の範囲で最も大きなスレッド数を最大収毎の計測値のばらつきが大きく，グラフのゆらぎが大

容人数と仮定すると，いずれのサービス・ソフトウェ

きい．各々の Web サーバにおける HTTP リクエスト

アにおいても，サーバ数の増加に伴って最大収容人数の処理時間には，その時々の負荷状況や他の仮想サーは増加する．

バとのリソースの競合などにより，ばらつきが生じる．

図 5 より，平均応答時間に関する計測結果と同様に，処理時間のばらつきは，サーバ数の増加と共に顕著とWeb サーバが 1 台の環境下においては，スレッド数がなる．特にスレッド数（同時利用者数）が多い場合に300 を超えると応答時間が著しく増加する．これは，はサーバ間で処理の進行状況の差が大きくなるため，

毎回の負荷テスト毎の応答時間のばらつきが大きくなの維持に伴う CPU 負荷の増加やメモリの消費を抑制

る．ただし，サービス・ソフトウェア間の比較においすることができ，Web サーバの性能を改善することがては，Lighttpd は最もグラフのゆらぎが小さく，毎回できる．今回の負荷テストにおいても，タイムアウトの小テストにおいて安定した性能を提供していること

時間が大きすぎる場合には応答時間の増加，及び収容が分かる．

可能人数の減少が生じた．ただし，KeepAlive のタイ

図 9 及び 10 はそれぞれ，スレッド数に対する最大-

ムアウト時間を小さく設定した場合，低速あるいは不99% 比率を示している．ここで最大-99% 比率とは，安定なネットワーク環境からシステムに接続している

最大応答時間を 99 パーセント応答時間で除した値でクライアントにおいては頻繁にコネクションの切断とある．

再接続が行われる．そのため，一部の学生においては

図 9 及び 10 より，共通の傾向として，スレッド数の応答時間が増加する恐れがある．

増加に伴い，最大-99% 比率はスレッド数の増減の影

今回の負荷テストに用いたサービス・ソフトウェア

響を受けにくいことが分かる．また，最大-99% 比率の中では，Lighttpd を採用した場合に，計測結果のばは最大-平均比率に比べて小さい値となるものの，Web

らつきが最も小さくなることが示された．そのため，サーバの台数の増加に伴い，毎回の計測値のばらつき

Lighttpd は他のソフトウェアに比べ，性能の予測やパが大きくなる．

ラメータの調節が容易である．

図 7∼10 より，サービス・ソフトウェア間では応答

また，サービス・ソフトウェアのパラメータ値の時間のばらつきに大きな差異は見られないことが示さ

調節においては，Lighttpd は他のソフトウェアに比れた．また，Web サーバ数の増加に伴い，スレッド間，

べてデフォルト値からの設定変更，及び設定項目のすなわち学生間での応答時間のばらつきが大きくなる

追加が少なかった．今回の負荷テストにおいては，ことが示された．試験等において受験者全体により公「server.max-keep-alive-idle」の値を変更したのみで，平なサービスを提供するためには，Web サーバの台数

他のソフトウェアと同等の性能を示した．システム管を増やすより，Web サーバあたりのスペックを向上

理者が Lighttpd を用いて Moodle 用 Web サーバを構させるほうが望ましい．ただし，少数の Web サーバ

築する場合，この値に加え，サーバのスペックに応じにリソースを集中させることは耐障害性の低下につなて最大接続数を調節すれば良い．

がるため，システム管理者はサーバごとのスペックとサーバ数のトレードオフに留意しなければならない．

4 まとめ

本節で得られたテスト結果より，今回のテスト環境

本稿では，多人数が一斉に小テストを受験する際のにおいては，小テストの回答を送信する際の応答時間負荷に着目し，各種 HTTP サービス・ソフトウェアのは HTTP サービス・ソフトウェアの種類には左右さ性能を比較した．HTTP サービス・ソフトウェアの性れないことが示された．Web サーバにおいて小テス

能を評価するためのテスト環境を構築し，JMeter をトの解答の受信，正誤の判定，受験記録のデータベー

用いた負荷テストを実施した．負荷テストに際し，一スへの書き込み，及びレビュー・ページの生成といっ

斉小テストの動作をシミュレートするためのテストプた一連の処理を行う場合，PHP プロセスにおける処理

ランを作成した．HTTP サービス・ソフトウェアとし時間が応答時間の大半を占める．そのため，小テストて，Apache，Lighttpd，及び nginx を使用した．3 種の応答時間に最も大きく影響するパラメータは，PHP類のソフトウェアを Moodle の Web サーバとして採FPM の最大プロセス数である．Web サーバにおいて用して負荷テストを行い，それらの性能について比較

CPU のコア数を増強し，PHP FPM の最大プロセスした．

数を大きく設定することによって応答時間の軽減を図

負荷テストの結果より，各々の HTTP サービス・ることが出来る．ただし，PHP の同時稼働プロセス数

ソフトウェアのパラメータが適切に設定されているの増加はメモリの不足の原因となるため，同時利用者

場合には，ソフトウェアごとの性能の差はわずかであ数が多い環境においてはメモリの増強も必要である．

ることが示された．本稿ではいずれのサービス・ソフ

HTTP サービス・ソフトウェアのパラメータの中でトウェアにおいても，PHP FPM を採用した．PHP

は，KeepAlive のタイムアウト時間が Web サーバのFPM では，PHP の処理を担当するサービスが OS 上

性能に最も大きな影響を与える．タイムアウト時間をに常駐しており，HTTP サービスと分離されている．

小さく設定すれば無駄なネットワーク・コネクション

多人数による一斉小テストのように PHP における処理時間が長い用途においては，PHP プロセスの処理時

dle の構築および運用評価.」，日本ムードル協会全間が応答時間の大半を占める．そのため，特に PHP

国大会（2018）発表論文集，pp.41–47 （2018）.

FPM を採用している環境下においては，HTTP サー[8] 浜元信州 他，「クラウドを利用したログ解析環境

ビス・ソフトウェアの違いによる性能の差が小さくの Moodle への適用」，日本ムードル協会全国大会

なる．

（2019）発表論文集，pp.24–31 （2019）．

それぞれのサービス・ソフトウェアにおいて応答時[9] 王躍 他，「Moodle 小テスト時の負荷シミュレー

間が小さくなるようにパラメータ値の調節を行った場

ションテスト」，情報処理学会研究報告，vol.2010-

合，Lighttpd が最もパラメータの変更箇所が少なかっ

IOT-10，no.11，pp.1–5 （2010）．

た．また，負荷テストにおいては 10 回のテストの平[10] 王躍 他，「OSS に基づいた Moodle サイトのス

均値を性能として示したが，Lighttpd は各回のテスト

ケーラビリティに関する報告」，情報処理学会研究における応答時間のばらつきが小さく，最もグラフの報告，vol.2011-IOT-14，no.2，pp.1–5 （2011）．

ゆらぎが小さかった．そのため，Lighttpd は他のサー[11] S. Chauhan et al.，「Exploiting Moodle Perfor-

ビス・ソフトウェアに比べ，性能の予測やパラメータ

mance under Various Configuration」，Innovativeの調節が容易であることが分かった．

Systems Design and Engineering，vol.7，pp.1–6

前述したように，HTTP サービス・ソフトウェアの（2016）．

性能が応答時間に与える影響は小さい．ただし，PHP[12] The Apache HTTP Server Project，https://

FPM における最大プロセス数と共に，サービス・ソ

httpd.apache.org/ （2020 年 9 月 30 日確認）．

フトウェアにおける KeepAlive のタイムアウトの値は[13] Lighttpd – fly-light，https://www.lighttpd.

応答時間の性能にある程度の影響を及ぼす．本稿の執筆段階では，これらのパラメータが Web サーバの性能に及ぼす影響についての詳細な調査・考察は出来ていない．今後の課題として，それぞれの HTTP サー
ビス・ソフトウェアにおけるパラメータ値の影響についての詳細な調査が挙げられる．

参考文献[1] Moodle: Open-source learning platform，https://moodle.org/ （2020 年 9 月 10 日確認）．
[2] 齊藤智也 他，「小テストの負荷に着目した Moodle
用データベース・システムの構築および性能評
価」，日本ムードル協会全国大会（2020）発表論文
集，pp.15–21 （2020）.

[3] Performancerecommendations,

https://docs.moodle.org/39/en/Performance_
recommendations （2020 年 9 月 30 日確認）．
[4] Apache JMeter，https://jmeter.apache.org/（2020 年 9 月 10 日確認）．

[5] JMeter

test

plan

generator，https://docs.moodle.org/37/en/JMeter_test_
plan_generator （2020 年 9 月 30 日確認）．
[6] M. Manzo，「Design and Performance Evaluationof a Virtualized Moodle-based E-Learning Environment」，Journal of E-Learning and Knowledge
Society，vol.12，no.3，pp.19–30 （2016）．
[7] 桑田喜隆 他，「パブリッククラウドを使った Moo-net/ （2020 年 9 月 30 日確認）．
[14] nginx，https://nginx.org/ （2020 年 9 月 30
日確認）．