2014/12/03(水)ECO-Wikiでの画像縮小・拡大

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

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

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

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

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

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

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

今後の画像提供について

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

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

*1 : 最近の環境・ブラウザならこんな事を気にする必要は無いかもしれません。今は亡きIE6のリサイズは汚かったような・・・。

*2 : JPEGのジェネレーションロスを考えると画像編集は1回ですませたいという気持ちもありますが

2014/11/29(土)製法データベース公開

製法データベース公開

本日製法データベースを公開しました。

不具合がありましたら、報告をお願いしますm(_ _)m


今は「総合レシピカタログ」があるので、データはカタログを見ながら見直しました(生成確率とか)。あと、手数料は面倒だったのでどこまできっちり入力されているかよく分からなかったので、初期データでは不明扱いにしています。

そういえば、総合レシピカタログって、作成できるアイテムの個数が出ないんですね。微妙な所に不便が・・・^^;

追記

合成データベース→製法データベースに名称変更。

2014/11/22(土)アイテムデータベース公開

アイテムデータベース公開

作成に結構時間がかかってしまいましたが、本日アイテムデータベースを公開しました。

投稿テストをしたい方は、以下にテスト用ページを設置しましたので、こちらで動作確認してみてください。

例によって、まだバグが残っているかもしれないので、見つけた人は報告をお願いしますm(_ _)m

2014/11/21(金)9th Anniversaryイリスカード 入手確率

9th Anniversaryイリスカード 入手確率

No.カード名右手左手両手合計
割合[%]割合[%]割合[%]割合[%]
AC39-4010アルティ270.90%301.00%381.27%951.06%
AC39-4020御魂・ヒスイ260.87%200.67%331.10%790.88%
AC39-5010御魂全員集合!913.03%862.87%802.67%2572.86%
AC39-5020ロア全員集合!2862.87%953.17%762.53%2572.86%
AC39-6010御魂・ミコト2006.67%1856.17%1795.97%5646.27%
AC39-6020御魂・メイ1745.80%1675.57%1876.23%5285.87%
AC39-6030御魂・ライ1735.77%1735.77%1856.17%5315.90%
AC39-6040御魂・キリエ1675.57%1986.60%1876.23%5526.13%
AC39-6050御魂・セレス1725.73%1655.50%1986.60%5355.94%
AC39-6060御魂・ルリ1665.53%1735.77%1886.27%5275.86%
AC39-6070御魂・フォルテ1866.20%1625.40%1926.40%5406.00%
AC39-6080御魂・エリーゼ1816.03%1695.63%1775.90%5275.86%
AC39-6090御魂・アリア2016.70%1846.13%1876.23%5726.36%
AC39-6100御魂・ナナイ1876.23%1996.63%1444.80%5305.89%
AC39-6200御魂・リーリエ1866.20%1806.00%1846.13%5506.11%
AC39-7010レイミ2719.03%2618.70%2357.83%7678.52%
AC39-7020クリエ2518.37%2829.40%2438.10%7768.62%
AC39-7030フェネアン&シュレム2558.50%2719.03%2879.57%8139.03%
合計3000100.00%3000100.00%3000100.00%9000100.00%

SRは1%くらいで、まあ普通?右手、左手、両手の違いが相変わらずよく分からない。

2014/11/20(木)CGI(PHP)とCacheやLast-Modified

CGI(PHP)とCacheやLast-Modified

ECO-Wiki (acronia) 設定メモで $lastmod = 1; の設定をしてみましたが、BugTrack/763-負荷対策のまとめ-キャッシュを生かすをみると、これだけではIf-Modified-Sinceの判定などは行われないとのことで、あまり意味がなさそうでした。

そこで、実際に確認してみました。まず、初回アクセス。

[Request]
GET /wiki/ HTTP/1.1
Host: eco.acronia.net
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

[Response]
HTTP/1.1 200 OK
Date: Wed, 19 Nov 2014 12:58:24 GMT
Server: Apache/2.2.25
Cache-Control: no-cache, max-age=10
Pragma: no-cache
Last-Modified: Sat, 15 Nov 2014 14:57:47 GMT
Expires: Wed, 19 Nov 2014 12:58:34 GMT
Keep-Alive: timeout=5, max=20
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=EUC-JP

確かに、Last-Modifiedは出力されています。また、no-cacheも返しているのでPukiWikiとしてはキャッシュして欲しくなさそうです。

そして、2回目のアクセス。

[Request]
GET /wiki/ HTTP/1.1
Host: eco.acronia.net
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Sat, 15 Nov 2014 14:57:47 GMT

[Response]
HTTP/1.1 304 Not Modified
Date: Wed, 19 Nov 2014 12:58:02 GMT
Server: Apache/2.2.25
Connection: Keep-Alive
Keep-Alive: timeout=5, max=17
Expires: Wed, 19 Nov 2014 12:58:12 GMT
Cache-Control: no-cache, max-age=10

ブラウザはIf-Modified-Sinceを送っていました。no-cacheは「キャッシュしても良いけど毎回確認してね」くらいの意味合いなので、この挙動自体はまあ普通です。*1

そして、なぜかレスポンスは「304 Not Modified」。つまり、サーバー側でIf-Modified-Sinceを解釈して更新されていないと返答したことになります。しかし、PukiWikiのソースコードを探してもそんなことをしている記述はなさそう、う~ん(ーー;)

そこでもっと調べてみると、どうやらスクリプトがLast-Modifiedを返すと、CGIがIf-Modified-Sinceと比較してNot Modifiedかどうか判断してくれる、らしいです。なにそれΣ('◇'*)

ただ、phpスクリプトはIf-Modified-Sinceなんか見ずに普通に動いている訳なので、

  • Not Modifiedでもサーバー側のCPU負荷とかはたぶん通常と同じだけかかる
  • データは送られないので、通信量は削減できる

ということになるでしょうか。う~ん、微妙(・・?)

そして、問題なのはPukiWikiのLast-Modifiedは、#pcommentや#include*2を見ていないので、コメントが書き込まれてもキャッシュが更新されずにそれが見えないという現象が起こります(;^_^A

というわけで、$lastmodの設定は元に戻すことにしました。

ちゃんとキャッシュするには?

クライアントキャッシュをちゃんと使うなら、以下の対応が必要でしょうか。

  • phpスクリプトでIf-Modified-Sinceを見て、Not Modifiedなら処理をスキップする
  • 以下のどちらかの方法で#pcommentや#includeに対応
    • Last-Modifiedを調べるときに#pcommentや#includeもたどる
    • コメントや被includeファイルを更新したとき、親ファイルの更新日時も変える

#pcommentや#includeもたどるのは、結局ファイルを読む必要があるので負荷を下げたいという目的を考えると微妙です。その点では同時更新が有力ですが、コメントはともかくincludeの対応はちょっと難しいですね。(親ファイルを探す方法を考えないといけない。)

いろいろ手間がかかりそうなのでこれはやらないと思います^^;

*1 : もしかしたら、PukiWikiとしては期待していない動作かもしれませんが。

*2 : たぶん、MenuBarもだめ

PukiWiki bodycache

bodycacheの動作テストをしているのですが、これも更新日時判定の問題で#pcommentや#includeが存在するページは対象外とするようです。ただ、#pcommentについては対策パッチが出ています。(親ファイルの更新日時も変える方式。)

#includeを使っているページは少なくないですが、それ以外のページだけでも負荷が減るなら適用してみても良いかな。