先日、７月17日にゲームファン(http://gamesjp.com/)をリニューアルいたしました。
今回は、技術的なことを中心に書いて見ます。
- とにかく高速化したかった！！！
- データベースの見直し
- PHPプログラムの見直し
- PostgreSQLの導入
- js, css ファイルの圧縮
- URL付き投稿の表示について
- iPhone, iPadの対応
目次
とにかく高速化したかった！！！
もともとのリニューアルのキッカケがこれでした。
このグラフは、サーバの負荷を表したグラフです。
上から、CPUの負荷、転送量、HDDアクセスの順になり、下の数字（ 11 ～ 17 ）は、７月11日から17日までの１週間を表しています。
赤線を引いた部分で、グラフに変化が現れていることが確認できます。
ちょどここでリニューアルを実施しており、１日が経過したところのグラフとなります。
Traffic（転送量）はあまり変わらず、CPUとDISK I/Oの負荷が激減しています。
リニューアル前までは、遅いときだとページの表示に数秒かかっていました。
せっかくゲームファンにアクセスして貰っても、こんなに重いとあちこちのページに移動するのも億劫になるはずです。
実際、アクセス解析を見ていても、複数ページに移動するユーザーは少ないです。
今回のリニューアルで、体感的に大きく変わっています。
ページが表示されるまでにちょっと待っていたのが、今はどうでしょう？
http://gamesjp.com/ で体感して頂ければと思います。
サーバでのログベースでも、1秒近かった処理時間が、0.02秒前後にまで抑えることができました。
データベースの見直し
データベースには、MySQLを使っています。
まずは、掲示板部分のテーブルを作り変えました。
テーブル構造自体は、ゲームファンオープンの頃からほとんど変わっておらず、ここを変えるのは冒険的でプログラム変更も多くなってくるので、なかなか機会がありませんでした。
今回、ばっさりとやりかえてます。
といいますのも、webシステムを作り始めて数年。
この間に蓄積されたノウハウ、コード資産はそこそこ持っていますので、
昔できなかったことも今なら容易にできる準備が整っているからでもあります。
PHPプログラムの見直し
まず、コアとなるシステムを入れ替えました。
そのうえで、ゲームファンに組み込んでいく過程で、高速化を目的としてコア部分にも手を加えています。
このシステムは、私の独自開発のもので、作り始めてからもう５年くらい経過し、いろんな種類のwebサイトやwebシステムにも採用しているもので、だいぶ熟成されています。
ちなみに私が公開しているサイトの多くは、このシステムの下で動いています。
リニューアルされたゲームファンは、「ちょっとHTML5」です。
（昔の）IEのこともありますし、あまり純粋なHTML5は避けています。
ということで、XHTMLのstrictをメインとしてきたこのシステムにも、HTML5のサポートを組み込みました。
ETagのLastModified は以前から導入していましたが、ファイルキャッシュの仕組みも変えました。
今回からは、アクセス者個人に関わるデータは、HTMLに含めないことにしました。
これにより、URL単位でページまるごとのHTMLデータをそのままキャッシュできます。
アクセスされたらまずキャッシュファイルの存在を確認し、最新データよりもキャッシュのほうが新しければキャッシュファイルをそのまま出力しています。
これにより、キャッシュが有効期間内であれば大部分のPHP処理、データベース処理が無くなります。
またURL単位のHTMLキャッシュは、ファイルとして保存することでデータベースへのアクセス自体も省きました。
ちなみに、ログイン情報などアクセス者個人に関わるデータの表示は、ajaxでページロード時に動的に書き換えることで対応しています。
PostgreSQLの導入
以前から、MySQL上で、ページのブロック単位のキャッシュを管理していましたが、この部分を PostgreSQL に任すことにしました。
役割分担として、大切なメインの部分はMySQL、失っても構わない（無くても動作に影響を与えない）データを PostgreSQL に置きました。
ちなみに、毎日のバッチ処理として、MySQLの部分は自動的にバックアップを作成しており、かつ、自宅の開発サーバよりSSH接続で最新バックアップを取得し、開発サーバのMySQLを自動更新していたりします。
MySQL内のキャッシュデータが大きくなり過ぎ、この部分の負担を減らすことが目的だったりしますが。。
PostgreSQLを使わずに、MySQL内にもうひとつ別のデータベースを用意する方法ももちろんありましたが、 PostgreSQL にしたのは、 「MySQL以外を使いたかっただけ」 という理由が大きいです。
今になって思えば、NoSQLを試してみても面白かったかなー、なんて思いますが。。。
PostgreSQL でも MySQL でも、キャッシュ保管を目的にするなら、key-value的な仕組みになりますし。。
js, css ファイルの圧縮
javascriptファイル(js)と、CSSファイルは、それぞれ１つのファイルにまとめてコンパクト化した上でgzipしました。
これにより、ページロード時の、jsやcssファイルのサーバへの問い合わせをそれぞれ１回ずつに抑えています。
複数ファイルに分散して記述することは開発効率やコード管理の面で良いのですが、アクセスの高速化という面では得策ではありません。
といっても、開発効率の点も重要ですので、実は、js、cssファイルも目的単位で複数ファイルに分散して記述しています。
それをサーバに設置する直前に１つにまとめているのですが、毎回毎回やってられないですので、このあたりは自動化しています。
いまのメイン開発環境はwindows xpですので、ms-dos でバッチ処理を書いています。
—— ms-dosでの処理
１．日付をセットする （20110717 など）
２．jsファイルのパスの配列を作る
３．cssファイルのパスの配列を作る
３．１と２の配列からファイルを読み込み、それぞれ結合する。
20110717.js と 20110717.css ができます。
４．３で作られたファイルを、yuicompressor に通します。
20110717-min.js と 20110717-min.css ができます。
５．４で作られたファイルを、gzip.exe に通します。
20110717-min.js.gz と 20110717-min.css.gz ができます。
６．サーバにアップします。
サーバへのアップは、SSHのrsyncで、指定フォルダ内の更新されたファイルだけがサーバ上の指定フォルダに上書きされるようにしています。（css, jsの他、htmlや画像ファイル、プログラムも含め）
この、バッチファイルは、開発サーバの更新用と、本番サーバへの更新用の２つ作ります。
（違いは、接続先のサーバ情報程度です）
これにより、開発中は複数のjs、cssファイルに処理内容を分散して、効率よく開発ができますし、アクセス時は１つのファイルだけを参照することでページ表示の高速化の両方を実現しています。
webサーバの設定で、ブラウザが gzip に対応していれば、 20110717-min.js.gz と 20110717-min.css.gz を返し、gzipに対応していなければ、 20110717-min.js と 20110717-min.css が返されます。
ちなみに、 HTMLファイルのheadには、 src=”20110717-min.js” と href=”20110717-min.css” と書いておけば、webサーバが適切なほうを返してくれます。
URL付き投稿の表示について
とりあえずこちらのトピックスのような感じです。
レスNo.１１６あたりからですね。
みんなのおすすめ動画
Youtube、にこにこ動画、画像ファイルのいずれかのURLを投稿内容に含めると、このように展開します。
クリックするとサブウィンドウがでてそのまま視聴・閲覧できます。
これは高速化ではなくちょっとした遊び心というか便利機能に含まれますね。
iPhone, iPadの対応
今回のリニューアルでは、ガラケーサイトは変更していません。
で、iPhone閲覧時は、ガラケーサイトをベースに、javascriptで画面サイズや文字サイズを調整する程度でしたので、今回もそのままです。
ということで、iPadですが、今回は最初からiPadでの表示を意識して作っています。
以前は、微妙なCSSの解釈の違いで崩れていた部分も今回は対処しています。
ただやっぱり・・・wi-fi環境ならまだしも 3G環境では少々遅く感じますね。。。
—————————————
ということで、技術的な部分については、このようなところでしょうか。
こうやって書き出していく過程でも、まだまだ改善の余地があるなーと、新しいアイディアが出てきてます。
いくら考えに考えて実装しても、システムに完成というものはありませんね！
１つ階段を昇ると、新しい景色が見えてくるものです。
そういえば、最初の負荷のグラフですが、いまのところ負荷は減っているにもかかわらず、アクセス数は増えています。
１人あたりのページ移動数も良い感じに変化しています。
こういう見えない部分への投資も大切ですね！
