ModXの大体のキャパシティについて（Ver1.0）

ちょっと大量にPVがあるクライアントさんが相手でModXを使えるかなーと思ってみなさんにご相談です。
ModXは、PVやユーザー数などをどのぐらいの数値で見て開発しているんでしょう？

全体のパフォーマンスはサーバやModXの使い方だろって話はわかりつつも、
このModX自体のパフォーマンス性能はどのぐらいの数値のものを受け入れられるキャパシティを考えているのかが気になった次第です。
（もし過去ログにあったら教えてください）

情報交換会でもあんまり出てなかったかなーと（どうやってスケーラビリティを高めるかは、ありましたが）。

大体 100万PV/月　までは見てるつもりだぜ！的な、模範解答があるとすごく嬉しいです。

すいません、完全に自己レス解決。
http://modxcms.com/forums/index.php?topic=14096.0

ちなみに2.0のものも。
http://modxcms.com/forums/index.php?topic=29252.0

MODx自体そこそこ軽いと思いますが、いざとなればindex.php内のprotect.inc.phpを読み込む直前あたりでキャッシュ制御を組み込めば(条件付きGETなども利用)、極限まで軽くすることができると思います。あまりアクセス数が多いモンスター級のサイトだと軽くするだけではダメで、「それでも限界を超えてしまった場合」の503対策などの処理を考える必要が出てきますね。

> yamaさん
キャッシュ制御なるほどです。確かにその手もありますね。
以前、情報交換会でスケーラビリティのところで、冗長化やロードバランスがどうかとかいろんな話をさせていただいたのですが、
まずこういった点から改善したほうがよさそうですね。

展示板にも掲載しましたが、ドキュメント数が1700超えたりしていますが、
結構このあたりの「スケール感」は、個人的にはすごく大事でして。
CMS選定の最初の基準値にもなりますしね。

Quote from: shinbori at Jul 11, 2009, 09:49 AM

> yamaさん
キャッシュ制御なるほどです。確かにその手もありますね。
以前、情報交換会でスケーラビリティのところで、冗長化やロードバランスがどうかとかいろんな話をさせていただいたのですが、
まずこういった点から改善したほうがよさそうですね。

展示板にも掲載しましたが、ドキュメント数が1700超えたりしていますが、
結構このあたりの「スケール感」は、個人的にはすごく大事でして。

ドキュメント数が多くなると、ややロングテール指向なキャッシュ制御のノウハウが必要でしょうね。MODxってキャッシュを通さずに動的に出力する時はかなりリソース食う気がするので(実際かなり遅い・・orz)、ライフタイムのコントロールなどで手を抜くとパンクしてしまうかも。MODx自体はそういうコントロールをできる仕様は持ってないけど、一意のURLを作りやすいCMSだし、動的・静的の区分けもわりとはっきりしてるので、ノウハウさえあれば扱いやすいのではと思います。そういう意味では高負荷サイトの運用は向いてそうです。

冗長化というのは特にDBまわりのことかな？と思いますが、読み書きそれぞれ専用に二重化するとか、構造的にはそういうのもやりやすい気がします。まだ完全じゃないけど、DBまわりはほぼAPI経由になってると思います。

Quote from: yama at Jul 11, 2009, 10:34 AM

冗長化というのは特にDBまわりのことかな？と思いますが、
読み書きそれぞれ専用に二重化するとか、
構造的にはそういうのもやりやすい気がします。
まだ完全じゃないけど、DBまわりはほぼAPI経由になってると思います。

MySQLは標準でレプリケーション機能は持っていますが、
「1台のマスターに対し複数台のミラー」、つまりselect文専用のDBサーバを建てられるようになっています。
MODxは現在1台だけしかDBサーバを指定出来ないですが、
select専用のDBサーバを別途指定出来るようになれば、DB周りのボトルネックは解消出来るかも知れません。
（このあたり、OpenPNEが良い感じで実装していると思います。）

回線の太さやサーバ構成など、同一の環境（条件）下で色々なソフトを比較・検証した結果この辺が限界みたい、って感じの経験則なら分かりますが、ハード的な前提条件がないソフト単体のキャパなんて、そもそもあるんでしょうか？

soushiです。

Quote from: sama55 at Jul 12, 2009, 01:27 AM

回線の太さやサーバ構成など、同一の環境(条件)下で色々なソフトを比較・検証した結果この辺が限界みたい、って感じの経験則なら分かりますが、ハード的な前提条件がないソフト単体のキャパなんて、そもそもあるんでしょうか?

例えば次期リリース予定のmodx1.0にはキャッシュ生成の効率化アップが図られていますが、最初に提案されたソースは「キャッシュ生成時にディレクトリ階層が8を越えるとバグる」というものでした。
結局、この制限はなくなった形のソースが採用されましたが、もしこの制限が残っていたらハード的な上限がなくてもソフト面での制限に引っかかっちゃいます。
こういった事もあるため、ソフト単体のキャパというよりかは仕様の壁を調べる(気にする)必要はあると思います。

もし仕様の壁が見つかった場合は、ソフトである以上改善の可能性が見込めるので諦めるのではなく、報告してもらえると修正できる場合があると思います

予想以上にレスがついててびっくりしましたｗ

> kmikage さん、yama さん
DBまわりのことですねー（言葉足らずですいません）。
いつもkmikageさんの発言で、DB周りの知識が自分にはないなぁと反省しますｗ
わかりやすい説明ありがとうございます。（というかそういうことがMySQLで出来ることを初めて知った・・・ググってきます）

> sama55さん
某Movableなんちゃらさん（Ver3.xx）はカテゴリの周りでいろいろ制限があって悲惨なことになったことが経験上あります（カテゴリを増やしすぎると異常な負荷になり再構築できなくなる）。
なので、今回自分が投げているキャパシティ云々とは直接起因はしないかもしれませんが、soushiさんが言うように気にはすべきかなと思います。
そして、気になっていた質問を代弁してもらってありがとうございますｗ

> soushiさん
回答ありがとうございます。
ModXは、問題があったとき大体がソフトウェアの仕様ではないところがボトルネックになるので、あんまり仕様の壁にぶつかることはそうそう無いと思いますが、
見つかったら報告はしますね。

soushiさん、shinboriさん

なるほどー　やっと話が通じました。
「キャパシティ」を「リミット」に読み替えて議論すると色々ありそうですね。

階層限界のバグは初めて知りましたが何ともお粗末な話で。。。＾＾；　この件は、端末からリクエストを送信してからレスポンスを受信するまでの実用に耐えられるアクセス性能限界もしかりですが、ドキュメントを木構造で管理するmodxならではの、実用に耐えられる管理画面の動作性能限界として盛り込むつもりだったのかなー？　とか。

0.9.x.xから1.x.xに変わった正規リリース版として、この辺はっきりさせておきたいshinboriさんのお気持ちよく分かりますです。