2015/01/20(火)ECO-Wiki画像リサイズ
ECO-Wiki画像リサイズ
こちらの記事(ECO-Wikiでの画像縮小・拡大)でふれていた、ブラウザ側でリサイズされていた画像について、一部*1をリサイズ済みの画像と差し替えました。元画像は、サフィックス _big を付けたファイル名にリネームして残してあります。
- 例
ECO-Wiki上の画像サイズ指定について
画像差し替えの際に、画像の実サイズと表示サイズを一通りチェックしたのですが、想像していた以上にいい加減でした^^;
例としては、
- 実サイズ:177x111 → 表示サイズ:100x100
- 縦横比が合っていない
- 実サイズ:128x128 → 表示サイズ:127x127
- 周りの画像は表示サイズ128x128に統一しているのに何故か1ピクセルだけ縮小
- 実サイズ:128x123 → 表示サイズ:123x128
- 縦と横が逆
単純ミスのものもあるでしょうし、既存の記述をコピーして修正したときに画像サイズ指定をそのままにしてしまったという可能性もありそうです。不特定の人が編集する場合は、画像サイズ指定は省略した方が無難なのかもしれないですね*2。
画像アップローダーは実サイズを指定した&ref記述を生成するので、これをそのまま使ってくれる分には問題はなさそうですが。
「アンケートページ:今後の ECO wiki について」のコメント
最近、「アンケートページ:今後の ECO wiki について」をチェックしていなかったので気づくのが遅れましたが、
装備品データベース等を面倒ではあるが独立したWikiとしての公開をするべきと思う
acroniaでは別のサイトに飛ぶが検索する閲覧者に酔ってみれば使い勝手が良い物とは言えない
というコメントが付いてますね。
ただ、このコメントの意図がよく分からないです。
- 「検索」がWikiの検索機能を指す場合
- 独立したWikiでは検索は結局別々なので解決にならない。
- 今のECO-Wikiに含めるなら検索はできますが、ECO-Wikiが肥大化しかねない。
- 「検索」がGoogle等の検索を指す場合
- データベースが検索にかかるようにすることを考えるべき。*3
あと、データベースにしておかないと、細かな条件を付けた検索や、データの機械的な再利用が困難になるので、よほどの事が無ければデータベース化が望ましいと思います。
・・・というか、Wiki管理だと数が多すぎて破綻しそう^^;*4
2015/01/08(木)圧縮転送による読込時間改善、他
圧縮転送による読込時間改善
以前、ECO-Wiki (acronia) でページ生成時間を表示するようにしましたが、内容が多いページではかなり時間がかかっているのが気になりました。
例えば、Iris/Explanationでは
HTML convert time: 0.007 sec. (total: 2.447 sec.)
と数秒かかり、実際に体感できるロード時間も同程度です。
これは、Iris/Explanationだとページ(HTML)サイズが約700kBとちょっとした画像並みに大きいため、単純に転送に時間がかかっていると思われます。
そこで、転送データをgzip圧縮して転送量を削減してみることにしました。さくらのレンタルサーバーは半年くらい前からmod_deflateが使えるようになったらしいので、以下の記述*1を .htaccess に追記します。
<FilesMatch "\.php$"> SetOutputFilter DEFLATE BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html AddOutputFilterByType DEFLATE text/html </FilesMatch>
2015/01/03(土)ECO-Wiki (acronia) 状況
2014/12/14(日)リソース状況 その3
リソース状況 その3
日付 | ページビュー | グラフ | CPU使用時間 | グラフ | ウェブ転送量 | グラフ |
---|---|---|---|---|---|---|
2014/12/13 | 60255 | 2時間38分56秒 | 4.96GB | |||
2014/12/12 | 46571 | 2時間13分13秒 | 4.15GB | |||
2014/12/11 | 24631 | 1時間47分 9秒 | 4.32GB | |||
2014/12/10 | 24959 | 2時間 5分46秒 | 4.32GB | |||
2014/12/09 | 27210 | 1時間51分48秒 | 4.80GB | |||
2014/12/08 | 25372 | 1時間56分48秒 | 4.25GB | |||
2014/12/07 | 34138 | 2時間39分52秒 | 6.19GB | |||
2014/12/06 | 32728 | 2時間25分14秒 | 5.57GB | |||
2014/12/05 | 29505 | 2時間17分 2秒 | 5.06GB | |||
2014/12/04 | 25888 | 2時間21分15秒 | 5.01GB | |||
2014/12/03 | 24984 | 1時間44分50秒 | 4.17GB | |||
2014/12/02 | 22825 | 1時間42分57秒 | 3.95GB | |||
2014/12/01 | 24100 | 1時間43分 2秒 | 3.66GB | |||
2014/11/30 | 29206 | 2時間 2分 3秒 | 4.88GB | |||
2014/11/29 | 25177 | 1時間48分32秒 | 4.13GB | |||
2014/11/28 | 18354 | 1時間27分12秒 | 3.06GB | |||
2014/11/27 | 18493 | - | - | |||
2014/11/26 | 19682 | 1時間27分52秒 | 3.35GB | |||
2014/11/25 | 18971 | 1時間27分52秒 | 3.29GB | |||
2014/11/24 | 23916 | 1時間45分41秒 | 4.07GB | |||
2014/11/23 | 20239 | 1時間30分58秒 | 3.36GB | |||
2014/11/22 | 19867 | 1時間29分49秒 | 3.37GB | |||
2014/11/21 | 16170 | 1時間16分 7秒 | 2.75GB | |||
2014/11/20 | 15450 | 1時間19分22秒 | 2.49GB | |||
2014/11/19 | 12708 | 1時間10分52秒 | 1.77GB | |||
2014/11/18 | 12545 | 1時間 39秒 | 1.86GB | |||
2014/11/17 | 13939 | 1時間 6分 2秒 | 1.84GB | |||
2014/11/16 | 14340 | 1時間 9分48秒 | 1.89GB |
日曜前後に山があって、大局的にはアクセスはだんだん増えてる傾向でしょうか。とはいえ、今のところは問題になるような感じでもないですね。
時間ができたら、bodycache patchを #include を使っているページにも適用できるように改造したいところ。
2014/12/04(木)ECO-Wiki (acronia) スパム状況
ECO-Wiki (acronia) スパム状況
日付 | 種別 | 内容 | アクセス元 |
---|---|---|---|
2014/11/24 | pcomment | Quest/Waterlayer | 台湾 |
2014/11/25 | pcomment | 油 | 香港 |
2014/11/29 | pcomment | (URLの羅列) | ウクライナ |
2014/12/01 | pcomment | アニバーサリーBOX | タイ |
2014/12/02 | newpage | (宣伝スパムっぽい) | U.S. |
2014/12/03 | newpage | (宣伝スパムっぽい) | U.S. |
頻度はそれほどではないですが、今までの所上記のようなスパム投稿がありました。
なんだか、無意味な単語投稿と、宣伝スパムの2種類があるような感じです。
香港の人はECO関係の掲示板*1から来ていたようですし、コメント欄があったので何か書いてみたくなったのかな?
今のところ、スパムっぽいのは全部国外アクセスのようなので、国外からのコメント投稿とページ編集を禁止して様子を見ようかと思います。