CakePHP PageSpeedをChromeで使ってみた

よろしくないなあ、と思いつつサイトの高速化という問題から目を背け続けてきたけど、
いい加減やばいんでない？　ということでサイト高速化についてちょこちょこ調べてみた。

参考サイト
・表示が速過ぎても、誰も文句は言いません
・ついに出た！Chrome版「Page Speed」の使い方

しかし、こうやって情報処理的な調べ物をするたびに、
どれもこれも最低限の専門知識を前提として語ってくるのは困る。
正直、なんちゃってエンジニアな自分にはきついなあ、と思うこともしょっちゅう。

PageSpeed

タイトルにもあるので一番に持ってきた。表示速度を調べた上で問題点も調べてくれるのだとか。

さっそくインストールして実行！　なんか色々出てきました。

サイトとは色々違うけどバージョン変わったんかな？　それとも別バージョン入れた？

なんにせよなにがなにを示しているのかはわかるのでオーケー。

色で判断で間違ってないよね？

すぐに対応できそうなのとして、色々画像が凝り固まっている部分をエレメントキャッシュ！

...相変わらずそこで怒られるぞい。CakePHP独自のキャッシュには対応してないのかな？

圧縮とかも試してみよう。

JavaScriptを圧縮しよう！

mod_deflateモジュールなるものが必要とな？

うちのxamppには最初から入っていたみたいなのでそのままゴー。

.htcaccessを弄る。以下の一文を追加。

AddOutputFilterByType DEFLATE text/html text/css application/x-javascript

エラー出たー！５００エラー。

どうやらCakePHPはヘルパーなりコンポーネントなりを使用してjavascriptを圧縮するのが

正しいよう。この結論に自信はありません。

ちょいと調べて出てきたの。

・JSMin Helper

・CakePHPで圧縮しよう！

JSMin Helperが良さそうかな。そのままJavaScript Helperのように使えるとか。

というわけでページからソースをコピペし、jsmin.phpもいただき実行してみた。

オーマイガ。めっさ怒られました。もしかして2.x系には対応していらっしゃらない...？

ソースコードを弄り弄りエラーをひとつずつつぶしていく。

で、なんとか動いた。afterRenderを全部コメントアウトしてみたりしたけど動いた。

PageSpeedにも怒られなくなってちょっとした達成感。

でも大して実行時間が変わっていないような...。

あれ？　なんかミスった？　それとももっと大きいファイルじゃないと目に見える変化がないのか。

要検証。

CakePHP2.x SmartyViewをいじったメモ

大体アプリケーション部分もできてきたのでぼちぼち負荷テストをはじめたんだけど、
どうしてもスループットが出ない。
どこが原因ぞ？　と思い調べてみたらば、RenderringViewが笑える重さを誇っていた。700msて。
で、さらに調べるとSmartyが原因だった。
どこから取ってきたかを忘れたSmartyViewクラスをいじったので、その辺のメモ。

コンパイルを１回こっきりにする

Smartyクラスのcompile_checkにfalseを指定する。

結論から言えばこれだけであっさり早くなったんだけれども、ここにたどり着くまでが大変だった。

最初にこのテストをしたときにソースをさっぱり見ずにやったがためにその後に書いてある

clearCompiledTemplate()の記述に気づかなかった。

こいつのせいでコンパイルチェックを無効にしていても

毎回コンパイルファイルが削除されていたのだ。

そりゃ、そもそもチェックする対象がいなければSmartyもコンパイルせざるをえんでしょう。

こんなくだらないことで１日以上悩んだ。悔しいからメモ。

表示が変わらないページにはページキャッシュを利用しよう

基本的にほとんどのページが動的にデータが入れ替わるので結局見送りになっけんだけども、

せっかく調べたので忘れないうちに。鉄は熱いうちに打て。

ページそのものをキャッシュとしてとっておいてそのページをベーと吐き出してしまう。

ただ、CakePHPを使っていると、ちゃんとキャッシュＩＤを指定してやらないとどのページも

同じだと判断してくれちゃう。どのコントローラ行っても最初に表示したページのままだぞう。

CakePHPはアドレスでページを判別できるのでキャッシュＩＤにも同じように指定してやればいい。

$this->cacheid = $this->params->url;

これでオーケー。ただ、クエリが違うだけのページはやっぱり同じページに...。

本格的に利用するつもりならもうちょい調べる必要がありますかも。

アルゴリズム 選択肢

テキストに引き続き、ノベルゲームで使いそうな選択肢を考える。

基本動作

1. 選択肢を表示する。
2. 選択肢のどれが押されたかを返す。
3. 戻り値を受けとってアプリケーション側がなんかする。

戻り値とアプリケーション側の応答の兼ね合いはどういったものを作ろうとしているかで変わる。

選択肢をどのように使うかが決まっていればあっさり決まるかと。

クラス設計

必要なメンバ変数はなんぞや？

• 選択肢のテクスチャ。文字列とか。
• 選ばれた選択肢。
• 選択肢別の戻り値。

必要最低限。選ばれたの判断は選択時に戻り値を返す関数ならいらないけども。

メンバ関数。

• 選択肢の描画。基本だと背景と文字列はセットになっている。
• 選択肢ごとの当たり判定を取得する。
• 選ばれた選択肢を返す。

これだけあれば基本はできそう。

選択肢単品だけど、中央ぞろえで表示とかそういった機能も実装すると別問題なので、

今回は無視。

でもいじりやすいようにひとつのクラスにまとめておくとよさそう。

jMeter 負荷テストわからないよう

jMeterを使って色々やってみたりしてはいるんだけど、未だに正しい使い方がよくわからない。
現時点で「こういうこと？」と思ったことをまとめてみよう。

いろんなサイトを参考にしつつ。資料集めならサイトに飛んだほうがきっと賢い。
・A Day In The Boy's Life
　ここの負荷テスト関連がわかりやすい。個人的に他のエントリも面白かった。
・TECHSCORE | jMeter
　jMeterの解説が載っている。テストケースの参考もあって大助かり。

webサイトが想定されるアクセス数に対しての負荷に耐えられるか調べる

常に想定数のユーザーがなんらかのリクエストを送っていればいいんだな？

と思って、以下のスレッドグループを作成。

• スレッド数　：　想定される同時アクセス数
• Ramp-Up期間　：　１
• ループ回数　：　無限ループにチェック。

これで単純に実行。無限ループにチェックが入っていると終わらないので、

スケジューラを使ってテスト期間を設定するか手動で終了する。

ただ、これだと本当に一度にリクエスト送られるから初動ですごい負荷かかるんだよね。

Ramp-Up期間を若干広げて少しずつスレッドを送るようにしたほうがいいのかな？

最大でどれだけの負荷に耐えられるか？

ようは上のやつの想定数の値がわからないときの場合．．．のはず。

どこのページでも何回かテストを繰り返して判断するみたいなことを言っているし。

• n=テスト回数
• スレッド数　：　１０かけることのｎ
• Ramp-up期間　：　１
• ループ回数　：　無限ループにチェック
• テスト時間はとりあえず３分

この条件でやってみる。テスト時間は適当に出した値なので当てにしない。

スループットが下がり始めたらそこが限界点！

多分このふたつは考え方は間違っていない、と思う。間違ってないよね。間違ってないといいな。

これをもとにして、色々シナリオ組んだりなんだりすればいいのかなあ？

アルゴリズム ゲームにおけるテキストの表示

どんなゲームでも文字列の表示はあるでしょう。...あるよね？
今回はノベルゲームで使われそうなテキストについて考える。

必要な機能

機能として必要そうなものを列挙する。

• 文字列を表示する
• 時間経過による表示の進行
• ボタンを押されたことによる全表示処理
• 上記の処理後のテキストの追加

最後の機能はテキストを全画面表示や、表示と表示の間になんらかの演出を挟むための。

分割ボイスを再生とか。

クラス設計

各機能に対して必要な関数やメンバはなにか。
まずはメンバ。

• 文字列のテクスチャ。これは行ごとに持つ。追加にも対応できるはず。
• 更新時間を計測するタイマ。
• １タイマにつき表示するテキスト量。
• 全表示を完了しているか。テキストの役目が終了してることをメインフレームに伝える

あれ？　こんなもん？

次は関数。というか必要な動作。

• タイマに合わせて文字列の表示範囲を調整。
• ボタンの入力を確認。
• タイマにかかわらず全文字を表示する。あるいはタイマを強制繰上げ。
• 文字列のテクスチャを追加する。タイマはリセットされない。

文字列の追加は行単位の細かいオブジェクトして追加でもいいかも。

これだけあれば行ける？　まあ、開発していればいやでも足りないものは見つかるでしょう。

SWF 構造に対する知識が足りない

SWFを解析して表示できるようにしたい。
そのためにはまず基本知識が必要だ！

わかりやすい解説を見つけたのでメモ。
・How to read SWF

http://www.slideshare.net/yoyayoya1/how-to-read-swf

jMeter Proxyサーバを使用してサンプラーを作成する

jMeterで自分でいちいちサンプラーを設定するのは面倒。
Proxyサーバを使えば自分のアクセスをそのまま使用できるということで、
Proxyサーバがなんなのかもわからないけどやってみよう。

今回は以下のサイトを参考にしました。
・JMeter 2.7つかってみた：プロキシー設定
http://sy5.sakura.ne.jp/jmeter/jmeteproxy.html

/*---------------------------------------------------------------------------*/

まずは「HTTPプロキシサーバ」を追加。
ワークベンチから「追加」→「Non-Testエレメント」→「HTTPプロキシサーバ」

Proxyサーバの設定をする。
なんか色々あるけどよくわからんので、対象となるコントローラから、
今回のスレッドグループを選択だけしておく。

開始！　なんか警告が出てきたけど、知ったこっちゃねえぜ！

使用しているブラウザのプロキシ設定を変更。
Chromeを使用しているので設定から詳細設定で変更。
使用しているＯＳのプロキシ設定が立ち上がるので、
アドレスを localhost に、ポートをjMeterで設定されてるやつにする。

ブラウザでアクセス！

なんか色々できた。
不要なものは右クリックで消してしまう。
やってしまえば意外となんとかなった。

/*---------------------------------------------------------------------------*/