5.1の要望ではありませんが、将来的にはこれを一番要望します。現在の半分の時間で各ページが表示されればかなり快適になると思います。あるいはAjaxを利用するなど。ブックマークを利用したページ遷移や、まとめて読み込んでから表示を切り替える案なども考えられますが、根本的な解決ではないと思います。
MTの問題というよりもPerl CGIの問題も大きいかと思うので、FastCGIやmod_perlで実際の運用に耐えうるレベルの対応や十分なテストと、そのあたりを整備した環境の普及なんかを考えた方がはやいかもしれませんね。
一方で例えばカテゴリの一覧がページ送りがないのでカテゴリを数百登録すると500エラーになったりとか、MT側で出来ることもあるかと思います。
MT3.xの管理画面はMT5よりもずっと軽かったので、CGIの仕組みだけの問題だけではないでしょう。 MT自体が巨大化したことや、管理画面でJavaScriptを多用するようになったことも、原因として大きいと思います。
MT内部的には、まずはJavascriptの統合、軽量化でしょうか
そういう環境で作るなって言われたら仕方ないんですが、 FireFox＋FireBugs環境で動かしてると重いなんてこともありますね。
こういう環境だと重くなるよ的な知見がどっかにあつまってるとうれしいかも。いやその重さの責任、半分君だしみたいな。でも、上記のような環境でも速度低下しないようなことは検討しておくべきかも。
Perl環境のチューニングは、root運用が前提だし、リソース不可を考えると共用機に実施されることはないでしょう。小規模以下案件では、指加えるだけになるか、責任おってデザイナーがバックエンドまで手をだすかの２択になるのは避けたい。
ビジネス的にはそこで差別化できるのだけど、提案者の多くはそこで勝負したくない、出来ないと思ってる人が多いとおもいます。僕もその一人なので（デザイナとしてはやってしまってるほうだと思うけど）
古いトピックにコメントしてしまいますが、私も管理画面の重さに悩まされています。 私の場合、MTで作品データベースを作っていて、カテゴリが6000個ほどあるので、通常の使用方法から外れていると思うのですが。
●カテゴリ管理画面を表示するのに数分かかる
●カテゴリを移動するのに数分かかる
●エントリ編集画面で、カテゴリリストを表示するのに1分ほどかかる（しかもその間にブラウザが他の操作を全く受け付けなくなる）
●エントリの所属するカテゴリを編集したいことが多いのですが、エントリ一括編集画面ではプライマリカテゴリしか変更できないため、結局上記の時間のかかる個別エントリ編集画面で作業しなければならない。
…といったことで困っています。 個人的な要望としては以下のとおりです。
●カテゴリ編集画面を、ページ分割表示するようにして欲しい。
●カテゴリ編集画面で、複数のカテゴリを一度に移動できるようにして欲しい。
●エントリ一括編集画面で、プライマリ以外の所属カテゴリも変更できるようにして欲しい。
●カテゴリ表示の処理（JavaScript）の軽量化。特にブラウザが入力を受け付けなくなるのは困るので改善して欲しい。
DTIのVPSサーバでmt.cgiの処理時間を計測してみました。
http://dqn.sakusakutto.jp/2011/07/movabletype-time-watch.html
１画面に7秒というのは遅すぎるので、やはりアプリ(Perlスクリプト)を高速化するべきと思います。
JavaScriptの高速化は優先順位が低いと思います。 クライアントPCの高性能化とブラウザの高速化競争が日々進んでいますから、MT側で何もしなくてもどんどん速くなります。
逆に、サーバサイドの高速化は、MTを改良することで解決するしかありません。
確かにCGIのプロセスは遅いですよね。memchacedやFastCGIを導入してもやはりサクサク感とはほど遠いなぁといつも思います。
プレビュー画面が遅いのが一番不満です。 DTIのVPSサーバで６～７秒ほどかかります。
mt_sessionテーブルのsession_dataの中身を取得して表示するようにすれば大幅に高速化できるのではないでしょうか？
試しにcgiでプレビュー画面を自作してみたら、300msで表示できました。(20倍高速化) SQLはこんなんです。ご参考まで。 "select session_data from mt_session where session_kind = 'AS' AND session_id like 'autosave:%type=entry:id=0:blog_id=1%'"
自作CGIでここまで速くできるのだから、MT管理画面が遅いのはCGIのせいではなくMTに原因があると思われます。
PSGI化でだいぶ速くなりましたね！
DTI VPSで２倍速くなりました。 http://dqn.sakusakutto.jp/2012/04/movabletype-psgi-starman.html
これはうれしいです。 ありがとうございました。 > Sixapartさん
管理画面のDOMをFirebugで見ると、やたらと無駄なクラス名が与えられているなと感じます。 IE6をサポートしなくなり、:first-child擬似クラスや属性セレクタを使えるようになった今、first-childとかcheckboxとかそういうクラス名は不要なはずです。 こういう細かい無駄を取り除いていけば、少しは軽くなるような気がします。
HTMLやMTタグを含む内容は、 このツールでエンコードしてから 投稿してください。
最新のトピック: 【MT東京主催】春のプラグイン祭り開催のお知らせ (2016年4月12日 Maki Sawa)
最新のトピック: 公開終了日の取り消し (2013年10月18日 gsk)
最新のトピック: MovableTypeのバックアック (2018年4月 2日 kazu)
最新のトピック: カテゴリ記事リストにカスタムフィールドが表示されない (2018年2月 3日 k_n)
最新のトピック: 再構築トリガーで特定のウェブページを再構築 (2018年4月24日 sousou)
最新のトピック: テーマのエクスポート時にlinked_fileを対象に含めて欲しい (2017年4月 3日 riatw)
最新のトピック: 先ほど質問した件解決いたしました。 (2018年1月17日 tmo)
MTの問題というよりもPerl CGIの問題も大きいかと思うので、FastCGIやmod_perlで実際の運用に耐えうるレベルの対応や十分なテストと、そのあたりを整備した環境の普及なんかを考えた方がはやいかもしれませんね。
一方で例えばカテゴリの一覧がページ送りがないのでカテゴリを数百登録すると500エラーになったりとか、MT側で出来ることもあるかと思います。
MT3.xの管理画面はMT5よりもずっと軽かったので、CGIの仕組みだけの問題だけではないでしょう。
MT自体が巨大化したことや、管理画面でJavaScriptを多用するようになったことも、原因として大きいと思います。
MT内部的には、まずはJavascriptの統合、軽量化でしょうか
そういう環境で作るなって言われたら仕方ないんですが、
FireFox＋FireBugs環境で動かしてると重いなんてこともありますね。
こういう環境だと重くなるよ的な知見がどっかにあつまってるとうれしいかも。いやその重さの責任、半分君だしみたいな。でも、上記のような環境でも速度低下しないようなことは検討しておくべきかも。
Perl環境のチューニングは、root運用が前提だし、リソース不可を考えると共用機に実施されることはないでしょう。小規模以下案件では、指加えるだけになるか、責任おってデザイナーがバックエンドまで手をだすかの２択になるのは避けたい。
ビジネス的にはそこで差別化できるのだけど、提案者の多くはそこで勝負したくない、出来ないと思ってる人が多いとおもいます。僕もその一人なので（デザイナとしてはやってしまってるほうだと思うけど）
古いトピックにコメントしてしまいますが、私も管理画面の重さに悩まされています。
私の場合、MTで作品データベースを作っていて、カテゴリが6000個ほどあるので、通常の使用方法から外れていると思うのですが。
●カテゴリ管理画面を表示するのに数分かかる
●カテゴリを移動するのに数分かかる
●エントリ編集画面で、カテゴリリストを表示するのに1分ほどかかる（しかもその間にブラウザが他の操作を全く受け付けなくなる）
●エントリの所属するカテゴリを編集したいことが多いのですが、エントリ一括編集画面ではプライマリカテゴリしか変更できないため、結局上記の時間のかかる個別エントリ編集画面で作業しなければならない。
…といったことで困っています。
個人的な要望としては以下のとおりです。
●カテゴリ編集画面を、ページ分割表示するようにして欲しい。
●カテゴリ編集画面で、複数のカテゴリを一度に移動できるようにして欲しい。
●エントリ一括編集画面で、プライマリ以外の所属カテゴリも変更できるようにして欲しい。
●カテゴリ表示の処理（JavaScript）の軽量化。特にブラウザが入力を受け付けなくなるのは困るので改善して欲しい。
DTIのVPSサーバでmt.cgiの処理時間を計測してみました。
http://dqn.sakusakutto.jp/2011/07/movabletype-time-watch.html
１画面に7秒というのは遅すぎるので、やはりアプリ(Perlスクリプト)を高速化するべきと思います。
JavaScriptの高速化は優先順位が低いと思います。
クライアントPCの高性能化とブラウザの高速化競争が日々進んでいますから、MT側で何もしなくてもどんどん速くなります。
逆に、サーバサイドの高速化は、MTを改良することで解決するしかありません。
確かにCGIのプロセスは遅いですよね。memchacedやFastCGIを導入してもやはりサクサク感とはほど遠いなぁといつも思います。
プレビュー画面が遅いのが一番不満です。
DTIのVPSサーバで６～７秒ほどかかります。
mt_sessionテーブルのsession_dataの中身を取得して表示するようにすれば大幅に高速化できるのではないでしょうか？
試しにcgiでプレビュー画面を自作してみたら、300msで表示できました。(20倍高速化)
SQLはこんなんです。ご参考まで。
"select session_data from mt_session where session_kind = 'AS' AND session_id like 'autosave:%type=entry:id=0:blog_id=1%'"
自作CGIでここまで速くできるのだから、MT管理画面が遅いのはCGIのせいではなくMTに原因があると思われます。
PSGI化でだいぶ速くなりましたね！
DTI VPSで２倍速くなりました。
http://dqn.sakusakutto.jp/2012/04/movabletype-psgi-starman.html
これはうれしいです。
ありがとうございました。 > Sixapartさん
管理画面のDOMをFirebugで見ると、やたらと無駄なクラス名が与えられているなと感じます。
IE6をサポートしなくなり、:first-child擬似クラスや属性セレクタを使えるようになった今、first-childとかcheckboxとかそういうクラス名は不要なはずです。
こういう細かい無駄を取り除いていけば、少しは軽くなるような気がします。