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

MacPerlの速度

発言者:ちゅん
( Date Monday, March 27, 2000 15:42:22 )


初めて参加させていただきます。
AppleShare IPとMacPerlの情報を求めて流れ着きました。

先日、社内ローカルネットワーク上のサーバーをNT+IISから、Mac OS 9+AppleShare IP
に置き換えました。
社内HTTPサーバーとしても使用しているのですが、ファイルサーバーしての側面もあり、
簡単な設定でAppleShare,Windows SMB,FTPにてファイルの共有が実現できる環境に魅力
を感じての乗り換えです。

置き換えてみて驚いたのは、信じられないくらいのcgi(Perlです)の遅さです。
まるで、テレホタイムにレンタルホストの掲示板に144のモデムで接続した時のようです。
とても、100BASEで構築されたローカルネット上のサーバーで実行されているとは思えま
せん。
決してアクセス過多というわけではなく、テスト期間中私一人が独占使用しても遅いです。
ただ、ページの表示やファイルコピーが遅いわけではないので、MacPerlの実行速度に問
題があるように思えます。

社内掲示板として使用しているスクリプトに問題があるのかと思い、幾つか移植の上、確
認してみましたが、いずれも耐えられない速度でした。
MacPerlをMacJPerlに変えたり、アプリケーションメモリを増やしてみたりしましたが、
効果ありませんでした。

G3やG4でこそありませんが、サーバーマシンのスペックは、決して低くはありません。
CPU:604e×2,メモリ:152M,ディスク:UltraWideSCSI Cheetah×2のソフトRAID,
100BASE-T といったところです。(正体はUMAXの互換機です)
今まで使用していたNTサーバーと比較すると、明らかに上のスペックだと思うのですが..。

MacサーバーでPerlによるcgiを実行する速度ってのは、「コンナモン」なんでしょうか?
こうして情報を漁ってみますと、68k-Mac時代からMacPerlを使ったMacサーバーが動いてい
たような事例が幾つも出てきます。
だとすると、この速度はどうしても納得できないのです。

どなたか、こんな私の気持ちをスッキリさせてくれるコメントをお願いします!!

田中求之 さんからのコメント
( Monday, March 27, 2000 16:13:51 )

NT と比較したことはないのですが、おそらく MacPerl の実行速度が速くない
のは事実でしょう(少なくとも UNIX 系の OS での実行速度とは比較にならない
部分がありますね)。

>68k-Mac時代からMacPerlを使ったMacサーバーが動いてい
>たような事例が幾つも出てきます。

インターネットのサーバーであれば、回線の速度など他の要因によって、
CGI の実行速度の遅さがボトルネックとして出てこないということがある
わけです。サーバ側でどんなに高速で処理が行われても、ユーザとの間の
接続が遅ければ、その「速さ」は活きませんよね? 同じように、「遅さ」も
影響しないことがあるわけです。

しかし、イントラネットで使用する場合には、回線の速度による制約がなく
なるため、サーバソフトウェアのパフォーマンスや CGI の処理速度が、
サイトのパフォーマンスにモロに影響します。ですから、Perl の実行速度
の違いがはっきりと出てくることになりますし、ボトルネックになるわけ
です。

ちゅん さんからのコメント
( Monday, March 27, 2000 17:08:26 )

早速のコメントありがとうございます。

やっぱし、どうしょうもないんでしょうかねえ...。
ガックリ。

Mac OS X Serverも検討したんですが、サードパーティカードどっさりのUMAXでは、
X Serverは動かないでしょうし、そうなると「お蔵入りになってるこのマシン」を
活用するという乗り換えのもう一つの理由を失ってしまうのです。

Linuxを使うとしたら、Mac互換機よりも元NTサーバーに使ってたCompacの方が安
心できますし..。嗚呼、可哀想なUMAX..。

田中求之 さんからのコメント
( Monday, March 27, 2000 17:17:57 )

Perl の CGI の実行速度を優先するということでしたら、Web サーバとして
WebTen を導入するという方法もあります。こちらは UNIX + Apatch 環境
の Web サーバが動きますから、Perl CGI の実行は速いと思います。
Perl で配付されている CGI などでは MacOS では WebTen での実行のみ
サポートすることになっているものもあります。

そこまでのコストをかける意味があるかどうかの判断次第でしょうが。

→  WebTEN (オープンテクノロジース)

稲垣 さんからのコメント
( Monday, March 27, 2000 17:51:48 )

 利用目的次第ですが、該当のcgiをPlug-inやAppleScript製、その他アプリ
ケーションのもので利用してみるのではどうでしょうか?
 Plug-inはWebSTARのものが利用できます。また、AppleScriptもそれなりに
速度がでます。
#個人的な体感では明らかにMacPerlより早かったです。
##まあ、行わせている処理によりますけどね・・・。

 また、ここでBBSで利用しているcgiは、Plug-in版とAppleScript版があり
ます。Plug-in版しか利用していませんが、結構な速度が出ているかと思い
ます。


一休 さんからのコメント
( Monday, March 27, 2000 17:53:36 )

今は使ってないのですが、以前 Power Mac 9500 (604/120Mhz) 上で Quid Pro Quo + Mac Perl 
で掲示板を運営してましたが、メモリ・リークの問題こそあれ、そんなにストレスなく動いてま
したよ。

確かに、本家の UNIX Perl にはかなわないまでも、少なくとも、

> まるで、テレホタイムにレンタルホストの掲示板に144のモデムで接続した時のようです。

ということはありませんでした。
Mac Perl は、改行コードやパス表記などで、移植時に修正もれが出がちなので、そのへんで引
っ掛かっている、ということはありませんか?
または、ASIPのせいなのかなあ…?

→  こんな感じのものが動いてました

田中求之 さんからのコメント
( Monday, March 27, 2000 17:59:07 )

>または、ASIPのせいなのかなあ…?

その可能性はありますね。サーバの実行の優先度をあげると、それだけ
アプリケーション(MacPerl)の実行速度はおちるわけですから。

QPQ とか WebSTAR といったサーバは、1アプリケーションの資格で動く
わけですから、その点で MacPerl と対等に CPU を分け合う資格がある
わけですが、ASIP って、サーバが優先されている環境になっているって
感じがありますね。

おがわまこと さんからのコメント
( Monday, March 27, 2000 18:43:58 )

気になったことを2点ほど

604e×2っていうのは意味がありますか?マルチCPUは
Photoshopじゃないと実力を発揮しないんじゃないでしょうか?

体感的には604eとG3ではかなりの速度差があります.


》「お蔵入りになってるこのマシン」を活用する
のだったら軽いOSにしないと.


もう一つ

OS9上の問題で,AppleScriptが遅いというのがいくつかの情報源で
言われております.もし,これがAppleEventにも影響しているなら.CGIの
起動や値の受け渡し自体がきびしいかもしれません.

ちゅん さんからのコメント
( Monday, March 27, 2000 22:23:58 )

みなさん、コメント、ありがとうございます。

まとめレスで申し訳ありません。

>そこまでのコストをかける意味があるかどうかの判断次第でしょうが。
>→  WebTEN (オープンテクノロジース)

情報ありがとうございます。
早速、見てみました。
うっ!高いですね....。
この金額を追加となると、5万円ぐらいでDOS/V買って、Linux入れて、cgiだけ
専用サーバーにした方がいいかも..。

> 利用目的次第ですが、該当のcgiをPlug-inやAppleScript製、その他アプリ
>ケーションのもので利用してみるのではどうでしょうか?

試しにダウンロードさせていただき、インストールして実行してみました。
最も速そうな、「EasyBBS_PI_1.0b3」で試してみました。
その結果は、ぎょへっ!っとなるほど、速かったです。

>Mac Perl は、改行コードやパス表記などで、移植時に修正もれが出がちなので、そのへんで引
>っ掛かっている、ということはありませんか?

私も、まずそこから疑いました。
で、20本ほどのcgi(Perl)を確認したのですが、どれも同じような状態で
したので、移植ミス..という可能性は少ないと思いました。
かなり、酷使しても動いてますので。

>>または、ASIPのせいなのかなあ…?

全てではないにしても、原因の一つかも知れません。
実は以前、Quadra 900+MacOS8+MacPerlで、ある程度動かしたことがある
のですが、その時の方が早かったように感じます。

使ってみた感じ、ファイル共有のパフォーマンスは、異常に高いので、もし
かすると比重はそちらにあるのかも。

>604e×2っていうのは意味がありますか?マルチCPUは
>Photoshopじゃないと実力を発揮しないんじゃないでしょうか?

そうですよねー。たぶん。
ただ、外しても付ける場所がないので、そのまま2CPUになってます。
例え1CPUしか活用されてなくとも、604e-200MHzなので、同時アクセス
数が10〜20程度のイントラなら大丈夫と思いました。

>》「お蔵入りになってるこのマシン」を活用する
>のだったら軽いOSにしないと.

そうなんですが、ASIP6.3って、MacOS9以降と書かれていたもので..。

>OS9上の問題で,AppleScriptが遅いというのがいくつかの情報源で
>言われております.もし,これがAppleEventにも影響しているなら.CGIの
>起動や値の受け渡し自体がきびしいかもしれません.

一番遅く感じるのは、Perlのcgiアプリケーションが立ち上がるときです。
デフォルトでは、5分経ったら勝手に終了するみたいですね。
その次のアクセスは、ストレスがかかります。

それとおっしゃるようにAppleEventのオーバーヘッドに影響する部分が
大きいように感じました。
素人考えながら、複数の「print」文をまとめたりしたら、速くなりそう
な気がしたのですが、この辺はどうなのでしょう?

自作や移植を含むスケジュールや共用名刺など、掲示板以外にもPerlで
書いたcgiが多数動いており、気が遠くなりつつも「EasyBBS_PI_1.0b3」
の速度に感動したのでお伺いしたいのですが、WebSTARプラグインっての
は簡単に書けるものなのでしょうか?
C++は使えるので、インターフェースが公開されており、かつ簡単そうな
ら、チャレンジしてみても...と思ったりしたのですが。

ちゅん さんからのコメント
( Monday, March 27, 2000 22:24:45 )

↑あ、がぁーーーっと書いてアップしたら、かなり長い文でした。
すいません。

ちゅん さんからのコメント
( Monday, March 27, 2000 22:43:19 )

甘えすぎやなーと自分で思いましたので、WebSTARプラグインのAPIについて、
探してみたら山ほど出てきました。
ちょっと眺めてみます。

前薗 健一 さんからのコメント
( Monday, March 27, 2000 22:54:35 )

W*API は C の知識があるのであれば、難しくはないと思います。
開発環境に CodeWarrior が必要ですけど。

コストをかけたくないのであれば、AppleScript + Tanaka's OSAX という
選択もいいと思います。この会議室でお分かりかと思いますが、速度的にも
遅いとは感じませんから。

→  StarNine Dev

重松修 さんからのコメント
( Tuesday, March 28, 2000 01:47:29 )

ちょっと気になったことがありますので。

print 文をまとめると速くなるか、とのことですが、MacPerl の CGI は
send partial に勝手に対応するのでしょうか?

常識的に考えれば、send partial の仕組みからして、あらかじめデータの
サイズが大きくなるのが明らかな場合を除いて、データをその都度返すのは
単に AE によるオーバーヘッドを増大させるし、その CGI がどの程度の
データを返すのか、MacPerl が予測可能であるとは思えません。

以前、WebSter か QPQ か忘れましたが、いわゆる CGI の 32K 制限が
なくなったというような記述を見たような、見てないような気もする
のですが、この問題は MacPerl ではどう扱われているのでしょうか?
ご存じの方がいらっしゃいましたら、お聞かせ下さい。

それから、UNIX の CGI は呼び出しの都度起動され、データの処理が終わると
終了されます。なので、終了時にはデータをいちいちディスクに
書き戻しり、次回起動時にそれらを読み込まなければなりません。

しかし、MacOS の CGI は AppleEvent で通信するだけですので、メモリに
余裕があれば、毎回ディスクに書き戻すような、そういう書き方をしないで、
メモリ上に保持し、また、この会議室の top ページのように頻繁に
読み込まれるが、更新されるのは書き込みが発生した場合、というような
場合もメモリにキャッシュしておくことで処理の高速化が期待されます。

概ね、CGI が遅いのは、プログラムがタコななだけであって、Mac が遅い
訳ではないし、特に Mac には Mac 独特の事情があり、それを見極めれば
UMAX も全然現役で行けると思いますよ。

田中求之 さんからのコメント
( Tuesday, March 28, 2000 02:30:42 )

Perl の CGI の話とは直接は関係ありませんが…

>この会議室の top ページのように頻繁に
>読み込まれるが、更新されるのは書き込みが発生した場合、というような
>場合もメモリにキャッシュしておくことで処理の高速化が期待されます。

この会議室のトップページは、ファイルに書きだしたキャッシュを使って
高速化しています。ファイルアクセスが遅いのが MacOS の欠点のように
言われますが、この会議室程度のものなら、ファイルに直接アクセスして
も、そんなに遅くないんですよ。

むしろ、HTTP プロトコルにちゃんと対応する(少なくとも CONDITIONAL_GET
と HEAD リクエストには対応する)ことで、不要な処理は極力行わないように
してあることで、LC475 でもそこそこの体感速度が出ている理由ではないかと
思っています。ま、一日、せいぜい1万5千程度のアクセスのサイトですから、
それほどシビアなチューニングは必要ないんですが。

田中求之 さんからのコメント
( Tuesday, March 28, 2000 02:34:33 )

>HTTP プロトコルにちゃんと対応する

CGI のメーリングリストなんかを見ていると、この点に関して気を配っている
ものって少ないような気がしますね。CGI の極意は HTTP を目一杯利用する
ことにあると思うんだけどな…

もっとも、こういうことを気にするのが、「遅い」MacOS ならではのこと
なのかもしれませんけど。

ちゅん さんからのコメント
( Wednesday, March 29, 2000 05:44:02 )

皆さん、いろいろとご指導ありがとうございます。

いろいろと試行錯誤しているうちに、満足..とまではいきませんが、妥協できる
ところまで速くなりました。

やったことは、
・「Web & File Activity」を50%に設定する。
・print文をまとめる。
・「.cgi」を「.acgi」にする。
・AppleTalkをオフにし、ファイル共有はTCP/IP経由のみにする。

ここまでで、体感上、数倍まで速くなりました。
真剣にWebStarプラグインへの移植を覚悟しかけてましたが、やはり、その前にや
れだけのことはやってみるもんですね。
しばらく、この状態で様子を見ようと思います。

ちゅん さんからのコメント
( Wednesday, March 29, 2000 05:50:08 )

>むしろ、HTTP プロトコルにちゃんと対応する(少なくとも CONDITIONAL_GET
>と HEAD リクエストには対応する)ことで、不要な処理は極力行わないように

恥ずかしながら、何もしてませんでした。
このサイトのPDFを見て初めて勉強させていただきました。
ためになります。

後、一本だけ、htmlファイルを書き出して、閲覧時にはcgiが動作しないように
書き直してみたところ、当然のごとく劇的に速くなりました。

MacやPerlのせいにする前に、自分でできることって山ほどあるんです
ねぇ..。

田中求之 さんからのコメント
( Wednesday, March 29, 2000 17:37:54 )

>MacやPerlのせいにする前に、自分でできることって山ほどあるんです
>ねぇ..。

なまじ Perl の実行速度が速い環境だと、ラフな作りでもそこそこ動いて
しまいますからね。処理速度が速いのは七癖隠すってなもんで (^_^;;

言い方を変えると、処理速度の遅さをカバーする方法を自分で工夫する
醍醐味が MacOS の CGI にはあるわけですよ(笑) プライベートのマシンで
ワークスのマシンをぶち抜いてやるっていう、そんな感じ(今風にいうと
ハチロクでランエボに勝つっていうか (^_^;; )ですかね。

ちゅん さんからのコメント
( Thursday, March 30, 2000 02:39:45 )

>ハチロクでランエボに勝つっていうか (^_^;; )ですかね。

マニアックな喩え、ありがとうございます。

あ、最後に、Mac OS 9のマルチユーザーを、Logout+一覧から選択するように
したら、また速くなりました。
マルチユーザーのLogin画面でのキーボード入力待ちも速度低下の一因だったよ
うです。

>言い方を変えると、処理速度の遅さをカバーする方法を自分で工夫する
>醍醐味が MacOS の CGI にはあるわけですよ(笑)

哀しい醍醐味...。

寺港みやび さんからのコメント
( Thursday, March 30, 2000 03:42:39 )

ソケットを使うと、ライブラリをインクルードするだけで
はげしくもたつきますね(^^;)
だからソケットを使う部分だけ別プログラムにして
必要に応じて呼んだりする工夫が気持ちいいでしょうか。
(個人的にはacgiにするとちょっと遅くなると体感してるんですが)

ちゅん さんからのコメント
( Thursday, March 30, 2000 18:38:39 )

>(個人的にはacgiにするとちょっと遅くなると体感してるんですが)

え?そうなんですか?
また、確認してみます。

それとつまらないことなんですが、アップルメニューの「最近使用した...」を
オフにしたら、またちょっと速くなりました。

きむら さんからのコメント
( Tuesday, April 04, 2000 20:32:12 )

MacPerlでのacgiの実行については、アクセスの多いサーバーでは問題となる
ようですのでご注意ください。


→  CGI Programming with MacPerl 移転公開

ちゅん さんからのコメント
( Thursday, April 06, 2000 15:31:22 )

> MacPerlでのacgiの実行については、アクセスの多いサーバーでは問題となる

そうみたいですね。
度々、cgiが止まってしまうので、.cgiに戻しました。
常に5つ以上のcgiが交錯して動くようなサーバーなのでキツいところです。