PHPのテクメモ

PHPでメールを大量に配信する方法を検討している。ウェブの管理画面から送信処理をするのだが、CLI版PHPで書かれたメール配信プログラムを、DSO版（モジュール版）PHPでキックし、メール配信プログラム内では、ループして送信するような処理はずっと以前から記述していた。とりあえず、それで事は足りていた。

しかしいろいろ調べる内に、もっと真面目にメール配信する手法を検討しようと言う気になった。それはマニュアルのmail関数の注意事項を読んでから。

注意: mail() 関数は、大量のメールをループ内で送信するには 向いていないことに注意しましょう。この関数は 1 通のメールを送信するたびに SMTP ソケットをいったん閉じて開きなおします。これは非効率的です。
大量のメールを送信する場合は、 » PEAR::Mail および » PEAR::Mail_Queue パッケージを参照ください。

メールの送信はmb_send_mail関数を使っているが、おそらく基本的な動作はmail関数と同じだろうから、これでは効率が悪いと言うことになるのだろう。より効率良くするためには「直接SMTPを話す」事になるとのことだ。個人的には「PHPで直接SMPTを話すなんて遅そう」と思っているのだが、そうではないらしい。今回使ってみようと思うのは、QdSmtpとQdmailの組み合わせ。

QdSmtp
Qdmail

スポックさんと言う人が書いているのだが、この方のメール配信系のプログラムにお世話になっている人も多いようだ。テクメモで以前書いたQdmailReceiverもこの方の成果物だ。

プログラムの記述方法は、実際に使用してからメモするとして、これらのプログラムを使うことで、ひとつのソケット接続で、ぽこぽことメールを送信できるようになる。PHPで大量のメールを送信する際に注意すべき事項（調べて出てきた重要そうな事項）をメモしておくことにする。

• mail関数を使用せず、PHPで直接SMTPを話す。
• 一定数送信したら、一定時間休む。
  sleepするような処理を入れる方がよいらしい（迷惑メール対策等で携帯宛などの場合連続して送信された大量メールは拒否られる可能性がある）。
• BCCで、例えば10通ずつとかまとめて送る方法もあり（TOの指定が必要だけど）。
• 基本的にループで処理するのだが、全てのプロセスを一つのプロセスで実行しようとせず、プロセスを分ける方法も考える（メモリリークとか）。

さてと、どうやって書こうかな。

今、一番重宝している本のメモ。

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

データベースなんてデータの保存庫と思っていた。大量のデータを扱う機会があまりなく、かつ複雑なSQLも今まで必要なかったけれど、最近はそうもいかない。適当なSQLを記述していると、実行速度が極端に遅くなったりすることが多くなった。SQL文をEXPLAINするのはもちろんだけど、それだけでは効率化する方法はわからない。例文がやっぱり重要だ。

そこでこの本。とてもいい！。

まずデータベースに依存しない。汎用的なSQL（92）での記述なので、どのデータベースでも対応出来る。そしてサンプルが豊富だし、変にデータベース技術者かぶれなSQL文ばかりでなくて、現場に則したSQL文を提供してくれる。SQLに関して初心者の域を脱したと思ったら、次のステップで読むには最高の良書だ。

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

MySQLはバージョン5からVIEWを使用できるようになった。最近はデータベースをコマンドラインから扱うことがあまりなく、基本的にphpMyAdminから操作することがほとんどだ。ではphpMyAdminから簡単にVIEWを扱うことが出来るのか。

VIEWの作成は簡単だ。SQLを実行したり、テーブルに対して検索をかけたりしたあとに表示される結果のページに「CREATE VIEW」とあるので、これをクリックするとVIEWが出来上がる。もちろんCREATE VIEWのSQL文を実行することでもVIEWを作ることができる。

しかし現状のphpMyAdminの最新バージョン3.2.4で確認したが、VIEWの内容を、インタラクティブに確認したり修正したりする方法が見つけられない。ウェブで調べたが、そもそもそういう情報を求めている人もあまりいないのか、期待する検索結果が出てこない。結局SQL文を実行するしかないみたい。

VIEWの内容を確認する方法は以下のSQL文。

SHOW CREATE VIEW view_name;

VIEWを修正するためのSQL文（CREATE VIEWの構文をALTER VIEWにするだけ）。

ALTER VIEW view_name AS SELECT … ;

まだまだVIEW機能はこなれていないのだろうか。

MySQLのダンプデータが60MBほどあった。phpMyAdminでインポートしようと思ったのだが、アップロードできるファイルの最大は16MBとなっていた。60MBのファイルと言っても所詮テキストファイルだから圧縮してしまえば12MBになるから、アップロード自体は出来る。しかしいろいろ考えて、アップロード出来る容量を増やすことにした。

ここのサイズ指定は、単純にphp.iniの設定に依存しているらしい。おそらく.htaccessを設置すれば事足りるだろうが、設置するとInternal Server Errorが表示されてしまう。とりあえずローカルな環境（Windows）で試そうと思っているのだが、なにか問題でもあるのだろうか。

本筋でないことに時間を割くのが嫌なので、php.iniを変更することにした。よくよく考えればおバカな話だが、読み込んでいるphp.iniがどのファイルか分からなくて、何回変更しても、変更した設定が有効にならなかった（正しいファイルを変更していないのだから当たり前）。初心に帰って、phpinfo()で表示されるphp.iniの場所を頼りに設定ファイルを編集した。

Windows版Xamppでは、xampp/apache/bin/php.iniを使用しているらしいことがわかったので、そのファイルを編集した（xampp/php/配下にもphp.iniやphp5.iniがあるので注意が必要）。修正箇所は以下の3つ。

• memory_limit 512M
• post_max_size 256M
• upload_max_filesize 128M

なんとも大盤振る舞いだが、ローカルな環境だから気にしないでいい。php.iniを修正したので、修正後はapacheの再起動が必要。再起動後にphpMyAdminのインポートの項目を見ると「最長: 131kKiB」となっていたkKiBだからMiB、つまり131MiBになった。これで無事一発で処理が完了した。

もし処理が遅い場合はmax_execution_timeの設定を増やしておけば良いかもしれない。

ファイルシステムext3のディレクトリ内のファイル数の上限が気になった。どこにでもよくある話のようで検索するといろいろ出てくる。でもすべてオリジナルは個々に端を発している。

http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.4/filesystems/ext2.txt.html

実運用上は「10-15k」らしい。これつまり「10k-15k」すなわち1万から1万5千ファイルほど。ファイルシステムの仕様上の問題らしい。パフォーマンスが悪くなるとのことだった。

パフォーマンスを気にしなければ「100k-1M+」とのこと。「100k-1M+」って意味わかんない、と思ったけど、どうやら100kから1Mもしくはそれ以上、ということらしい。だから10万ファイルから100万ファイル（もしくはそれ以上）という解釈。

でもその下には130兆以上のファイルが作成可能とも書いてある。

そもそも「じゃぁどれだけ」と言いたくなるが、それはおそらく状況に依存するのだろう。ちょっと悩んでいることがあるのだが・・・。まぁ、ひとつのディレクトリ内に設置するファイル数は数千を超えないようにすることが無難なようだ。