共有ﾚﾝﾀﾙｻｰﾊﾞ
【粘って解決】
日々積み重ねてきた記事が200を超えた頃からか、ﾌﾞﾛｸﾞ記事の更新を行うと頻繁に"Internal Server Error"が発生するようになりました。
とりあえずの対応（その1）で、だましだまし使ってきましたがどうもｽｯｷﾘしません。
もう少し粘ってみることにします。
根気にﾈｯﾄ検索していると「ｻﾑﾈｲﾙを作成するImageDriverが負荷をかけている場合がある」という記事を見つけました。
ｱｯﾌﾟﾛｰﾄﾞした画像のｻﾑﾈｲﾙ生成に必要なものですが、初期状態ではImageMagickﾗｲﾌﾞﾗﾘとImage::MagickというPerlﾓｼﾞｭｰﾙが使われています。
Websiteと各ﾌﾞﾛｸﾞのﾄｯﾌﾟﾍﾟｰｼﾞに記事ﾘｽﾄを表示するときにｻﾑﾈｲﾙ画像を生成しています。
ﾌﾞﾛｸﾞ記事の概要ﾃﾝﾌﾟﾚｰﾄで「MTAssetThumbnailURL」というﾀｸﾞを使い、記事のURLとLinkさせています。
ﾘｽﾄでは全部の記事にｻﾑﾈｲﾙを生成するため、ｻｰﾊﾞへ相当の負荷がかかっているものと思います。
試しにConfigﾌｧｲﾙ設定から一時的にImageMagickを外してみます。
CMSを作動させると"ｲﾒｰｼﾞﾄﾞﾗｲﾊﾞｰが設定されていません。"と表示。
この状態でﾌﾞﾛｸﾞ記事の更新を実行してみると、"ものすごくｽﾑｰｽに再構築"されました。
やはり「ImageDriver」がｻｰﾊﾞにかなりの負荷をかけているようです。
そうはいっても記事ﾘｽﾄにｻﾑﾈｲﾙがなくなるのはﾃﾞｻﾞｲﾝ的にも見栄えが良くありません。
さらにﾈｯﾄ検索を続けるとImageDriverの種類に、動作が軽いといわれる「NetPBM」があることを知りました。
期待を込めてｻｰﾊﾞ管理画面のPerlﾓｼﾞｭｰﾙを閲覧しましたが「NetPBM」はありません。
そこでﾚﾝﾀﾙｻｰﾊﾞ管理者あてに"NetPBMﾓｼﾞｭｰﾙをｲﾝｽﾄｰﾙして欲しい"旨の問い合わせをしました。
返ってきたﾒｰﾙは、"共有ﾚﾝﾀﾙｻｰﾊﾞのため、他のお客様へ影響する可能性があるため、個別の導入につきましては対応できかねる。"という回答でした。
ImageDriverを変更するという方法は、断念せざるを得ません。（ｶﾞｯｸﾘ）
気を取り直して、ﾚﾝﾀﾙｻｰﾊﾞ管理画面のｴﾗｰﾛｸﾞを見ることにします。
ｱﾙﾌｧﾍﾞｯﾄの羅列の中で、"File does not exist: /image"を見つけましたが無視。（多分ImageDriverの関連）
もう一つは、"Premature end of script headers"。
「CGIﾌﾟﾛｸﾞﾗﾑが適切なHTTPﾍｯﾀﾞを出力していない」ということのようです。
ﾌﾞﾛｸﾞ記事更新時に"Internal Server Error"が出るまでの時間を計ってみると、およそ13秒でした。
どうも共有ｻｰﾊﾞに時間制限がかけてあるようです。
またまたﾚﾝﾀﾙｻｰﾊﾞ管理者に問い合わせてみると、"CPU時間使用量を制限する設定は【10秒】。10秒より上げてしまうとｻｰﾊﾞの過負荷が発生する可能性があるため変更できない。 "という回答でした。
これでｷﾞﾌﾞｱｯﾌﾟか。
そうかといって、年老いた田舎のﾗｼﾞｵ少年のﾌﾞﾛｸﾞに高額な専用ｻｰﾊﾞを使う訳にもいきません。
もうちょっと粘って、「10秒」以内にﾘｽﾄ抽出・ｻﾑﾈｲﾙ生成が終わるように工夫すればいいんでは、と考え方を変えます。
１回の再構築で処理する記事の数を指定する「EntriesPerRebuild」という環境変数があることが分かりました。
ﾃﾞﾌｫﾙﾄでは、1回に付き40記事を再構築し、それが終わると次の40記事に取りかかるとあります。
ということは・・・
Configﾌｧｲﾙで「EntriesPerRebuild 10」を設定します。
次に、Websiteの全般設定の中に、"再構築の速度向上のために、ﾃﾝﾌﾟﾚｰﾄﾓｼﾞｭｰﾙ毎のｷｬｯｼｭ設定を有効にする"というのがあるので、ﾁｪｯｸを入れます。
その1でも行いましたが、記事の抽出関連のﾃﾝﾌﾟﾚｰﾄを再点検します。
Websiteのﾒｲﾝﾍﾟｰｼﾞは、lastn 999⇒20に変更。
次に、Websiteのﾌﾞﾛｸﾞのﾒｲﾝﾍﾟｰｼﾞ。
全ﾌﾞﾛｸﾞ（12）から新しい記事順にﾘｽﾄｱｯﾌﾟするﾒﾆｭｰですが、その1では全く忘れていました。
何と言っても全部の記事を抽出しｻﾑﾈｲﾙを生成する訳なので、ｻｰﾊﾞ過負荷の大きな要因となっています。
ここも最新の記事20だけの表示とします。lastn 999⇒20に変更。
各ﾌﾞﾛｸﾞの記事数は50以下なので、当面はﾃﾞﾌｫﾙﾄのままとします。
これで個人でできる対策は全部講じました。
さあ、MovableType5の管理画面を起動させ記事の更新を実行します。
ﾌﾞﾛｸﾞ記事の更新⇒ﾌﾞﾛｸﾞ再構築⇒Website再構築へとｽﾑｰｽに移行。
記事概要にｻﾑﾈｲﾙが生成され、ﾄｯﾌﾟﾍﾟｰｼﾞの記事ﾘｽﾄが出来上がりました。
見事に"10秒の壁"を超えました。（大げさ？）
【粘って解決】
日々積み重ねてきた記事が200を超えた頃からか、ﾌﾞﾛｸﾞ記事の更新を行うと頻繁に"Internal Server Error"が発生するようになりました。
とりあえずの対応（その1）で、だましだまし使ってきましたがどうもｽｯｷﾘしません。
もう少し粘ってみることにします。
根気にﾈｯﾄ検索していると「ｻﾑﾈｲﾙを作成するImageDriverが負荷をかけている場合がある」という記事を見つけました。
ｱｯﾌﾟﾛｰﾄﾞした画像のｻﾑﾈｲﾙ生成に必要なものですが、初期状態ではImageMagickﾗｲﾌﾞﾗﾘとImage::MagickというPerlﾓｼﾞｭｰﾙが使われています。
Websiteと各ﾌﾞﾛｸﾞのﾄｯﾌﾟﾍﾟｰｼﾞに記事ﾘｽﾄを表示するときにｻﾑﾈｲﾙ画像を生成しています。
ﾌﾞﾛｸﾞ記事の概要ﾃﾝﾌﾟﾚｰﾄで「MTAssetThumbnailURL」というﾀｸﾞを使い、記事のURLとLinkさせています。
ﾘｽﾄでは全部の記事にｻﾑﾈｲﾙを生成するため、ｻｰﾊﾞへ相当の負荷がかかっているものと思います。
試しにConfigﾌｧｲﾙ設定から一時的にImageMagickを外してみます。
CMSを作動させると"ｲﾒｰｼﾞﾄﾞﾗｲﾊﾞｰが設定されていません。"と表示。
この状態でﾌﾞﾛｸﾞ記事の更新を実行してみると、"ものすごくｽﾑｰｽに再構築"されました。
やはり「ImageDriver」がｻｰﾊﾞにかなりの負荷をかけているようです。
そうはいっても記事ﾘｽﾄにｻﾑﾈｲﾙがなくなるのはﾃﾞｻﾞｲﾝ的にも見栄えが良くありません。
さらにﾈｯﾄ検索を続けるとImageDriverの種類に、動作が軽いといわれる「NetPBM」があることを知りました。
期待を込めてｻｰﾊﾞ管理画面のPerlﾓｼﾞｭｰﾙを閲覧しましたが「NetPBM」はありません。
そこでﾚﾝﾀﾙｻｰﾊﾞ管理者あてに"NetPBMﾓｼﾞｭｰﾙをｲﾝｽﾄｰﾙして欲しい"旨の問い合わせをしました。
返ってきたﾒｰﾙは、"共有ﾚﾝﾀﾙｻｰﾊﾞのため、他のお客様へ影響する可能性があるため、個別の導入につきましては対応できかねる。"という回答でした。
ImageDriverを変更するという方法は、断念せざるを得ません。（ｶﾞｯｸﾘ）
気を取り直して、ﾚﾝﾀﾙｻｰﾊﾞ管理画面のｴﾗｰﾛｸﾞを見ることにします。
ｱﾙﾌｧﾍﾞｯﾄの羅列の中で、"File does not exist: /image"を見つけましたが無視。（多分ImageDriverの関連）
もう一つは、"Premature end of script headers"。
「CGIﾌﾟﾛｸﾞﾗﾑが適切なHTTPﾍｯﾀﾞを出力していない」ということのようです。
ﾌﾞﾛｸﾞ記事更新時に"Internal Server Error"が出るまでの時間を計ってみると、およそ13秒でした。
どうも共有ｻｰﾊﾞに時間制限がかけてあるようです。
またまたﾚﾝﾀﾙｻｰﾊﾞ管理者に問い合わせてみると、"CPU時間使用量を制限する設定は【10秒】。10秒より上げてしまうとｻｰﾊﾞの過負荷が発生する可能性があるため変更できない。 "という回答でした。
これでｷﾞﾌﾞｱｯﾌﾟか。
そうかといって、年老いた田舎のﾗｼﾞｵ少年のﾌﾞﾛｸﾞに高額な専用ｻｰﾊﾞを使う訳にもいきません。
もうちょっと粘って、「10秒」以内にﾘｽﾄ抽出・ｻﾑﾈｲﾙ生成が終わるように工夫すればいいんでは、と考え方を変えます。
１回の再構築で処理する記事の数を指定する「EntriesPerRebuild」という環境変数があることが分かりました。
ﾃﾞﾌｫﾙﾄでは、1回に付き40記事を再構築し、それが終わると次の40記事に取りかかるとあります。
ということは・・・
Configﾌｧｲﾙで「EntriesPerRebuild 10」を設定します。
次に、Websiteの全般設定の中に、"再構築の速度向上のために、ﾃﾝﾌﾟﾚｰﾄﾓｼﾞｭｰﾙ毎のｷｬｯｼｭ設定を有効にする"というのがあるので、ﾁｪｯｸを入れます。
その1でも行いましたが、記事の抽出関連のﾃﾝﾌﾟﾚｰﾄを再点検します。
Websiteのﾒｲﾝﾍﾟｰｼﾞは、lastn 999⇒20に変更。
次に、Websiteのﾌﾞﾛｸﾞのﾒｲﾝﾍﾟｰｼﾞ。
全ﾌﾞﾛｸﾞ（12）から新しい記事順にﾘｽﾄｱｯﾌﾟするﾒﾆｭｰですが、その1では全く忘れていました。
何と言っても全部の記事を抽出しｻﾑﾈｲﾙを生成する訳なので、ｻｰﾊﾞ過負荷の大きな要因となっています。
ここも最新の記事20だけの表示とします。lastn 999⇒20に変更。
各ﾌﾞﾛｸﾞの記事数は50以下なので、当面はﾃﾞﾌｫﾙﾄのままとします。
これで個人でできる対策は全部講じました。
さあ、MovableType5の管理画面を起動させ記事の更新を実行します。
ﾌﾞﾛｸﾞ記事の更新⇒ﾌﾞﾛｸﾞ再構築⇒Website再構築へとｽﾑｰｽに移行。
記事概要にｻﾑﾈｲﾙが生成され、ﾄｯﾌﾟﾍﾟｰｼﾞの記事ﾘｽﾄが出来上がりました。
見事に"10秒の壁"を超えました。（大げさ？）
以前はｺﾒﾝﾄ投稿でもｴﾗｰが発生しておりましたが、今回の対策で正常に投稿できるようになりました。
数少ない読者の皆様、ｺﾒﾝﾄをお待ちしております。
よろしくお願いします。