雑記帳 - JasminInfo

アクセス数制限と負荷対策

アクセス数制限

さくらインターネットのコントロールパネルを見ると、しばらく前からアクセス制限がかかっているようです。

アクセスログを見ても、上のグラフの通り、21日以降は「503 - Service Unavailable」がいくつか発生しています。

原因

ちょっと調べてみました*1が、この制限は、転送量ではなくて同時アクセス数によるようです。

ログを見ると503になっているのは画像が多くて、他はJavaScript/CSSファイル、若干のWikiページでした。（もっとも、これだけだと単にアクセスされるリソースの中で画像が一番多いからそうなっただけかもしれませんが。）アクセスされている画像を確認してみると、モンスター、家具ページなど画像が多いページから参照されている画像が多く、画像が多いページへのアクセスが要因になっている可能性があります。

対策

画像が多いページへの対策としては、表示されている範囲＋αの画像だけを読み込む遅延ロードを既に行っていますが、これはどちらかというと転送量対策で同時アクセス数はあまり気にしていませんでした。（ただ、快適さをできるだけ損なわないように＋αをかなり大きくしていたので、2/26頃に少し範囲を絞りました。）

そこで、現在使っている遅延読み込みプログラムを少し改造して、画像の同時読み込み数を最大2に制限してみることにしました。とりあえず、これで少し様子を見てみます。

JavaScript/CSSファイルも影響しているかもしれないので、画像のようにキャッシュを強く効かせる*2ようにしても良いかもしれません。

もうちょっと根本的な対策としては、画像を別のサーバーに置くことでしょうか。

制限の解除

リソース情報に記載されている「制限」について｜さくらインターネット公式サポートサイトによると、対応完了後にメールで連絡すると、制限を解除してくれるようです。

でも、制限されない程度に対策する必要があるなら制限はあってもなくても同じような・・・。

最近2ヶ月は、負荷状況はほとんど変化していなかった（どちらかというと減少傾向）ので、何がトリガーになって制限されたのかは聞いてみても良いかもしれません。（制限されたタイミングがたまたま2/21だっただけで、もともと制限されるようなアクセス数だったのかもしれないですが。）

追記

21日頃からサーバーのload averageが増えていたので、サーバー全体としての負荷が増えたのを契機に制限をかけることにしたのかもしれません。

ECO-Wiki (acronia)のfavicon

今置いてあるfaviconは、ECO-Wiki(gamedb)のをとりあえずそのまま使っていますが、

• ECO-Wiki(gamedb)が復活したので同じだとちょっと紛らわしい
• 高解像度のfaviconも準備しておきたい

などの理由で新しいfaviconを置きたいと思っています。

そこで、とりあえずプルル・アルマのSSから作ってみたのですが、どうも16×16の画像が微妙な感じ・・・。まあこの大きさだと、どこかで妥協は必要だと思いますが。

• 案1:

  

  -

  

  ※16x16はこっちが良さそう？
• 案2:

  

  -

  

  -

  

• 案3:

  

  -

  

  -

  

  ※高解像度用(16x16は参考)

あとは、題材はこのままプルル・アルマにするのかという問題もありますね。（結構作るのに時間かかったので、私としてはもうこのままでいいかな、という気分になっちゃってますが＾＾；）

pukiwiki bodycache patch 2重include対応

以前、#includeを含んだページで更新時にキャッシュが再生成されるような改良を行いましたが、この改良では上図のように#includeや#pcommentが2重に使われていると、キャッシュが正しく再生成されないことが分かりました。

このような場合、一番深いページを更新したときに、最上位のページのキャッシュが再生成されずに残ってしまいます。これは、キャッシュを再生成するページを探すときに、#includeや#pcommentを更新されたページから1段しかたどっていないために発生する現象です。

そこで、更新時に2段までページをたどってキャッシュを再生成するように変更しました。これで、2重include/pcommentまでなら正しくキャッシュが再生成されるようになります。

ただし、3重include/pcommentには未対応です。対応は難しくありませんが、たどる段数を増やすとその分負荷も増えるので、2重までの対応としています。

見出しタイトル化のバグ

タイトルプラグイン(PukiWiki)導入に合わせて、最初に出現したレベル1見出しをタイトル扱いにする改造を行いましたが、バグがあったようです。（季節イベントページをみていて気づきました。）

• 発生条件: includeプラグインが使われており、includeで参照しているページにレベル1見出しが含まれている
• 現象: レベル1見出しが含まれる最後のincludeがタイトルとして使われてしまう。
• 原因: includeを使うとconvert_htmlが複数回呼ばれることを考慮していなかった。その結果、後で呼び出されたconvert_htmlにより見出しから抽出したタイトルが上書きされていた。
• 修正前: Heading->Heading() 内の改造箇所

  if( $this->level === 1 && !isset( $root->title ) ){
      $root->title = preg_replace('|\s*\[.*|', '', $text);
      $root->title = preg_replace('|^\*\s*|', '', $root->title);
  }
  

• 修正後: Heading->Heading() 内の改造箇所

  //初回呼び出し時は $root->id は 1
  if( $this->level === 1 && !isset( $root->title ) && $root->id === 1 ){
      $root->title = preg_replace('|\s*\[.*|', '', $text);
      $root->title = preg_replace('|^\*\s*|', '', $root->title);
  }
  

また、includeプラグインの参照先ページにtitleプラグインが含まれている場合も、同様にincludeしたページのタイトルが優先されてしまうと思われます。ただ、このような使い方はたぶんしないと思うので、こちらの問題はそのままにしておこうかと思います。

続・PukiWiki bodycache patch副作用：id重複

PukiWiki bodycache patch副作用：id重複で適用した修正ですが、不十分だったようです＾＾；

原因は、やはりconvert_htmlが複数回呼ばれることを考慮していなかったことで、

function convert_html($lines)
{
	//省略
	static $contents_id = 0;
	global $bodycache_status;
	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
		++$contents_id;
	}
	//省略
	$body = & new Body(++$contents_id);
	//省略
}

この修正では、includeによる2回目のconvert_html出力と、メニューバーの$contents_idが共に2になってid重複してしまいます。

ものすごく場当たり的ですが、以下のように再修正しました。

	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
		$contents_id += 90 ; //これだけ足せばきっと重複しない・・・(^_^;)
	}

いっそ、メニューバーでは見出しの自動id生成をやめた方が良い気もしてきましたが、メニューバーだけ自動id生成をやめる方が修正は面倒そうです。（もしかしたら、本文も自動id要らないかも？）

PukiWiki UTF-8版とEUC-JP版

今の ECO-Wiki (acronia) はEUC-JP版

PukiWikiにはUTF-8版とEUC-JP版がありますが、現在はEUC-JP版を採用しています。理由としては、

• 元のECO-WikiがEUC-JPだった
• UTF-8版にすると転送量が増える
• UTF-8版にするとPukiWikiが内部的に使用するファイル名が長くなる
• UTF-8版にするとURLが長くなる（けど、そんなに大した問題ではないかな）
• UTF-8はあまりおすすめしないような記述があった*1

などです。

UTF-8版にするべきか

ただ、最近はUTF-8版にした方が良いかなと考え始めてます。

• 最近の文字コード事情はUTF-8が主流
• PukiWiki公式でもUTF-8推奨になった（PukiWiki開発日記、PukiWiki 1.5.0ダウンロード）
• 転送量は圧縮が効いていればそんなに問題ないかも

とはいえ、EUC-JPで困っているというわけでもないのでUTF-8版に置き換えるかどうかはちょっと悩ましいところです。

UTF-8版にするなら、PukiWiki 1.5.1のリリースに合わせることになるでしょうか。

UTF-8版にする場合の課題

• ファイルなどを全部UTF-8に変換する必要がある
  • 変換スクリプトが作られているようなので、これで変換を試みることになりそうです。
• （英数字以外をページ名に含む）各ページのURLが変わってしまう
  • 検索エンジンなどからのリンクが切れてしまうので、存在しないページにアクセスされたら、EUC-JP版URLへのアクセスと解釈して301 Moved Permanentlyで新URLに転送するような仕組みを入れたいところです。
    • と思って探してみたら、同じ事をやってた人がいました→PukiwikiをEUC→UTF-8移行した後もEUCのURLでアクセスできるようにする - あっきぃ日誌