|
||||||||||||||
| 前のページ 1 2 | ||||||||||||||
| Perlとシステム負荷 | ||||||||||||||
|
ここで一つ「Perlとシステム負荷」について論じてみたいと思います。 最近ではLL、特にPerl/PHP/Python/Rubyで書かれたWebアプリケーションは一般的になりつつあるので、「LLで書かれたシステムは遅い」という、一昔前に言われていた噂(?)も払拭されつつあります。 動的な言語であるLLで書かれたプログラムが、Cなどの比較的静的な言語に比べて速度的に劣る主な原因は、プログラムの起動時のオーバーヘッドが大きいことに起因しています。 例えばPerlは、プログラムの起動時にスクリプトのコードをバイトコードにコンパイルして、その後にインタプリタがプログラムを実行しますので、そのコンパイルにかかる処理の負荷が高くなります。CGIのようにリクエストごとにプログラムの起動と終了を繰り返す実行環境では、このコンパイルフェーズが毎回発生してしまうため、システムへの負荷がどうしても大きくなってしまいます。 そこでこのオーバーヘッドを回避するために、WebアプリケーションではFastCGIやmod_perlなどの実行環境を利用して高速化します。FastCGIやmod_perlを使うと、Webサーバーが起動する際にスクリプトのコンパイルを行い、それをメモリに常駐させて、クライアントからのリクエストに備えるということが可能になります。 これでリクエストごとにコンパイルのオーバーヘッドが生じることはなくなるため、LLで書かれたWebアプリケーションを高速に動作させることができます。 それでもやはり、C言語のようなハードウェアに近い言語で書かれたプログラムに比較すると、同じ処理でもLLで書かれたものは基本的には速度面で劣ることもあります。 ただし、その速度差は、Webアプリケーションのライフサイクルの中でコストの高い他の処理、例えばディスクI/Oやデータベースからのデータの読み込みによる遅延などに比較すると、多くの場合は無視できる程度のものになります。そして、このI/Oなどの負荷はサーバーを増やすことにより分散させることができます。 データベースの場合、どうしても処理が一箇所に集中してしまいがちで且つそれを分散させることが難しく、例えばマスターに搭載された巨大なテーブルを分割するにはクラスタリングなどのアプリケーションに特化したシステム設計が必要になります。しかし、Perlが動く母体であるWebサーバーの負荷を分散させる場合は、基本的に全く同じ処理をするサーバーを追加するだけでよく、その作業はとても容易です。 このような状況下では、コードを極限までチューニングし保守性や開発効率を犠牲にしてまでサーバー1台あたりでの処理能力を向上させるのは得策ではありません。適切なタイミングでサーバーを増設することで、I/Oなど相対的にコストの高い処理をスケールアウトによって分散させ、コードの保守性/開発容易性を保ったまま運用する方が総体的な利益は大きくなります。 優れたLLのフレームワークで開発を行えば、LLの開発効率の高さを生かしつつ保守性の高いプログラムを書くことができるのはいわずもがなです。 保守性の高いプログラムをLLで書き、それをFastCGIやmod_perlなどの実行環境により高速化し、I/Oなど言語レベルで対応できないコストの高い処理は安価なサーバーの追加やキャッシュの導入などによって分散させる。必要以上の最適化は施さずにコードの保守性と開発効率を高く保つ。これが近年のWebアプリケーション開発の一つの形と言えるでしょう。 こうした開発方法に必要な道具となるプログラミング言語と、Apache/lighttpdやMySQLなどの優れたミドルウェアが揃い、且つハードウェアが安価な昨今、PerlなどのLLによるWebアプリケーション開発プラットフォームは、すでに成熟したと言っても良い、というのが筆者の考えです。 |
||||||||||||||
|
前のページ 1 2 |
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||

