MODX JAPAN

[サーバ]
　ホスト&契約タイプ:(sixcore,50GB,共有プラン,CPU XEON-2.33GHz,MEMORY 12GB)
　ネットワーク:(インターネット)
　Webサーバ:(Linuxサーバ,Apache:2.2.3)
　PHPバージョン:(5.1.6)
　DB:(MySQL:5.0.22)
php.ini : memory_limit ; 64M
[Local]
　ネットワーク:Xampp ,Apache:2.0
　PHPバージョン:(5.2.6)
　DB:(MySQL:5.0.67)
php.ini : memory_limit ; 128M
[modx]
　バージョン:Evolution(1.0.0)
　アドオン:sitecache.idx.php

---

いつも貴重な情報をありがとう御座います。

7000ページを越えた頃、キャッシュでもサイト表示が遅くなる問題にあたりました。
sitecache.idx.phpの容量が大きいのが原因と思うのですが、（間違えでしたらご指摘ください）
何か良い対処法はありますでしょうか？

---

[これまでの経緯]
サーバ上でドキュメント数4000ページくらいの所でこちら様と似た様なエラーが出ました。
>sitecache.idx.phpでのエラー
http://modxcms-jp.com/bb/viewtopic.php?f=7&t=95

その時はサーバのphp.ini : memory_limitを32Mから64Ｍに変更し問題解決いたしました。
その後、順調に動いていたのですが、7000ページを越えた頃、どうにもフロントページ表示が重くなり、

>ページが増えてきたらやっておきたいこと
http://modxcms.com/forums/index.php?topic=32848.0
>サイトが完成に近づいたらやっておきたいこと
http://modxcms.com/forums/index.php/top ... t.html#new

などを参考に改善しました。とても調子がよくなりました。

現在、ドキュメントが8000ページほど有ります。
sitecache.idx.phpは1M程です。
特にエラーは出ていません。ただサーバ上での１ページ表示に30秒くらいかかります。
Server
MySQL: 0.0211 s, 78 request(s), PHP: 0.3170 s, total: 0.3381 s, document retrieved from cache.

total: 0.3381 sなのですが表示体感速度は３０秒です


ローカル（memory_limit:128Ｍ)で同サイトの同ページでテストしたろ、
local：8000ページでの表示速度
MySQL: 0.1042 s, 90 request(s), PHP: 1.4129 s, total: 1.5171 s, document retrieved from cache.
sitecache.idx.phpは1M程です。
表示体感速度はそのまま１秒ほどです。

ローカルでどの程度のページ数の耐久があるかストレステストしたところ、
30000ページを越えたあたりから、保存後のサイトツリーのローディング、クリーンナップを自動でやらなくなりました。
しかし、保存はちゃんと出来ていて、プレビューではサイトは不安定ではありますが表示しています。
sitecache.idx.phpは3.6Ｍ
local：34000ページでの表示速度
MySQL: 0.0968 s, 83 request(s), PHP: 3.3440 s, total: 3.4408 s, document retrieved from cache.
表示体感速度はそのまま3秒ほどです。

40000ページでも一応動いています。ww
sitecache.idx.phpは3.6Ｍ以上増えなくなりました。
sitecache.idx.phpの中身を見てみると、30000ページくらいまでキャッシュされていました。
ＩＤ30000以上のページをプレビューするともれなくデータベースから呼び出されます。
local：40000ページでの表示速度（上でテストした同じページです。キャッシュを外してテストしました。）
MySQL: 0.1196 s, 98 request(s), PHP: 3.5579 s, total: 3.6775 s, document retrieved from database.
表示体感速度はそのまま3秒ほどです。

質問に戻りますと、

sitecache.idx.phpの容量が大きくなるとキャッシュでも表示速度が遅くなると思うのですが、
sitecache.idx.phpを何か分散（容量を小さく）できる方法は無いでしょうか？
最終的に４言語対応にしようと思いますので30000ページほどになるかと思います。
単純に言語別に４つのＭＯＤＸを組み合わせて作ることも可能だと思いますが、その場合でも10000ページくらいのがスムーズに動くと嬉しいです。
そして、その場合、別々のＭＯＤＸ間のファイルの複製などをする方法はありますか？

最終的にはサーバ上で表示速度が速くなれば問題ないのですが、何か良い方法がありますでしょうか？

取り留めのない文章を長々と申し訳御座いません。
どうかご教授お願いいたします。

ページ数が増えた場合のパフォーマンスの問題は近いうちに解決したいですが、アイデア次第ですね。

対症療法になりますが、PearライブラリのCache_Liteを利用すると問題を解決できると思います。MODxではなくCache_Liteが制御するキャッシュを読ませることで、sitecacheにもDBにも一度もアクセスせずにページを出力させることができます。ただしDittoを使ってページスイッチ付きの一覧を制御してたりする場合は動的に処理する必要があって、この場合はどうなるかは調べてないのでよく分かりません。sitecacheが逆に足を引っ張っているので、sitecacheを経由しない処理になっていれば問題ないですが。問題ある場合はコアの改造で対応できそうな気はします。

僕の方もmodx外の対処法です。

ドキュメントが増えるとキャッシュファイルを読み込むだけで時間がかかるので、php側のスピードアップも検討されるといいかもしれません。
fastCGI+APCの組み合わせでphpの処理速度が結構速くなります。
ただ、php側の改造は専用サーバやVPSじゃないと難しいですが…。

あとキャッシュファイル(sitecache.idx.php)が頭打ちしてしまうと$modx->documentListing等のAPIに影響がでそうな気がします。
ちなみにキャッシュファイルが頭打ちしたのはPHPの実行時間の制約かもしれないですね。
(php.iniのmax_execution_timeで調整できます。デフォルトはたしか30秒です)

そして肝心のキャッシュファイルの高速化ですが、今はWebアクセス時に全ドキュメントの情報(の一部)を毎回全部読み込むので、ここの見直しで改善が図れると思います。
ただmodx APIの実装を大胆に見直さないとダメなので、実装方法次第では動かなくなるスニペットやプラグインが大量に出てきますね…

一応日本のmodxコミュニティ内部でもキャッシュ周りの速度改善も課題として上がっています。
まだ案を出し合ってる状態で決定打がないので素敵な案があれば提案をお待ちしています

8000という数字はエンタープライズ系システムでは至極当たり前の数字ですが、実運用されてるMODxサイトでは過去聞いた中で最高レベルかも。yamaさんとsoushiさんからプロフェッショナルな意見が出たので、自分はdotさんの精密なご報告内容に沿って気になるポイントを幾つか。

dot さんが書きました:Server
MySQL: 0.0211 s, 78 request(s), PHP: 0.3170 s, total: 0.3381 s, document retrieved from cache.
total: 0.3381 sなのですが表示体感速度は３０秒です

ローカル（memory_limit:128Ｍ)で同サイトの同ページでテストしたろ、
local：8000ページでの表示速度
MySQL: 0.1042 s, 90 request(s), PHP: 1.4129 s, total: 1.5171 s, document retrieved from cache.
sitecache.idx.phpは1M程です。
表示体感速度はそのまま１秒ほどです。

MODxのキャッシュの性能限界（逆ザヤ的な劣化が起こり始めるデータ量グラフ上のポイント）がどの辺かは自分も詳しくは掴んでませんが、ぱっと見、これだけデータが多くなるとDBからページデータを引くよりもsitecache.idx.phpのパース（配列展開）の処理コスト（ここでいうコストとは処理時間ではなくメモリの占有率など）の方が高くつくのかもしれませんね。上のサーバとローカルの性能比較結果がとにかく気になります。性能測定タグが示す数値はそれほど開きがないのに（というか、５倍ぐらいサーバの方が早いのに）、なぜ、体感速度がこれほどまでに乖離するのか。yamaさんやsoushiさんがMODx外の対処法を薦めるのはこの辺に起因するのだと思いますが、ここをもう少し突き詰めてから、対処法を探った方がいいように感じます。yamaさん/soushiさんどうでしょね。

幸いdotさんはパワフルなサーバを使われてるようですので、安直な発想ですが、逆にハードスペックに頼って以下のことを試してみてはどうかと・・・
これらの改造って相当難しいんでしたっけ？

　試行１）　キャッシュを使わない
　試行２）　キャッシュは使うが、ドキュメントデータだけはキャッシュせずにＤＢからリアルタイムに引いてからパースする

dot さんが書きました:最終的に４言語対応にしようと思いますので30000ページほどになるかと思います。
単純に言語別に４つのＭＯＤＸを組み合わせて作ることも可能だと思いますが、その場合でも10000ページくらいのがスムーズに動くと嬉しいです。
そして、その場合、別々のＭＯＤＸ間のファイルの複製などをする方法はありますか？

４言語対応のマルチリンガルサイトをご検討とのこと。
現状8000ページ * 4＝32,000。今後の増加量も加味して10000 * 4 = 40,000　という見通しですね。（こりゃまたすごい数字で・・・　＾＾；）
現状の8000でも性能的な問題がある状態で、ページを単純に倍加させると更に性能が劣化するのは明白。
少し前から下のアドオンに非常に興味があって自分も研究してるのですが、マルチリンガル対応に使えないでしょうか？このアドオンはテンプレート変数を使ってマルチリンガルを実現するので、テンプレート変数の増加に伴う別な性能劣化要因を誘発する懸念はありますが、少なくともページ数が倍加することは防げる気がします。
YAMS (Yet Another Multilingual Solution)
まだベータ版ですが、コアの基盤を使ったシンプルな構造なので品質に関する大きな問題は出にくいと予想してます。
制作者のPMSさんとは、数回ご連絡させていただいてて、確か英国在住の日本人の方だったと記憶してます。ですから深めな問題が出ても対応はしやすいのではないかと・・・

早速のお返事ありがとう御座います。
とても参考になります。

まず、すぐに出来るところから調べてみました。

sama55 さんが書きました:　
試行１）　キャッシュを使わない
試行２）　キャッシュは使うが、ドキュメントデータだけはキャッシュせずにＤＢからリアルタイムに引いてからパースする

sama55さんの仰る通りデータベースからの方が早い時があります。
全てデータベース呼びにしたところ、ページによって、表示体感速度で20秒から１分以上のばらつきがあります。
サーバ：体感２０秒くらい
MySQL: 0.0316 s, 107 request(s), PHP: 0.3868 s, total: 0.4184 s, document retrieved from database.
サーバ：体感１分以上
MySQL: 0.0272 s, 94 request(s), PHP: 3.4144 s, total: 3.4416 s, document retrieved from database.
キャッシュよりデータベースの方が早くなるときがありますが、全体的には遅いです。

sama55 さんが書きました:性能測定タグが示す数値はそれほど開きがないのに（というか、５倍ぐらいサーバの方が早いのに）、なぜ、体感速度がこれほどまでに乖離するのか。

私もこれがすごく気になりました。
そこでsitecache.idx.phpの容量が原因ではないかと思うのですが、どうでしょう？（あてずっぽです）

今まで意識したことはあまり無かったのですが、一般的な重いサイトでブラウザからローディングすると、まず、軽いデータ（テキスト）などが出てきて、
サイドメニュー、背景、軽い画像、重い画像、などバラバラと表示され、最終的に重い画像を読み込むまで時間がかかるとしても、
テキストが先に読める分、若しくは何か変わってる感がある為、閲覧者にはそんなに遅く感じさせないという効果があったと思いますが、
私のサイトの場合、ブラウザのローディングに３０秒（その間更新前の画面でフリーズ）、後、全てを表示に０．５秒みたいな、出るか出ないかローディングになっています。
テンプレート変数入力画面の都合上、テンプレートの種類を乱発してるのですが関係あるのしょうか。

sama55 さんが書きました:YAMS (Yet Another Multilingual Solution)

こちらは是非試させて頂きたいと思います。ありがとう御座います。

yamaさん
なるほどと思いました。

yama さんが書きました:PearライブラリのCache_Liteを利用すると問題を解決できると思います。

数時間格闘して、まだ上手くいってません。でもなんか分かった気がします。
私の技量で上手くいくか分かりませんが、もうちょっと勉強して、この方向で挑戦しようと思います。
コア改造必要ですか？
上手くいったらご報告いたします。ありがとう御座います。

soushiさん
ありがとう御座います。

soushi さんが書きました:ドキュメントが増えるとキャッシュファイルを読み込むだけで時間がかかるので、php側のスピードアップも検討されるといいかもしれません。
fastCGI+APCの組み合わせでphpの処理速度が結構速くなります。

レベル高そうな感じですね :汗
出来るかどうか分かりませんが、チャレンジしたいと思います。

soushi さんが書きました:ちなみにキャッシュファイルが頭打ちしたのはPHPの実行時間の制約かもしれないですね。
(php.iniのmax_execution_timeで調整できます。デフォルトはたしか30秒です)

私の環境でデフォルト60秒→120秒に変更してみましたが、結果は変わりませんでした。

soushi さんが書きました:一応日本のmodxコミュニティ内部でもキャッシュ周りの速度改善も課題として上がっています。

他力本願で本当に申し訳なく思うのですが、大変期待をしております。


とりあえず、yamaさんの案でPearライブラリのCache_Liteを利用する
という方向で取り組んで見たいと思います。

他に何か試してみれば的な事でも有りましたら、是非教えてください。

ありがとう御座いました。

dot さんが書きました:

yama さんが書きました:PearライブラリのCache_Liteを利用すると問題を解決できると思います。

数時間格闘して、まだ上手くいってません。でもなんか分かった気がします。
私の技量で上手くいくか分かりませんが、もうちょっと勉強して、この方向で挑戦しようと思います。
コア改造必要ですか？

少し改造が必要です。index.phpの先頭行あたりから仕込むといいと思います。
キャッシュのIDとして使う変数はgetenv('REQUEST_URI')という感じでURIで生成するのが無難。これを読み書き両方で用います。ページを編集・投稿した場合にキャッシュをクリアしたい場合はmanager/index.phpにも手を入れるといいと思います。$cache->clean(ナントカ)という感じだったかな、ちょっとよく思い出せないですが。汗
組み込みが成功すれば、静的ページと同様に一瞬で表示されるようになります。ある程度試してみて、分からないことがあったらいつでも気軽に相談してください。いきなりMODxで始めず、手元に練習パターンを作ってコツをつかんでから始めるのも意外と近道かもです。

とりあえずはページ単位の組み込みを試されるといいと思いますが、うまくやれば[!xxxxx!]に相当するスニペット単位のキャッシュコントロールも可能です。いろんなCMSで応用が利くので、マスターしておくと役に立つと思います。

追記
QuickManagerを使ってる場合は、ログイン時にはキャッシュを生成しないようにする必要があります。クッキーを見て判定するとよいのかなと思います。

解決したっぽいのですが、釈然としないので
また質問させてください。

サーバに問い合わせたところ
htaccessの記述内容に問題があると言われました。

.htaccessは1.0.0のデフォルトです。
これを外したところ爆速になりました。w

sitecache.idx.phpは関係なかったのかなぁ？

調べたところ、
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
をコメントアウトするかどうかで大きく速さが変わります。
コメントアウトした状態で、何か問題があるのでしょうか？

そして、関連があると思うのですが、フレンドリーＵＲＬが使えなくなりました。

また、RewriteRule を有効、modx側でフレンドリーＵＲＬをＯＦＦにしてもサイト表示の遅延は解消されませんでした。

今となっては、フレンドリーＵＲＬ捨てても良い様な気になっているのですが、
何か救う手は有るのしょうか？

んー、原因とは言えるけど問題ってことはないですよ。他のCMSでも普通にやってることですし。

MODxのキャッシュパフォーマンスの問題はエイリアス処理にあるのですが、その部分の変換を無効にすることでエイリアス変換をする必要がなくなるので軽くなります。つまりフレンドリーURLを使わなくてもいいなら解決です。

dot さんが書きました:サーバに問い合わせたところ、htaccessの記述内容に問題があると言われました。
.htaccessは1.0.0のデフォルトです。これを外したところ爆速になりました。w
sitecache.idx.phpは関係なかったのかなぁ？

サーバ管理者が、「htaccessの記述内容に問題がある」と断言するからには、それなりの理由（根拠）があってのことだと思います（普通「ここだ」とは言ってくれないので・・・）。modxの内部機構を知らないサーバ管理者がそう判断したのは、Apacheのログで何か不審な動きを確認したからではないでしょうか。

dot さんが書きました:調べたところ、
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
をコメントアウトするかどうかで大きく速さが変わります。コメントアウトした状態で、何か問題があるのでしょうか？
そして、関連があると思うのですが、フレンドリーＵＲＬが使えなくなりました。
また、RewriteRule を有効、modx側でフレンドリーＵＲＬをＯＦＦにしてもサイト表示の遅延は解消されませんでした。
今となっては、フレンドリーＵＲＬ捨てても良い様な気になっているのですが、何か救う手は有るのしょうか？

dotさんの報告を見ると、表示遅延が起きてるのはmodx内の処理ではなくApacheっぽい感じがします。例えば、上記RewriteRule指定が結果的にsixcoreサーバのApacheの初期設定と関係して内部的なループを誘発してるとか。。。この仮定が当たってた場合、modx側からいくら調べても解決策を見つけ出すのは難しいと思いますので、サーバ管理者が「htaccessの記述内容に問題がある」と判断した理由（箇所）をもう少し詳しくヒアリングしてみてはいかがでしょう？

なるほど。担当者さんは「htaccessの記述内容に問題がある」としか言ってないのですね。^(.*)$ index.php?q=$1 [L,QSA]には問題ないと思いますが、それより前の部分でループなどを引き起こしている可能性は（MODx内部の問題とは別の問題として）あるので、いちおう詳細を聞いておいたほうがよいと思います。予想としては、rewriteモジュールに処理が渡ってから実際の出力が始まるまでの時間をログで見て言ってるだけのような気がしますが・・もう少し賢い組み方もあるような気もしますし。

皆様ありがとうございます。

7000ページ位まで今の設定で特に問題も起こらなかったので、キャッシュを疑っていました。

そもそも、8500ページを越えた頃、500エラーが頻発したので、サーバに問い合わせてみたのですが、
返答が下記です。

> 現在特に負荷が高まっているという事はございませんでした。
> その為、お客様のアカウント固有の負荷であるかと存じます。
> 確認を行わせて頂きましたところ、「xxxx.com/public_html」へ.htaccessファイルを設置されているかと存じますが、こちらの記述内容に問題があるようでございます。
> 1度.htaccessを無効にする、もしくは修正を行って頂き、
> 再度トップページの表示についてご確認頂けますよう宜しくお願い申し上げます。
> ※.htaccessの記述内容に関しましてはサポート対象外事項とさせて頂いております。

思いもよらず問題解決しました。

sama55 さんが書きました:この仮定が当たってた場合、modx側からいくら調べても解決策を見つけ出すのは難しいと思いますので、サーバ管理者が「htaccessの記述内容に問題がある」と判断した理由（箇所）をもう少し詳しくヒアリングしてみてはいかがでしょう？

問題があると判断した理由については、もう一度問い合わせて見ます。
理由となる返答が得られましたら、後日報告させていただきます。

一応解決と言う事で、
本当にありがとうございます。

古いトピですがこちらでシェアします

https://github.com/modxcms-jp/evolution ... a52b24a5f0
本件は次のリビジョンで改良を試してみます