slow.log のlogrotate

slow.logは、自動的にlogroteしてくれないので、Cronで自前でやることにする。

#!/bin/sh

DATE=`date %Y%m%d`

mv /var/lib/mysql/slow.log /var/log/slow.$DATE.log

mysqladmin flush-logs (必要に応じてオプションをつける -u -h .... )

上記を 適当なファイルに記述して Cronで設定すればよい

携帯サイトで利用するJPG

携帯サイトで、JPG画像を利用して表示できない場合は、Content-Type を確認してみるとよい。

○ Content-Type: image/jpeg

× Content-Type: image/jpg

サーバ出力で画像を生成している場合などで、 image/jpg とするようなことは結構ある気がします。。。

私の場合は、PEAR::Image_Graph を使ったときに、Content-Type:image/jpg に出くわしました。

Image/Canvas/GD/JPG.php に、header 出力部分があるので利用の際は確認したほうがいいです。

PHPの最適化 12 PHP Optimization tips

(元ネタ http://www.ilia.ws/files/zend_performance.pdf)

1. staticが使えるなら、staticを使う。速度は4倍になる。


2. __get, __set, __autoload は避ける。


3. require_once() はコストがかかる。


4. include や require では絶対パスで指定する。


5. スクリプトの開始時間は $_SERVER[’REQUEST_TIME’] で得る。


6. 正規表現は、文字列関数で代用できないか探る。(文字を見つけるだけならstrposなどでもよい)


7. str_replace は preg_replace より早いが、strtr は str_replace の4倍早い。


8. 文字列/配列両方を受け入れる柔軟さを持つ関数は避ける。変わりに個別の関数を用意する。


9. @によるエラー制御は遅い


10. $row[’id’] は $row[id] より7倍早い


11. エラーメッセージはコストがかかる


12. for ($x=0; $x < count($array); $x) の count() のようにループの度に呼ばれる関数はさけ、変数に格納する。

ねた的には、古いですがふとしたときに思い出すと良いかも。

自社のフレームワークに、こういうエッセンスを入れていくのが重要なのかな。

個人的には、require_once は使いまくりなので、どうにかコスト削減に努めたいです。（便利だからねぇ）

弊社のプログラミングの基本的な方針

便利なコード　>>>>（優先順位）>>>> パフォーマンスがでるコード（コスト小）

基本的に便利なほうを優先する傾向にあります。

ここで言う便利とは、使いやすく、理解しやすく、人間的に優しいもの。という意味です。

省略したり、コードを短くしたり、難解なテクニックを使うのは、プログラマーの質によって

ムラが出るため、チームで仕事をしたりしているといろいろ弊害が出てきます。

（みんながスーパープログラマーなら問題ないけどね。。。）

この辺はシステムの要件にもよります。

普通の公道を走るのに、F1のマシンは必要ないですね。

ただし、燃費が良いほうが好まれるのは、公道でも、F1でも同じです。

このあたりの必要なパフォーマンス要件をしっかりと事前に考えて取り組むのが重要かと。

また、必ずしもトレードオフとか限らないので

「人間にもマシンにとっても優しい方法」を考えるのはなかなか楽しいものです。

得てして、人間に優しいコードは、パフォーマンス的にも良い場合が少なくありません。

そういう気質は、すぐに目の前の仕事から脱線してあらぬ方向へ行ってしまいますが、

プログラマーには、必要な「遊びごころ」だと思ってます。

Xenコマンド備忘録

たまにしか使わないので良く忘れます。

・ドメインの起動（　-c でコンソール接続）
xm create [ドメイン名]
xm create -c [ドメイン名]

・コンソールに接続
xm colsole [ドメイン名]

・稼動状況を表示
xm top

・ドメインのリスト表示
xm list

・終了
xm shutdown [ドメイン名]

・強制終了
xm destroy [ドメイン名]