MovableTypeの再構築エラー
MovableType3.2を導入した時に、私のような初心者が一番悩むのが『再構築の時のエラー』ではないでしょうか。
正直、ここで使うのやめようかと思ったくらいです。
胃がキリキリしました(笑
ロリポップの場合、再構築に失敗するとロリポップねーさんが出てくるわけですが、段々ねーさんの顔が鬼に見えて来ましたもの。
「くっそー！何で出来ないんだっ！！」
ほとんど毎日寝不足でした。
これは結局MovableTypeがサーバに負担をかけるもので、再構築の際にタイムアウトになってしまうからだそうです。
回避する方法として、次のようなものが有ります。
mt→mt-config.cgiに書かれている【# EntriesPerRebuild 40】というのはエントリー数を40個ずつ再構築するというもので、これを減らしてやるとタイムアウトしなくて済む（のではないか）と。
mt/mt-config.cgiの中に有ります
# EntriesPerRebuild 40
を
EntriesPerRebuild 10
に減らしてみます。
そうすると、再構築数が10個単位で行われるというわけです。
先頭に記述されている【# 】は取り除き、反映させるのを忘れないこと。
結局私はこれで回避出来ず、現在は5個単位にしています。
もう、イヤになるくらい時間が掛かりますから(涙)
これで回避した人も居れば、全くダメという場合が有ります。
他の、月間・カテゴリ等で失敗してしまう。
ということで、こちらも負荷をかけないような設定を。
mt→lib→MT→App→CMS.pmをダウンロードして書き換えます。
Individual => 1,
Daily => 2,
Weekly => 5,
Monthly => 10,
Dynamic => 5,
何となく見れば「こいつかな」というのが解ります。
なので、こいつを
Individual => 1,
Daily => 2,
Weekly => 3,
Monthly => 5,
Dynamic => 3,
とかに減らします。
もうこの辺は個人個人の予想といいますか、『この数字が良い』なんてものは有りませんので、1つずつ減らしてテストするとかしてみないと解りませんです。
現在どうなっているかというと、エラーは出にくくなりましたが、再構築の時間が掛かり過ぎるのがストレスになっています。
たまにエラー出るし。
尚、この時点でSQLiteへの変換は済んでいます。
何故SQLiteにしたかというと、ロリポップの場合はSQLiteが最速だと、どこかで読んだからです。
これでは全く満足出来なかった私は、ダイナミックパブリッシングにしてみることにしました。
これも「ダイナミックパブリッシングは素晴らしく速く、エラーが出ない」と、どこかで読んだからです(こればっかり)。