学術情報処理研究 No.1 1997 pp.72-74

巨大ＵＮＩＸシステムでのネットワークパフォーマンス


山賀 正人


千葉大学総合情報処理センター
千葉県千葉市稲毛区弥生町 1-33
043-290-3544 (Fax 兼), yamaga@ipc.chiba-u.ac.jp


概要

　授業のような同時に多数のクライアントが WWW サーバにアクセスする際に 最も良いパフォーマンスを得るためのプロクシサーバの設定を調べる。

キーワード

プロクシサーバ、マルチプロセッサ、squid

1. はじめに

　現在、インターネットを利用したサービスの中で World Wide Web(WWW) は 電子メールに匹敵する、また場合によってはそれ以上に重要かつ普及度の 高いものになった。 そのような中で大学などのような利用者数の多い組織では、 WWW へのアクセスがサーバやネットワークに多大な負担をかけてしまうという 問題が生じる。 この問題を解決する手段として、アクセス頻度の高い外部データを定期的に 取得して保存するミラーリングの機構や、 一度アクセスした外部データを自組織のサーバに短期間保存するキャッシング の機構が開発され、既に実用化されている。
　しかし、このキャッシング用のサーバ(プロクシサーバ)の運用、 特に各種パラメータの設定は試行錯誤に頼っている場合が多い。 その最大の原因は、WWW の普及があまりに急速であったため 運用の経験が蓄積されておらず、例えばこのようなシステム・ネットワーク構成の 場合はどのような設定が最適であるかを系統的に示すものがないということである。
　また本学では 100人単位の情報リテラシの授業がほぼ全学必修の形で行なわれており、 その授業において WWW を利用する際に 100人同時の外部データへのアクセスが 内部のネットワークやプロクシサーバに多大な負荷を与え、 講義時間を大量にロスしてしまうという深刻な問題を生んでいる。\\ 　このような背景のもとで本発表では、上記教育システムを用いて 授業中のような同時大量アクセスを行なう場合にどのような設定が最高の パフォーマンスを与えるかを調べた実験結果を発表する。 特に注目すべき点は本システムのサーバが CPU を 28個有するマルチプロセッサの マシンであるということ、また本来シングル CPU で動作させることを前提に 作られているサーバプログラムをどのような設定で運用すれば、 このマルチプロセッサの仕組みを有効に生かせるかを調べた点である。

2. 実験

　今回の実験で用いた本学の教育システムは以下のような構成になっている

　　プロクシサーバ・ファイルサーバ CRAY スーパーサーバ CS6400 1 台　
　　　　・60 MHz SuperSPARC × 28
　　　　・1.8 GByte メモリ
　　　　・270 GByte ハードディスク

　　Ｘクライアントワークステーション
　　　CRAY エントリーレベルスーパーコンピュータ EL92 8 台
　　　　・133 MFLOPS × 2
　　　　・512 MByte メモリ
　　　　・ 21 GByte ハードディスク

　　Ｘ端末 230 台

　これらが 10BaseT と FDDI によってネットワーク接続されている。 図1 に構成を示す。




　実験方法として、ある時刻に EL92 上でブラウザ(lynx)が一斉に起動して、 特定の URL にアクセスするように EL92 上の cron に設定し、 プロクシサーバがクライアントから URL を受け取ってからデータを全ての クライアントに渡し終わるまでの実時間をログから調べるという方法を取った。 もちろん実験の際には純粋に本実験のデータのみが取り出せるように利用者などの 全くいない時間帯に行ない、全てのマシンは NTP (Network Time Protocol) を使って 正確に時刻を合わせてある。
　今回の実験ではプロクシサーバのプログラムに squid を用いた。 以前、本システムでは DeleGate を利用していたのだが、 DeleGate ではキャッシュデータやログをそれぞれ単一のディレクトリやファイルで 管理するため、同時に大量のアクセスが行われるとディスクへの IO が ボトルネックとなり、クライアントのうちのいくつかが目的のデータを取得できない ことがあった。 そこで、ポート番号を変えて複数のプロクシサーバを立ち上げ、 各 EL92 に対してそれぞれ処理を分担させる方法を考えた。 もちろん、キャッシュデータやログを蓄えるディスクは それぞれ SCSI ユニットを変え、ディスクへの負荷が分散するようにした。 また複数のサーバプログラムが OS の仕組みとして別々の CPU に割り振られる。 しかし、複数のサーバがそれぞれ同じデータを取得しに行ってしまっては 無駄である。 できればキャッシュデータを共有しあった方が良い。 そこで、プロクシサーバ間でキャッシュデータを共有し合う機能を有する squid を 採用したのである。
　今回はクライアントの数、一斉にアクセスする URL の数、プロクシサーバの数を それぞれ変えて実験を行なった。 ただし、実時間を測定しているので、同じパラメータの実験を複数回(4回)行ない、 その平均値を取ることとした。



3. 結果

　実験結果は Table 1 である。 しかしこの実験結果は著者の予想を裏切るものであった。 著者の予想は次のようである。 URL の数が一つの場合は、プロクシサーバの数が多いとサーバ間の通信が ネックとなるので、プロクシサーバも一つの方がよいであろう。 一方、URL が複数になれば、それに伴ってプロクシサーバも複数であれば良いだろう。 しかし、もちろんプロクシサーバの数が多すぎれば URL やクライアントの数に 関わらず、サーバ間の通信がネックとなって良いパフォーマンスを得ることは できないだろう。 つまり処理の負荷分散とサーバ間の通信負荷とのバランスで最適な値が 分かるのではないかと期待していたのである。 ところが実際には Table 1 に見られるように値にばらつきがあり、 規則性がほとんど見られない。
　なぜこのような結果になったのか理由として考えられる点は以下である。

　このような結果をふまえ、発表ではその後の実験結果を発表する予定である。

Contents Back Next