開発日記
早速 1.4.4 に移行したサイトが出始めている様ですね :)
ブレストあるいは対談†
- 09/05 の早朝に移行しました(勝手に追記していいのかわからないけど） :) -- romap 2004-09-08
- Σ（ ´∀｀） 早！(移行も反応も) -- henoheno
- どんな風になると／どんな機構があると今後もっと維持が楽になりそうですか？ 折角ですので、率直なご意見をお聞かせ下さい :) *1 -- henoheno
- メニューが無いページについてレンダリング済みの圧縮データをキャッシュしておいて、ブラウザにそれを送りつける事でで転送量を削減できないか (Read-onlyの運用が前提のサイトであるromapであれば、矛盾なく効果が出せるのではないか)、なんて事を考えていた今日このごろです。 -- henoheno
- ああメニュー部分も普通のMenuBarとサブメニューを使い分け、(要所を除いて)固定メニューにすれば、(不自然でない)キャッシュ(が)可能かも。 -- henoheno
- あのページの運用ですが、メインのコンテンツは実データをテキストとして保存しておいて、それをPerlで整形したものをFTPでアップしてるという流れになっています。現状でも特に不満はﾅｲのですが、一点だけ。上で少し出てますがレンダリング済みのキャッシュデータを保存しておいて変更がなければキャッシュデータを使う。というような感じになればいいなぁと思ってます。http://romap.xrea.jp/index.php?mapのページとかだと1秒ほど時間がかかってるようなので。 -- romap
- って。1.4.3のときには1.2秒ほどかかっていたんですが、今再チェックすると0.6秒ですね。 -- romap
- あまりこちらに書くのも気が引けるんですが、キャッシュデータの有効利用に関してはうまく結果が出せるのではないか？と思って居ます。 一日の総リクエスト数が400kほどありますので。これから少し減るとは思いますが・・・ -- romap
- マップの方ですが、(これは凄い使い方ですね :) ) 私は 単ページの convert time よりも ref プラグインで出力されている多量の画像ファイルが気になっています。これはまだ改善の余地があると思っているのですが、ここまで多数の画像を処理させると、ちょっとイメージ展開の遅さが気になりますね。 -- henoheno
- レンダリング結果のキャッシングについては、静的なデータを前提としたページ作りが前提になるわけですが、そうであれば、初めから「他のページへのリンク」をレンダリングする直前に、そのページの有無をチェックする機構そのものをバイパスさせればもっと速度が上がると思われます。そういったread-only運用向けのチューンも(速度面では)有効そうですね。(dangling link機能のオフ) -- henoheno
- あ、私が考えていたレンダリング結果の保存というのは、レンダリング結果を圧縮しておいて、それを受け取ることができるブラウザにはそのまま送りつける ということにより転送量低下が図れるのではないか、という事でした。gzが受け取れないブラウザには毎回レンダリングさせるつもりでした。gzが受け取れないブラウザについては、転送量に違いが出ないですからね (^^; -- henoheno
- ∑('-';) ﾊｯ!! 対談になってるっ マップの方ですがあれはメインとして置いてる分けではないのでアクセス数は1日100行くかどうか？という所なので負荷とかはあまり気にしていません。階層構造上作っただけなので。でも、他にも20前後の画像を展開してるページはあるので改善できるようでしたらお願いしたいです。 -- romap
- レンダリングの件はちょっと勘違いしてたようですね。henohenoさんの言うようなものであれば、サイトへのアクセスの８０％前後がIE6ですので劇的に変化すると思います。問題は各ページにコメント欄があるので完全な静的なページというのは無いという件でしょうか・・・ (^^; -- romap
- ちょっと書き忘れた事があり、自分でも少し改造していて時間があれば続きをするんですが、ls2プラグインに更新時間順に並べるというオプションがあればかなり運営の面で楽になります。 というのも、各ページのコメントを投稿できるようになってるんですが、前に80件とか投稿があるときがあり、チェックするのに苦労した覚えがあります。 毎回最終更新を80とか100にするのも無駄なときが多いので。 まぁこれは欲しいプラグインに出す内容ですが・・・--; -- romap
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
