OpenX

URLの最大文字数の制限について、改めて調べてみました。
URIではなく、URLについて。

URLなのでHTTPだろう、ということでRFC 2616をチェック。すると・・・

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

[Read More]

OpenXで広告配信システムを構築したとき、APCの導入で負荷が1/100くらいに下がったのでメモ。
LoadAverage60→0.6になりました。
導入は簡単です。

でokです。
php.iniに設定を追加して完了。ポイントは、apc.shm_sizeを大きめにとらないとgcが正常に動作しないようです。
apc.shm_sizeが足りないと、apacheのエラーログになんてのが出続けます。。。

[Read More]

OpenXでのMySQLチューニングの話

OpenXの場合、impressionをinsertでMySQLに記録するため
物理データファイルのサイズを小さく保つことが大事になります。

特に、インプレッションを記録する
ox_data_raw_ad_impression
テーブルのサイズが重要です。

実数はI/O性能によるので参考にしかなりませんが、
経験的にはデータファイルが800MBを超えたあたりから
急に性能が落ちてきます。

メンテナンススクリプトがテーブルをロックするので、
メンテナンススクリプトの処理時間が長いと
配信が遅延する原因になります。。。
また、データファイルが大きいと
配信自体(ox_data_raw_ad_impressionテーブルへのinsert)自体の
性能も低下する感じです。

と、いうわけで、

1. 生データ保持期間を短くする
2. (小さくできれば)データファイルを小さくする

という2つがポイントになります。

OpenXの管理画面で設定します。実際にデータが削除されるのは
メンテナンススクリプト(定期メンテナンス or 自動メンテナンス)が
実行されるタイミングです。show table statusで調査できます。
Data_freeが大きい場合、小さくする余地ありです。データファイルが大きくなりすぎた場合、
PostgreSQLならVACUUMコマンドで対応しますが
MySQLの場合はOPTIMIZE TABLE句で対応します。分速80MBくらいのスローペースで、テーブルにロックがかかるので、
頻繁に実施するか/まとめて実施するかは
システムの特性にあわせて選択するのがよいと思います。

[Read More]