雑記帳 - JasminInfo

リソース状況 その3

日曜前後に山があって、大局的にはアクセスはだんだん増えてる傾向でしょうか。とはいえ、今のところは問題になるような感じでもないですね。

時間ができたら、bodycache patchを #include を使っているページにも適用できるように改造したいところ。

ECO-Wiki (acronia) スパム状況

頻度はそれほどではないですが、今までの所上記のようなスパム投稿がありました。

なんだか、無意味な単語投稿と、宣伝スパムの2種類があるような感じです。

香港の人はECO関係の掲示板*1から来ていたようですし、コメント欄があったので何か書いてみたくなったのかな？

今のところ、スパムっぽいのは全部国外アクセスのようなので、国外からのコメント投稿とページ編集を禁止して様子を見ようかと思います。

ECO-Wikiでの画像縮小・拡大

ECO-Wikiを眺めていて気づいたのですが、ECO-Wikiに掲載されている画像の中にはサイズ指定でブラウザ側で画像縮小・拡大されているものがあります。

例えば、きらめく人魚姫・ローレライの画像は、414px × 595pxなのですが、ペット一覧表 （ロア）＞きらめく人魚姫・ローレライでは 155px × 222px で表示されています。

ただ、この方法ってデメリットがあるので、私は避けるようにしてました。

• ブラウザ側での縮小なので転送量は減らない（→元画像をあらかじめ縮小すれば転送量を減らせる）
• 拡大・縮小にともなう画質劣化、ブラウザの処理量増加*1（→ちゃんとした画像編集ソフトで縮小した方が良い）
• 指定がまずいとアスペクト比が狂う
  • ただ、ECO-Wikiの画像についてはアスペクト比はきっちり考慮して指定されているようです。各画像についてちゃんと計算するのは大変だったのではないかと思います。

おそらくECO-Wikiの場合、画像提供者がたくさんいて画像サイズがそろっていなかったけど、編集者としてはレイアウト上画像サイズを統一する必要があってこのような指定をすることにしたのではないかと思います。あとは、編集者が画像を簡単に差し替えることができなかったというのもあったでしょうし。

今なら私が元画像のサイズを変更することはできるので、時間あるときに差し替えようかなと思います。もしかしたら、元画像が必要なこともあるかもしれないので、 KiramekuNingyohimeLoreley.jpg → KiramekuNingyohimeLoreley_t.jpg のように新しいファイル名で縮小画像を作るのが良いかな。

今後の画像提供について

理想としては、画像サイズを指定しておいて、画像提供者がそのサイズで提供するということになるのでしょうけど、あまり規定が多いと面倒かもしれないですね。

せっかく自由にアップロードできるようにしているので、提供者は大きめの画像で提供してもらって編集者がリサイズ*2した画像を別名でアップロードするのでも良いかもしれません。

リソース状況 その2

• 主なイベント
  • 2014/11/05(水): 公開。
  • 2014/11/14(金)ごろ: 画像ファイルのクライアントキャッシュを有効にした。PukiWikiの設定見直し。
• ページビューはWikiのページ参照を全部カウント（画像アクセスなどはWikiページではないので含まない）。
• CPU使用時間とウェブ転送量は3:00～翌3:00が集計期間。ページビューの集計は0:00～翌0:00。

何とも言えませんが、とりあえず今のところは負荷が増える傾向ではなさそうです。もっとも、次のアップデート後にはアクセスが増える可能性がありますが＾＾；

2014/11/09のアクセス数が妙に多いのは巡回ソフトでのアクセスがあったようです。

画像アップローダー更新

ECO-Wiki用の画像アップローダーのメニュー部とメイン部を独立にスクロールできるようにしました。

その結果、echo.jsがスクロールイベントを拾わなくなったのでちょっと中を弄る羽目に(^_^;)

IE7は見捨てました(。・・。)。全く閲覧できないわけではない感じでしたが…。

• 設定変更
  • pukiwiki.ini.php
  • default.ini.php
• 見た目周り
  • pukiwiki.skin.php
  • pukiwiki.css (pukiwiki.css.php)
• プラグイン
  • counter.inc.php
  • source.inc.php
  • 追加

続きを読む