このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

NetPresenz vs Rumpus

発言者:田中求之
( Date Saturday, June 28, 1997 17:29:25 )


NetPresenz 4.1 と Rumpus 1.1d を使って、パフォーマンスの比較テストを行い
ました。結果は Rumpus の圧勝。

また、NetPresenz がバックで走っていると Web サーバーにも影響を及ぼすことが
確認されました。

====

§0:テスト環境

転送に用いたファイルは 6237580 bytes のテキストファイル

サーバーマシン: Centrice650 + MacOS 7.6J + OpenTransport 1.1.2

テスト前に、ハードディスクのイニシャライズおよびシステムのインストール
を行っておいた。Disk Cache は 1024K に設定。仮想記憶はオフ。各FTP サー
バーは、デフォルトのメモリー割当てにて運用。

クライアント: Sun ワークステーション (SunOS (UNIX))

学内 LAN で結ばれているが、サブネットが異なり、ルーターを経由して接続さ
れることになる。


NetPresenz, Rumpus ともに、登録ユーザーの資格でログイン
( Rumpus は Built-in Security によるユーザー登録)


§1: FTP サーバー単独で運用の場合

→ FTP サーバーのみを走らせ、それをフロントのアプリケーションにしておく

●サーバー→クライアント転送 (get)

NetPrezenz -> Sun
  6237580 bytes received in 40 seconds (1.5e+02 Kbytes/s)
  6237580 bytes received in 40 seconds (1.5e+02 Kbytes/s)

Rumpus -> Sun
  6237580 bytes received in 27 seconds (2.3e+02 Kbytes/s)
  6237580 bytes received in 27 seconds (2.2e+02 Kbytes/s)

●クライアント→サーバー (put)

Sun -> NetPresentz
  6237580 bytes sent in 49 seconds (1.3e+02 Kbytes/s)
  6237580 bytes sent in 47 seconds (1.3e+02 Kbytes/s)

Sun -> Rumpus
  6237580 bytes sent in 33 seconds (1.8e+02 Kbytes/s)
  6237580 bytes sent in 34 seconds (1.8e+02 Kbytes/s)


§2:バックグランドでの運用

→ Quid Pro Quo を表で走らせ、これに対して Pounder II によって1秒間隔
で同時に10コネクションのアクセスを繰り返し行う。この状態で、FTP サー
バーをバックグランドアプリケーションとして動かす。
(Pounder II は FTP サーバーとは別のマシンにて走らせた)

●サーバー→クライアント (get)

NetPresenz -> Sun
  6237580 bytes received in 94 seconds (65 Kbytes/s)
  6237580 bytes received in 93 seconds (66 Kbytes/s)

Rumpus -> Sun
  6237580 bytes received in 58 seconds (1e+02 Kbytes/s)
  6237580 bytes received in 55 seconds (1.1e+02 Kbytes/s)

●クライアント→サーバー (put)

Sun -> NetPresenz
  6237580 bytes sent in 93 seconds (66 Kbytes/s)
  6237580 bytes sent in 98 seconds (62 Kbytes/s)

Sun -> Rumpus
  6237580 bytes sent in 55 seconds (1.1e+02 Kbytes/s)
  6237580 bytes sent in 57 seconds (1.1e+02 Kbytes/s)


特記事項: NetPresenz をバックグランドで動かしていると、QPQ に対する 
Pounder II のアクセスにおいて、46%の割合で Can't open のエラーが発生
しアクセスに失敗する(NetPresenz が処理を行っていない状態でも Can't 
Open エラーは発生)。


田中求之 さんからのコメント
( Saturday, June 28, 1997 17:43:23 )

§2のバックグランドでのテストにおいて用いた QPQ は v1.02 です。また、
Server Configure において、MultiTasking の設定を Interval, Sleep
ともに More Neighborly いっぱいに設定して(つまり、パフォーマンスを落と
して、他のアプリケーションに処理時間を分け与える)テストしました。


たまちゃん さんからのコメント
( Sunday, June 29, 1997 00:05:10 )

田中さんへ:

詳細なテスト有り難うございました。特にWeb サーバーに与える影響について
結果が得られたのが貴重だと思います(Built-in Securityによらない従来の
ユーザー認証方法でも結果はほぼ変わらないのでしょうね)。本家のMaxumも数
字を挙げては説明していなかったはずです。

ところで、RumpusでBuilt-in Securityや利用者&グループによるユーザーの設
定をして試していたところ、認証自体は問題ないのですが、見えてはいけない
はずのフォルダーが見えたりしました。UNIXのシェルから確認したところ、
パーミッションがぐちゃぐちゃになっていました。全く同じ設定でNetPresenz
で試したところ、見えてもいいフォルダーだけが見えて、問題は起こりません
でした(NetPresenzはもちろん利用者&グループによる設定です)。

多分、私の設定方法のどこかがおかしいのだと思いますが、私1人がftpサー
バーを使うだけだから、まあいいやと思って相変わらずNetPresenzを使い続け
ています。

しかし、Rumpus圧勝のテスト結果をみて、フムフムと頷いたのと、きちんとテス
トをしてくださった田中さんに改めて敬服いたしました。


田中求之 さんからのコメント
( Sunday, June 29, 1997 01:19:40 )

>ところで、RumpusでBuilt-in Securityや利用者&グループによるユーザーの設
>定をして試していたところ、認証自体は問題ないのですが、見えてはいけない
>はずのフォルダーが見えたりしました。

ユーザーの管理の部分に、まだバグが残っている感じですね。Drop Folder (あまり
よい名称とは思えませんが)のような便利な機能がついたり、独自にユーザー管理を
行うようになったため、何らかの問題が生じてしまったのでしょう。正式版までには
解決されると思いたいですね。

私自身も、これまで漠然と感じていた、NetPresenz が Web サーバーに影響を
与えるということを、きちんと確認できたのは収穫でした。しかし、あそこまで
多くの Can't Open のエラーが出るとは思いませんでしたが(実際、 QPQ の
Ststus を見ていても、Rumpus の時との処理の違いは明らかにわかります)。

リース切れ放出の Centrice 650 が整備のために研究室に来ていましたので、
テストが行えたのでした。やはり、純粋にテストに使えるマシンがあるのはいいなぁ
としみじみ思いました( C650 も来週には、私の手を離れる)。

arame さんからのコメント
( Thursday, July 03, 1997 15:05:53 )

こんにちは。
以前FMプロとWebsterの連携でお世話になったarameと申します。
その後、順調だったのですがftpサーバが思うように動かず、再度お尋ねさせて
頂くことにしました。
(しばらく見ないうちにすごくかっこいいデザインになっていたので驚きました。)
今は、NetPresenz4.01を使っているのですが、fetch等でファイルを転送すると
文字化けしてまうため、田中さんのFTPd用のコメントの所にあるパッチをあてた
のですが、もう既に、文字化けして転送されたファイルを読めるようにする方法
はないのでしょうか?
それから、上記コメントにある、Rumpasは、sjis転送時の文字化けといったこと
は起きないのでしょうか?


田中求之 さんからのコメント
( Thursday, July 03, 1997 15:41:34 )

Rumpus はテキスト転送の際に文字化けを起こしたりしません。すなおにテキストの
データをそのまま送りだします。

NetPresenz(FTPd) によって文字化けが起こってしまうのは、データを送りだす際に
サーバーが ISO8859-1 コードに変換してしまったのが原因ですから、文字化けした
データをもとに戻すのは、ISO->Mac の逆のコード変換を行えばよいことになります。

Tanaka's osax をインストールした状態で

set dx to choose file
set myData to readFromFile dx
set myData to L1ToMac myData
set df to new file
writeToFile myData to df

というスクリプトを走らせて、文字化けしてしまったファイルを選んでもらえば
逆変換を行った結果を新しいファイルに保存し直せるはずです。