2014/11/29(土)製法データベース公開
製法データベース公開
本日製法データベースを公開しました。
不具合がありましたら、報告をお願いしますm(_ _)m
今は「総合レシピカタログ」があるので、データはカタログを見ながら見直しました(生成確率とか)。あと、手数料は面倒だったのでどこまできっちり入力されているかよく分からなかったので、初期データでは不明扱いにしています。
そういえば、総合レシピカタログって、作成できるアイテムの個数が出ないんですね。微妙な所に不便が・・・^^;
追記
合成データベース→製法データベースに名称変更。
2014/11/22(土)アイテムデータベース公開
アイテムデータベース公開
作成に結構時間がかかってしまいましたが、本日アイテムデータベースを公開しました。
投稿テストをしたい方は、以下にテスト用ページを設置しましたので、こちらで動作確認してみてください。
例によって、まだバグが残っているかもしれないので、見つけた人は報告をお願いしますm(_ _)m
2014/11/21(金)9th Anniversaryイリスカード 入手確率
9th Anniversaryイリスカード 入手確率
No. | カード名 | 右手 | 左手 | 両手 | 合計 | ||||
---|---|---|---|---|---|---|---|---|---|
数 | 割合[%] | 数 | 割合[%] | 数 | 割合[%] | 数 | 割合[%] | ||
AC39-4010 | アルティ | 27 | 0.90% | 30 | 1.00% | 38 | 1.27% | 95 | 1.06% |
AC39-4020 | 御魂・ヒスイ | 26 | 0.87% | 20 | 0.67% | 33 | 1.10% | 79 | 0.88% |
AC39-5010 | 御魂全員集合! | 91 | 3.03% | 86 | 2.87% | 80 | 2.67% | 257 | 2.86% |
AC39-5020 | ロア全員集合!2 | 86 | 2.87% | 95 | 3.17% | 76 | 2.53% | 257 | 2.86% |
AC39-6010 | 御魂・ミコト | 200 | 6.67% | 185 | 6.17% | 179 | 5.97% | 564 | 6.27% |
AC39-6020 | 御魂・メイ | 174 | 5.80% | 167 | 5.57% | 187 | 6.23% | 528 | 5.87% |
AC39-6030 | 御魂・ライ | 173 | 5.77% | 173 | 5.77% | 185 | 6.17% | 531 | 5.90% |
AC39-6040 | 御魂・キリエ | 167 | 5.57% | 198 | 6.60% | 187 | 6.23% | 552 | 6.13% |
AC39-6050 | 御魂・セレス | 172 | 5.73% | 165 | 5.50% | 198 | 6.60% | 535 | 5.94% |
AC39-6060 | 御魂・ルリ | 166 | 5.53% | 173 | 5.77% | 188 | 6.27% | 527 | 5.86% |
AC39-6070 | 御魂・フォルテ | 186 | 6.20% | 162 | 5.40% | 192 | 6.40% | 540 | 6.00% |
AC39-6080 | 御魂・エリーゼ | 181 | 6.03% | 169 | 5.63% | 177 | 5.90% | 527 | 5.86% |
AC39-6090 | 御魂・アリア | 201 | 6.70% | 184 | 6.13% | 187 | 6.23% | 572 | 6.36% |
AC39-6100 | 御魂・ナナイ | 187 | 6.23% | 199 | 6.63% | 144 | 4.80% | 530 | 5.89% |
AC39-6200 | 御魂・リーリエ | 186 | 6.20% | 180 | 6.00% | 184 | 6.13% | 550 | 6.11% |
AC39-7010 | レイミ | 271 | 9.03% | 261 | 8.70% | 235 | 7.83% | 767 | 8.52% |
AC39-7020 | クリエ | 251 | 8.37% | 282 | 9.40% | 243 | 8.10% | 776 | 8.62% |
AC39-7030 | フェネアン&シュレム | 255 | 8.50% | 271 | 9.03% | 287 | 9.57% | 813 | 9.03% |
合計 | 3000 | 100.00% | 3000 | 100.00% | 3000 | 100.00% | 9000 | 100.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の対応はちょっと難しいですね。(親ファイルを探す方法を考えないといけない。)
いろいろ手間がかかりそうなのでこれはやらないと思います^^;
PukiWiki bodycache
bodycacheの動作テストをしているのですが、これも更新日時判定の問題で#pcommentや#includeが存在するページは対象外とするようです。ただ、#pcommentについては対策パッチが出ています。(親ファイルの更新日時も変える方式。)
#includeを使っているページは少なくないですが、それ以外のページだけでも負荷が減るなら適用してみても良いかな。
2014/11/17(月)リソース状況 その2
リソース状況 その2
日付 | ページビュー | グラフ | CPU使用時間 | グラフ | ウェブ転送量 | グラフ |
---|---|---|---|---|---|---|
2014/11/16 | 14340 | 1時間 9分48秒 | 1.89GB | |||
2014/11/15 | 20001 | 1時間31分48秒 | 1.88GB | |||
2014/11/14 | 17541 | 1時間37分45秒 | 2.78GB | |||
2014/11/13 | 16821 | 2時間 4分 3秒 | 3.56GB | |||
2014/11/12 | 16062 | 2時間16分 9秒 | 3.61GB | |||
2014/11/11 | 15511 | 2時間 8分32秒 | 3.27GB | |||
2014/11/10 | 10881 | 1時間37分43秒 | 2.51GB | |||
2014/11/09 | 35546 | 2時間 6分36秒 | 4.20GB | |||
2014/11/08 | 27376 | 2時間 6分47秒 | 3.18GB | |||
2014/11/07 | 6394 | 1時間 6分49秒 | 1.68GB | |||
2014/11/06 | - | 58分13秒 | 1.65GB | |||
2014/11/05 | - | 43分 2秒 | 945.6MB | |||
2014/11/04 | - | 20分41秒 | 627.5MB |
- 主なイベント
- 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は見捨てました(。・・。)。全く閲覧できないわけではない感じでしたが…。