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

現場は無理な使い方してるケースはざらにあると思いますが、８階層を超えるとツリーの表示にも無理が出てくる気はします。このへん、ツリーモードと従来のCMSのようなスタックモードと、表示を切り換えて扱えるような管理画面にできるとよいなという気がします。

パフォーマンス的な話についてですが、MODxってキャッシュのパージのタイミングがすごく大雑把ですよね。更新時は全部削除、みたいな。ページ数が多いだけの普通のサイトならそれでも問題ないかもですが、ユーザによって立ち寄るページがバラバラなコミュニティ指向な構成のサイトだと一時的にパンクしやすくなりそうな気がします。将来的にはヘッドとロングテールを意識した緻密なキャッシュコントロールができるようになるとよいなと思います。

確かにそうですね。管理画面もキャッシュも、もう少し工夫が欲しいところです。
ツリーで直感的にドキュメントが把握できたり、高速なキャッシュといった現状のmodxの良さを損なわずに、更に限界を伸ばすためのキーワードは負荷分散のような気がします。

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

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

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

soushiさんあたりが一番ご存知だと思いますが、現状の実装では限界に近いのかもしれませんね。パージについては、「多少（短い期間）なら古いコンテンツが見えてもいい！」ぐらいの割り切りが許容できれば、cronと公開スケジュール機能を組み合わせて、明け方５時ぐらいにキャッシュのクリアと再生成（エクスポート）プロセスを走らせるとか。これなら簡単に実現できそうなので、実際やってる人がいたりして。データ量（レコード数やコンテンツのボリューム）が多くなることが予め分かってるフォーラムやマルチメディア系CMSでは、この辺非常にインテリジェントに作られてるんですが、なぜかmodxには「テンテナンス」という括りの機能がコアに実装されてませんよね・・・（アドオンにあるのかなー）