2004-10-06

Apache のレスポンスの違いから感じたこと

内部向け PukiWiki のサーバを PenIII 800MHz + 256MB + 18GB(Ultra160) + Win2k から Duron 900MHz + 320MB + 40GB(UATA100) + FreeBSD 4.10R に移行した。少しだけどレスポンスが軽くなった。機械の性能的には前の方がいいから、Windows 自体の性能とそのうえでの Apache の性能の違いってことですかな。

ちょっと凝った処理をさせると違いは分からないので PHP のスピードには違いなさげ。まぁプロセッサパワーだけなら同等と言っていいので当たり前か。でも編集 → 再表示などのサイクルは少しだけど確実に差が出る。あと検索が速くなってる。ディスク周りは Windows を載せている機械の方が速いような気がするんだけど、実際にはそういう結果にはならない。プロセスの細かいスケジューリングとか、そもそもデスクトップ環境があるかないかとか、そういう違いがこの辺に出ているのかな。というか NTFS より UFS の方がパフォーマンスいいのか? でも UFS って相当古いよな。

なんかどうもなぁ。

なんかどうも公平じゃないなぁ。まぁでも基本は同じで、

  • 手間
  • お金

どっちかを掛けなければ便利な環境にはならないってことだ。ただし、@IT の記事は記事通りの構成でなくたって「目的」の達成は可能だし、microsoft の情報も、「そもそも勝手にファイルをロックしまくる Windows の仕組みが邪魔くさい」という重要な事実に触れていないのはどうかと。

あと、Windows は工夫しにくい。何かを工夫してちょっと加えるとすごく良くなるってことは日常においてもよくある話だが、Windows ではそのちょっとが許されていなかったり、ちょっとのつもりがすごく大変な手間になったりする。その辺は実際に管理してみないと分からないかもしれないけど。

ただまぁ、その工夫が管理者個人に帰属しまくって外に出てこないとか、そういう問題は伝統的な Unix 方面には多いかもしんない。でもそれは Web の存在が当たり前になる以前からあるノウハウなのでしょうがないのかなぁと思ったり。新しい人がどんどん Wiki などを使って情報を発信しているので、状況は改善されていくと思うし、実際に改善されてきていると感じている。

それに。

何度でも言うけど、Windows のようにライセンス料が発生する上にバージョンが上がったら昔のノウハウが通用しないなんて事態に陥る OS は、長期のランニングコストが高くつく。Unix は初期学習コストは確かに高いが、期間が長くなればなるほどその差は小さくなり、やがて逆転することも十分にあると思う。

パスの長さのへぇ。

pathの長さ

from /.-s (Arch 作者 Tom Lord のインタビュー)

Linux
    NAME_MAX 255 (終端nulを除く1階層の文字数)
    PATH_MAX 4096 (終端nulを含むフルパスの文字数)
Windows
    MAX_PATH 260 (終端nulを含むフルパスの文字数)

Wiki スタイルだとこういうのはうまく引用できないんで pre で。ま、要するに Windows は使えるパスの長さが短いくせに無用に長いフォルダ名を使いたがる困ったシステムだよね、という話。

tree

去年の今ごろも話題にした tree コマンド。FreeBSD では

/usr/ports/sysutils/tree

ほかにも「なんとか tree」というものがたくさんあるが、自分の求めるものはこれ。

X にも tree というコマンドがあるので、そっちが立ち上がる可能性あり。alias とかで逃げること。

Ultr@VNC

書き忘れてたけど、先週の土曜辺りに Win2k でテスト。速い。確かに速い。 OS X からの接続でしか試してないけど、これは速いわ。昔試したとき(と言っても同一のものかどうか分からないんだけど)みたいな不安定な感じはしないし、これいいかも。

ただしタスクトレイのアイコンはもうちょっとかっこよくならんかな。

About

例によって個人のなんちゃらです