2011年5月アーカイブ

なんというか、CentOS界隈が不穏な状況なので、/.に書かれてた

Scientific Linux（6のx86_64）をVMにインストール中。

さほどCentOSとも変わらない（はず）なので、使うにしても困らないかな（Ubuntuみたいに:-）


っても、MacBook (Late 2007)なのでまぁ、それなりのパフォーマンス。

でも、どこか遠くのサーバより近くの仮想環境って感じで、いろいろ役立ってます。


でもねー、UNIX系（純粋じゃないにしても）を触ったのは

Linux　Kernel2.2 ->SunOS 2.6 ->Linux2.4 ->Linux2.6 ->Mac OSX ->FreeBSD

ってな感じでして、実は現在サーバOSとしてお気に入りなのはFreeBSD。

お金かけられるなら今でもSunOS(あー、Solarisだね、２．６とかは)が堅いかなー、

というのはありますが。もちろんSPARC版だけですよ。x8６はわかんない。


FreeBSDは、なんていうのか、ちょっと近寄りがたい雰囲気もありながら、とにかくシンプル。

そしてなによりもPorts。

Linuxってrpm -> yum/apt って感じで、まぁ、いわゆるバイナリをインストールしましょう、

って文化だと思ってて、使いこなせばいいんだろうけど、知識の範囲が狭い印象。

例えると、島国的、村社会的というのか。

たとえばyumを他のOSで使う事はないだろなー、って。

SRPMもあるけど、使った事無いし。（あぁ、それは個人の力量の問題？:-）


それに比べてPortsはソース持ってきてその場でビルド、を比較的お手軽に実現。

yumみたいに提供が遅い感じが全くないし。印象だけど。


また、いくつも似たようなディストリビューションがあって迷っても迷わなくても

結局長いものに巻かれる感じのLinuxに比べて、一枚岩的なのもFreeBSDが

不惑な感じでいいです。


それに、インストールも一瞬で済むしね。


あ、インストール終わったー。つかってみよー！（っておぃ;-）

まだ使ってない、んです。

というか、有効には使えてない、かな。

Redmineは入れてからそこそこ経ちますが、まぁ、有効に使ってる人は使う、
使った事の無い人は使い方がわからないから使わない、
まぁ、そんなものでしょう。

新規じゃなくて改修についてはBugzillaがいい、という話もあり。

じゃ、GWあけにBugzillaも入れてみますか、と自宅環境で検証できたところ。
ほんと、最近のアプリケーションは至れり尽くせりです、楽になったもんだ。


乱立するのは避けたいけど、こっちにしてみればどれでも同じです。

使えるのは使いたいと言った人だけになる可能性大だからね。

入れても使わないのは、教育しないから。

使える人は使うけど、使えない人のサポートまではしない、というのが構造的な問題。

使わない人の理由は、
使い方がわからない、
使うメリットがわからない、
覚えるのがめんどくさい、
というところか。

結局メールか口頭で伝えれば、伝える方はそれでおしまい。だって、伝えたもの。


どっちが悪いってわけじゃないけど、結局使ってほしい人が努力しないと、
使った事の無い人が努力するわけがない。

だって、変化は苦労につながるから。

逆の立場だったらどうでしょう？よくわからない事に時間を使いたくないよね？

その苦労をしてまでも、便利だ、楽だ、良くなった、という実感を想像させる事なく、
新しいプロダクトの導入なんてできるわけがないし、導入しても根付かない。


というわけで、何かを導入したい人は、永遠に続く教育のコストまで含めて
そのプロダクトを導入する価値があるかどうかを判断するべし、と。

さて、このてんまつはどなりますやら。

が、とにかくやってみる事は大事です。

PHPの高速化の手法について改めてまとめてみる。

歴史の長いPHPの高速化手法はいくつかに分かれていて、

１.事前コンパイルしてキャッシュするタイプ
  リクエストの度に実行されるコンパイル時間がオーバーヘッドなので
　　（事前｜初回実行時）にコンパイルして、同時に最適化を行い、
　　それを（メモリ｜ファイル）にキャッシュしておくことで高速化を図る。
　　古今東西PHPではいくつも出ては消えの古典的かつ安定している（と思われる）手法。

２.高速な言語に変換しちゃえ
　　インタプリタで実行じゃなくてコンパイルする言語に変換して実行すれば速くね？
　　というアプローチ。
　　調べると結構あるみたいだけど、寡聞にしてHipHop for PHPくらいしか聞いた
　　事がありません。日本国内での利用実績ってあるのかなぁ？

３.FAST CGI的なアプローチ
  常駐しておけば１.よりも速くね？という、FAST CGIの手法をお借りしてみました的手法。
  まぁ、PHPもFAST　CGIで動くわけですが、それよりも速い、のだろうと思われ。

というのが主な分類かな。

一つの言語でこれだけ多岐にわたる高速化手法が選択できるって、
ステキというかなんというか。。。選ぶの困っちゃうよね。

で、ちゃんとしてるところはもうPHP5.xだと思うんだけど、まだ4.xな環境も
存在するだろうということで、わかる範囲で4.xの対応状況も併記してみる。

ではいってみよー！

１.事前コンパイルしてキャッシュするタイプ

  APC
 　　　3.1.8(release 2011/5/2)はPHP5.1以降をサポート。
　　　 PHP4.xについては3.0.x台は使えた模様。

　　eAccelerator
　　　　0.9.6.1(release 2010/05/31)はPHP5.3/5.2/5.1をサポート
　　　　0.9.5.1(release 2008/5/18)はPHP5.2/5.1/4.xをサポート

　　XCache
　　　1.3.1(release 2010/11/27)はPHP5.3をサポート
　　 １．０系は4.3.x/4.4.xをサポートしている模様だが。。。　

  Zend Optimizer
    本家本元の最適化モジュール。
　　　　５．２までに対応するものは無償でダウンロードできますが、
　　　　5.3以降に対応するものから、ZendServerという有償プロダクトに
　　　　同梱されるものとなりました。（ZendOptimizer+という名称に変更）
　　　　もちろんPHP4.xにも対応。

２.高速な言語に変換しちゃえ

　　HipHop for PHP
　　　　C＋＋に変換する、らしい。Facebookの中の人が作成。

　　quercus
　　　　Java内でPHPを実行できる、らしい。

　　Phalanger PHP compiler
   　　.NETに変換する、らしい。

　　Roadsend
    PHPの別実装らしい。
　　　　FASTCGI向けのバイナリが生成できる、のかな。

　　phc
　　　　PHPのコンパイラ。
　　　　.phpからCのソースを生成して、.so(shared object)を生成できるらしい。

３.FAST CGI的なアプローチ

  GreeFastProcessor(GitHubはこっち)