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

<![CDATA[ ModXの大体のキャパシティについて（Ver1.0） - My Forums]]> https://forums.modx.com/thread/?thread=56630 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0?page=2#dis-post-332635 ツリーで直感的にドキュメントが把握できたり、高速なキャッシュといった現状のmodxの良さを損なわずに、更に限界を伸ばすためのキーワードは負荷分散のような気がします。

■バックエンド画面　（ツリー）

先日、実用的なドキュメント数の限界を探るため、2.8GHz程度の標準的なXPマシンのXAMPP環境にドキュメントを最大１０,０００個作っみたのですが、さすがに重かったです。これがネット上のサーバであれば、回線の種類に依存した大きな遅延が加わるので想像するだけでゾッとしました。ツリーの情報収集と描画（トラフィック）がボトルネックであれば、多少画面の反応が悪くなることには目をつぶって、ツリーの展開や折りたたみを非同期で行えば負荷が分散されたりして・・・(ツリーもAjaxなんですよね？、ってよく分かってないという)

■フロントエンド画面　（キャッシュ）

soushiさんあたりが一番ご存知だと思いますが、現状の実装では限界に近いのかもしれませんね。パージについては、「多少（短い期間）なら古いコンテンツが見えてもいい！」ぐらいの割り切りが許容できれば、cronと公開スケジュール機能を組み合わせて、明け方５時ぐらいにキャッシュのクリアと再生成（エクスポート）プロセスを走らせるとか。これなら簡単に実現できそうなので、実際やってる人がいたりして。データ量（レコード数やコンテンツのボリューム）が多くなることが予め分かってるフォーラムやマルチメディア系CMSでは、この辺非常にインテリジェントに作られてるんですが、なぜかmodxには「テンテナンス」という括りの機能がコアに実装されてませんよね・・・（アドオンにあるのかなー）]]> sama55 Jul 12, 2009, 11:14 PM https://forums.modx.com/thread/56630/modx-ver1-0?page=2#dis-post-332635 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0?page=2#dis-post-332634
パフォーマンス的な話についてですが、MODxってキャッシュのパージのタイミングがすごく大雑把ですよね。更新時は全部削除、みたいな。ページ数が多いだけの普通のサイトならそれでも問題ないかもですが、ユーザによって立ち寄るページがバラバラなコミュニティ指向な構成のサイトだと一時的にパンクしやすくなりそうな気がします。将来的にはヘッドとロングテールを意識した緻密なキャッシュコントロールができるようになるとよいなと思います。]]> yama Jul 12, 2009, 09:26 PM https://forums.modx.com/thread/56630/modx-ver1-0?page=2#dis-post-332634 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332633
なるほどー　やっと話が通じました。
「キャパシティ」を「リミット」に読み替えて議論すると色々ありそうですね。

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

0.9.x.xから1.x.xに変わった正規リリース版として、この辺はっきりさせておきたいshinboriさんのお気持ちよく分かりますです。]]> sama55 Jul 12, 2009, 07:22 PM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332633 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332632
> kmikage さん、yama さん
DBまわりのことですねー（言葉足らずですいません）。
いつもkmikageさんの発言で、DB周りの知識が自分にはないなぁと反省しますｗ
わかりやすい説明ありがとうございます。（というかそういうことがMySQLで出来ることを初めて知った・・・ググってきます）

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

> soushiさん
回答ありがとうございます。
ModXは、問題があったとき大体がソフトウェアの仕様ではないところがボトルネックになるので、あんまり仕様の壁にぶつかることはそうそう無いと思いますが、
見つかったら報告はしますね。]]> shinbori Jul 12, 2009, 05:39 AM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332632 <![CDATA[Re: ModXの大体のキャパシティについて(Ver1.0)]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332631
Quote from: sama55 at Jul 12, 2009, 01:27 AM

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

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

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

]]> soushi Jul 11, 2009, 11:49 PM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332631 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332630 sama55 Jul 11, 2009, 08:27 PM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332630 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332629 Quote from: yama at Jul 11, 2009, 10:34 AM

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

MySQLは標準でレプリケーション機能は持っていますが、
「1台のマスターに対し複数台のミラー」、つまりselect文専用のDBサーバを建てられるようになっています。
MODxは現在1台だけしかDBサーバを指定出来ないですが、
select専用のDBサーバを別途指定出来るようになれば、DB周りのボトルネックは解消出来るかも知れません。
（このあたり、OpenPNEが良い感じで実装していると思います。）]]> kmikage Jul 11, 2009, 09:04 AM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332629 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332628 Quote from: shinbori at Jul 11, 2009, 09:49 AM

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

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

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

冗長化というのは特にDBまわりのことかな？と思いますが、読み書きそれぞれ専用に二重化するとか、構造的にはそういうのもやりやすい気がします。まだ完全じゃないけど、DBまわりはほぼAPI経由になってると思います。]]> yama Jul 11, 2009, 05:34 AM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332628 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332627 キャッシュ制御なるほどです。確かにその手もありますね。
以前、情報交換会でスケーラビリティのところで、冗長化やロードバランスがどうかとかいろんな話をさせていただいたのですが、
まずこういった点から改善したほうがよさそうですね。

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

]]> shinbori Jul 11, 2009, 04:49 AM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332627 <![CDATA[Re: ModXの大体のキャパシティについて（Ver1.0）]]> https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332626 yama Jul 11, 2009, 01:30 AM https://forums.modx.com/thread/56630/modx-ver1-0#dis-post-332626