■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50
read.cgi 2006―JavaScriptはCGIの夢を見るか
- 71 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 19:04:57 ID:6gP6+0Mt0
- >>70
やりたいこと＆目標は
http://qb5.2ch.net/test/read.cgi/operate/1153615149/775
＞おいらはブラウザ派なのですな。
＞
＞javascriptだけで、read.cgiが実現できるんじゃないかと、
＞前から思ってるんですが、誰か試してみないすかね。
じゃなかったっけ？
- 72 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 19:07:02 ID:zo6Ee0v80
- >>71
それ、>>70と矛盾してる？
- 73 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 19:08:22 ID:hZZWHB7M0
- つまりread.cgiの負担を減らす事かと
- 74 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 19:09:03 ID:+1rXbJLeP
- 目標は>>70、やりたいことは>>71で。
- 75 ：外野ｧｧﾝ ：2006/07/26(水) 19:16:29 ID:WJtZ0RWx0
- >>70がrootくんが独自に掲げたお題だっていうなら納得
>>70がひろゆきくんからの指令だって言うなら否定
- 76 ：root▲ ★ ：2006/07/26(水) 19:28:22 ID:???0 BE:1915373-BRZ
- >>70は、私の位置づけです。
で、それがたまたま、管理人の興味と一致したので、
私もやる気になった。
ということだと思います。
- 77 ：root▲ ★ ：2006/07/26(水) 19:31:58 ID:???0 BE:2919348-BRZ
- なので、私は >>70の目的が実現できるのであれば、
別にその手段が JavaScript である必要はかならずしもなくて、
別のものでもいいと思っているです。
JavaScript 以外の候補としては、
・flash
・Java
なども、あると思っています。
で、私としては管理人が「JavaScript 以外のものは使うな。これは私の命令です」
と言わない限り、可能性はより多いほうがいいなと考えています。
つまり、上記に JavaScript も含めたそれぞれの
・メリット
・デメリット
・実現可能性
などなどの要素を総合的に評価したうえで、
目標実現のためにどんな道具を使うのがいいか、決めたいかなと。
- 78 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 19:34:30 ID:ax/3R4o80
- だったらActiveXでWebブラウザ上に2chブラウザ再現しちゃえば良いじゃん。IE限定だけど
- 79 ：root▲ ★ ：2006/07/26(水) 19:36:47 ID:???0 BE:4378368-BRZ
- >>78
それも、手段としてはありえますね。
今 >>78さんは「IE限定」と書かれていたわけですが、
目的の実装に使う手段を選ぶときには、そういったファクター(汎用性とか)も、
当然考慮するべきものの一つなのかなと。
- 80 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 19:44:51 ID:9rtlkJef0
- IETabみたいに、レンダリングエンジンをうまく
ごにょごにょすればfirebirdでも大丈夫だぜ
- 81 ：stream ◆PNstream2s ：2006/07/26(水) 19:57:39 ID:kXk1e64C0
- >>78>>80
うーん、read.cgiの代わりだからなあ。2ch独自のものを導入させるってのは違うと思う。
JavaScriptにしてもFlashにしてもJavaアプレットにしても、2ch独自じゃないし。
- 82 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 20:10:42 ID:kV/VHu8d0
- 2001年の閉鎖危機の時にもread.cgiをjavascriptで代用するという案があったけど、
当時は互換性うんたらかんたらで却下されました。
- 83 ：stream ◆PNstream2s ：2006/07/26(水) 20:24:33 ID:kXk1e64C0
- んで、mod_charset_lightでUTF-8に変換してみたけど、うまくいきますね。
ただ、Shift_JIS的におかしなデータがdatファイルに存在すると500 Internalサーバーエラーになるっぽいですね。
- 84 ：root▲ ★ ：2006/07/26(水) 20:33:31 ID:???0 BE:2918584-BRZ
- >>83
なるほど。
ただこの場合、コード変換の分だけ、サーバは仕事をすることになりますね。
read.cgi 動かすのとどっちが負荷がトータルで低くなるか、が、
重要なポイントの一つなのかな。
あとは、ユーザに影響が出ないように実装できるのか、とか。
いずれにせよ、
> ただ、Shift_JIS的におかしなデータがdatファイルに存在すると
> 500 Internalサーバーエラーになるっぽいですね。
は、ちょっといまいちなのかなと。
- 85 ：stream ◆PNstream2s ：2006/07/26(水) 20:34:48 ID:kXk1e64C0
- >>84
それは詳しい人のフォロー待ちです
マニュアルちょっと読んで試しただけなんで
- 86 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 21:08:04 ID:kV/VHu8d0
- IEのデータバインディングを使って、datをcsvとして読み込むという方法もあるのかな。
http://www.microsoft.com/japan/msdn/columns/dude/dude1103.aspx
ここのサンプルなんかはSJISのデータファイルを読み込んでる。
http://himuka.miyazaki-c.ed.jp/db/kyouzai/manual/orienteering2/ogura/sample.htm
- 87 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/26(水) 21:20:34 ID:oRQikQhd0
- Java アプレットは重い（特に VM 起動時）ですからね......
Flash は Java よりは軽いでしょうけど，（文字列の扱いにもよるのかも
知れませんが）文字化けすることもあって......まぁこちらの環境は少数派でしょうけど．
http://sunos.saita.ma/read-js/test/flash.png
JavaScript はブラウザによって挙動不審になったりとかする部分もあったりするのが
苦労するところですが，それを乗り越えれば一番お手軽ではあるんですよね．
あと，フィルタモジュールの負荷ってことなら，文字コード変換より圧縮，
つまり mod_deflate の方がよほど重いかと．
- 88 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 21:22:52 ID:+1rXbJLeP
- ここで空気を読まずにJSP
- 89 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 21:29:57 ID:gpcl/1Jf0
- JSPって↓のようなやつだっけ？
＜%
for(int i = 0; i < bbs.getLastNum(); i++){
%＞
メッセージ：＜%= bbs.getMessage() %＞＜br＞
＜%
}
%＞
- 90 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 21:30:19 ID:wK/+H917P
- Web製作板でJavaScript版
プログラム板でJava Applet版
Flash板でFlash版
を作ればいいんでね？盛り上がりそうｗ
- 91 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 21:36:49 ID:8Qn/kEiJ0
- SunがMicrosoftのVM潰さなければねぇ。
独自拡張もあったにしろMicrosoftの方が早かったのに。
- 92 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 22:19:15 ID:ax/3R4o80 BE:76951139-2BP
- JSPはサーバサイドだからあんま意味なくね？
それとも実はものごっつ軽いとか？
- 93 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 23:03:24 ID:RjRvuw4Y0
- いや、別にJSPがものごっつ軽いとかは無い。
普通にサーバサイドだし。
- 94 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/26(水) 23:10:45 ID:oRQikQhd0
- 不正なバイトシーケンスを無視して 500 エラーにしないようにするパッチ．
--- httpd-2.2.2/modules/filters/mod_charset_lite.c Sat Apr 22 10:53:06 2006
+++ httpd-2.2.2/modules/filters/mod_charset_lite.c Sat Apr 22 10:53:06 2006
@@ -188,6 +188,31 @@
return NULL;
}
+static apr_status_t _xlate_conv_buffer_no_eilseq(apr_xlate_t *convset,
+ const char *inbuf,
+ apr_size_t *inbytes_left,
+ char *outbuf,
+ apr_size_t *outbytes_left)
+{
+ apr_status_t rv;
+
+ while (inbytes_left && outbytes_left) {
+ apr_size_t inbytes = *inbytes_left, outbytes = *outbytes_left;
+
+ if ((rv = apr_xlate_conv_buffer(convset, inbuf, inbytes_left,
+ outbuf, outbytes_left)) != APR_EINVAL) /* EILSEQ */
+ break;
+ if (*inbytes_left)
+ inbuf += inbytes - --(*inbytes_left);
+ if (*outbytes_left)
+ (outbuf += outbytes - --(*outbytes_left))[-1] = '?';
+ }
+
+ return rv != APR_EINVAL ? rv : APR_SUCCESS;
+}
+
+#define apr_xlate_conv_buffer _xlate_conv_buffer_no_eilseq
+
/* find_code_page() is a fixup hook that decides if translation should be
* enabled; if so, it sets up request data for use by the filter registration
* hook so that it knows what to do
- 95 ：ゴッド便所 ◆AKQJ10itoI ：2006/07/26(水) 23:13:58 ID:sAti+2UJ0 BE:280560948-BRZ
- 文字コード変換でサーバーにかかる負担はどれくらいなんだ？
- 96 ：動け動けウゴウゴ２ちゃんねる ：2006/07/26(水) 23:33:57 ID:9rtlkJef0
- 文字コード変換もjava scriptで。
- 97 ：root▲ ★ ：2006/07/27(木) 00:01:42 ID:???0 BE:1459744-BRZ
- >>90
それぞれの住民が、競い合って作るというのはどうか。
>>94
おぉ。
これでいけるなら、文字コード変換のコストは
それほどでもないと。
あとは、/板名/dat だと今までの dat を生読みして、
/板名/datutf8 だと mod_filter かました結果で出る、
というふうにできると、いいのかな。
mod_proxy 使えばできそうな気がするんですが、どうやるのがいいんだろうか。
- 98 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 00:17:17 ID:tvu0ZHE80
- jspは意味無いでしょ・・・
折角、サーバ側で読み出しの負荷を下げようというのに・・・
- 99 ：stream ◆PNstream2s ：2006/07/27(木) 00:21:06 ID:5ofr++i80
- >>97
板のディレクトリのところに dat-utf8 とかでdatディレクトリに対しシンボリックリンク作って
そこへのアクセスはmod_charset_liteを使うようにするとか
これだと各サーバーの各板でシンボリックリンクを張る作業しなきゃいけないから大変？
- 100 ：root▲ ★ ：2006/07/27(木) 00:26:22 ID:???0 BE:729942-BRZ
- >>99
めんどそうだなぁ。
- 101 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 00:35:54 ID:YpMYl/gy0
- <ぼそ>スイスアーミーナイフ</ぼそ>
- 102 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 00:44:39 ID:86/KPhLr0
- rangeで**バイト以降のデータをリクエストしたら、変換後のバイト数で来るんだよね。
- 103 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 18:42:21 ID:viWF9XEA0
- ブラウザによって違う動作といえば、Gecko系のXMLHttpRequestは
同一ホストか同一ドメインに限られていたような。
これは各サーバに入れておけば済む問題だが。
- 104 ：root▲ ★ ：2006/07/27(木) 20:07:57 ID:???0 BE:2919348-PLT(10000)
- JavaScript は、結構方言が多いんですかね。
大きく分けると、
・IE 系
・Gecko 系
・Opera 系
・Safari 系
ぐらい?
- 105 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 20:26:48 ID:mkOYbx750
- そこにバージョンの差とかいろいろ
- 106 ： ◆Reffiz2Zh. ：2006/07/27(木) 20:32:55 ID:6s+Ev8y+0
- >104
分類すると
・ＩＥ−Ｓｕｎ系 ＭＳ系
・Ｇｅｃｋｏ−1.5系 2.0系 3.0系
ＯｐｅｒａとＳｕｆａｒｉは使ったことがないので補足ﾖﾛ
- 107 ： ◆Reffiz2Zh. ＠ｒｅｆｆｉ@報告人 ★ ：2006/07/27(木) 20:34:59 ID:???0
- >106
Ｇｅｃｋｏ間違えて炎狐でやっちゃった
・Ｇｅｃｋｏ−1.8.0系（炎狐1.0.x） 1.8.1系（炎狐2.0） 1.9系（炎狐3.0）
- 108 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 20:37:27 ID:E06nA/kZ0
- Safariは1.X系と2.X系…か？
- 109 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 20:45:01 ID:/QbR/fVa0
- SafariはKHTML系の一部だろ。
他にKonquerorとかある。
- 110 ：あまた ◆GOKvPKrEQ. ：2006/07/27(木) 20:58:53 ID:F/NtCPlN0 BE:528612487-2BP(33)
- Operaって
ttp://www.opera.com/docs/specs/js/
こんなでいいの？
- 111 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/27(木) 21:19:09 ID:fWmc8hHl0
- >>102そうなります......と言いたいところですが，基本的に chunked 転送となって
Range は効かないかと．もっとも，Range を効かせた場合は mod_deflate で
圧縮するわけにはいかない（Range 指定しても圧縮後の内容に対して
Range が効いてしまうため）とか，キャッシュと Range の相性もよろしくない
ってことで，果たしていいのか悪いのか......
なお，前のパッチ以外にも修正した方がいい点があったので，パッチ更新版を．
http://sunos.saita.ma/read-js/test/mod_charset_lite.patch
ちなみに，httpd.conf の設定はこんな感じかな．
AliasMatch ^/(\w+)/dat-utf8/(\d+\.dat)$ /home/ch2xxx/public_html/$1/dat/$2
<Location /*/dat-utf8/*.dat>
SetOutputFilter XLATEOUT
CharsetSourceEnc CP932
CharsetDefault UTF-8
</Location>
Alias /test/bbs-utf8.cgi /home/ch2xxx/public_html/test/bbs.cgi
<Location /test/bbs-utf8.cgi>
SetInputFilter XLATEIN
CharsetSourceEnc CP932
CharsetDefault UTF-8
</Location>
- 112 ：root▲ ★ ：2006/07/27(木) 21:28:07 ID:???0 BE:5107687-PLT(10000)
- >>111
おぉ、、、。
これは、dso.2ch.net に入れると、
テストが可能になると言っていますか?
- 113 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/27(木) 21:33:51 ID:fWmc8hHl0
- >>111かもですね．ただ...... sunos.saita.ma で見ている限りでは，
mod_charset_lite で必要な APR-Util 中の apr_xlate_*() の関数群が
FreeBSD だと普通にビルドすると APR_NOTIMPL になっちゃうかも知れない
っぽいんで，ビルド時に細工してやらないとならないのかも......？
- 114 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/27(木) 21:39:59 ID:fWmc8hHl0
- >>113s/>>111/>>112/
....../include/apu.h 中の
#define APU_HAVE_APR_ICONV 0
#define APU_HAVE_ICONV 1
#define APR_HAS_XLATE (APU_HAVE_APR_ICONV || APU_HAVE_ICONV)
のところで APR_HAS_XLATE (== APU_HAVE_APR_ICONV || APU_HAVE_ICONV) が 0 に
なってるようだと，そのままでは使えないので細工の上 APR-Util のビルドし直しが必要かと．
- 115 ：動け動けウゴウゴ２ちゃんねる ：2006/07/27(木) 23:06:38 ID:qm7/fCsY0
- >>107
1.0 1.5 2.0?
- 116 ：tato ：2006/07/28(金) 00:17:25 ID:+swShs5T0
- この「CGIの夢を見るか 」スレから ここ↓「Ajaxでも語りませんか3」スレへ来られた方が
http://pc8.2ch.net/test/read.cgi/php/1147750917/
こんな質問↓をされているのですが、
http://pc8.2ch.net/test/read.cgi/php/1147750917/334
>IE6だと、最初のリクエストだとOK･･････304 Not Modified が返ってくると･････UTF-8と解釈して文字化け
この現象を確認できるページはどこかにあるでしょうか？
普通に考えると、304で表示されるのはキャッシュのはずですから、それが最初OKだったsjisではなく、UTF-8に解釈されてしまうとしたら、
個々のブラウザのローカルなエンコード設定の問題なような気もするのですが、何はともあれ、その現象がどこでも再現するのかを確かめたいと思いまして、、、。
- 117 ： ◆KAGESsh/NQ ：2006/07/28(金) 00:26:30 ID:BnqGP0Q/0 BE:5511348-2BP(111)
- >>103-107
参考になるのかな？
http://www.mozilla-japan.org/docs/web-developer/sniffer/browser_type_oo.html
＃Firefox は使い始めたばかりで、Mozilla(Gekko)、Firefox のバージョンの区別が…
- 118 ：stream ◆PNstream2s ：2006/07/28(金) 00:37:36 ID:azD6ToFp0
- >>116
http://210.235.206.47/read-js/test/read.html/linux/1082969833/
http://210.235.206.47/read-js/test/read.html/linux/1153390747/
こんな感じです
- 119 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 00:41:08 ID:lDXvnfU00
- 一瞬CPUファンがすごく回転した。コワス・・・
- 120 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 01:24:01 ID:3rgozFxf0
- とりあえず，UTF-8 の dat を取得する形で XMLHttpRequest 利用に戻しておいた．
ただ，sunos.saita.ma は共用サーバにつき自分で mod_charset_lite を組み込んだり
できないんで，UTF-8 に変換済みの dat を置いて代用......
http://sunos.saita.ma/read-js/operate/dat-utf8/
- 121 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 01:48:01 ID:r+F+KIBY0
- む、500になる。
- 122 ：tato ：2006/07/28(金) 02:00:54 ID:+swShs5T0
- キャッシュの再読み込み時に文字コード判定をUTF-8にしているようですね。
もし、キャッシュを無視する下記のような方法だとどうなるでしょうか？キャッシュは使えなくなりますが。。。
httpReq.open("GET", urlPrefix + "../" + paths[1] + "/dat/" + paths[2] + ".dat?"+(new Data()).getTime(),false);
#ところで、asyncがfalseのわけは？
- 123 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 02:02:23 ID:3rgozFxf0
- あ...... sunos.saita.ma には mod_headers が入ってなかったんだ......
- 124 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 03:16:41 ID:636jpKTQP
- JavaScript重すぎ。
- 125 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 04:32:41 ID:kVfCz8VA0 BE:99750757-BRZ(3183)
- http://pc8.2ch.net/test/read.cgi/php/1147750917/337の案って
<?xml version="1.0" encoding="Shift_JIS"?><response><![CDATA[
動け動けウゴウゴ２ちゃんねる<><>03/08/31 03:53 ID:xo367wqv<> 踏むとスレ立てしたり投稿したりするスクリプトにつて <br> 情報を集めたり対策したりするスレです。 <>■ スレ立て・投稿スクリプト対策
動け動けウゴウゴ２ちゃんねる<>sage<>03/08/31 03:53 ID:Xj/IL/tw<> ( ﾟдﾟ)ﾎﾟｶｰﾝ <>
動け動けウゴウゴ２ちゃんねる<>sage<>03/08/31 03:59 ID:xo367wqv<> http://okazu.bbspink.com/test/read.cgi/ascii/1062203672/13-<>
(略)
]]></response>
っていうはったりXMLをサーバーが用意。
※CDATAは、 ]]> だけが使えない。セクションの終りになっちゃうから。
文字コードの変換は行わないで、
＞<?xml version="1.0" encoding="Shift_JIS"?><response><![CDATA[
と、
＞]]></response>
で、はさむだけだから負荷はそんなにない感じ？
JavaScript側は
httpReq.responseText
を
httpReq.responseXML.documentElement.text
に変更するだけ。
って感じかな。誰かできる人試してくれ。
上手く行ったらBeをふりこんで置くように
- 126 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 07:18:47 ID:E5cyDbY60
- 今のread.cgiの出力を単純にこうするだけでもけっこう軽くなるでしょうか？
<form name="datForm">
<textarea style="display:none;" name="namaDat">
(ここにdatをそのまま出力)
</textarea>
</form>
<script src="lib.js"></script>
<script>
showThread(document.datForm.namaDat.value,1,1000);
</script>
- 127 ：tato ：2006/07/28(金) 09:46:52 ID:chE9END/0
- 今日、別のマシンのIE6で見たらリロードしても文字化けしていませんでした。もしかしてサーバー側で何か変りましたか？
ところで、
httpReq.open("GET", urlPrefix + "../" + paths[1] + "/dat/" + paths[2] + ".dat", false);
httpReq.send(null);
texts = httpReq.status == 200 ? httpReq.responseText.split("\n") : ["[エラー]<><>[エラー]<>[" + httpReq.statusText + "]<>[エラー]", null];
この部分ですが、このままですと着信待たずにresponseText要求して失敗する可能性が高いので、たとえば、
httpReq.onreadystatechange =function () {
texts = httpReq.status == 200 ? httpReq.responseText.split("\n") : ["[エラー]<><>[エラー]<>[" + httpReq.statusText + "]<>[エラー]", null];
}
httpReq.open("GET", urlPrefix + "../" + paths[1] + "/dat/" + paths[2] + ".dat", false);
httpReq.send(null);
オーソドックスにこんな方が良いのではないかと思います。
- 128 ：tato ：2006/07/28(金) 10:13:47 ID:chE9END/0
- >>125は、たぶん良い方法だと思います。が、
httpReq.responseXML.documentElement.text がおそらくOperaやFirefoxで動作しない気もしますので
普通に、
var xmlDoc = oj.responseXML
var nodes = xmlDoc.getElementsByTagName("response")[0].firstChild.nodeValue
などで取り出すのが良いかも。
- 129 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 10:43:15 ID:3rgozFxf0
- >>125それって，SSI 使えば結構簡単にできそう......と思ったけど，
SSI は普通にやると Last-Mod を吐かない，XBitHack 使って吐くようにしても
それはインクルードした dat の mtime ではなく外側の xml の mtime になってしまう，
ってことで，やるとしたら read.cgi のように DSO で dat を取り込んでそんな感じに
出力するってことになるかな．
てか，そもそも負荷軽減が目的でそういうことやるなら，現行の read.cgi にムダがないか
見直すのが先決という気も．read.cgi を介さず dat を直接返せば軽くなると言われてるけど，
mod_deflate 使わずに sendfile() で一気に送出するならともかく，実際は gzip 圧縮かけてますよね．
圧縮処理自体，文字コード変換や HTML 整形処理などと比べても結構重いはずです．
それにもまして read.cgi が重いとすれば，現状の read.cgi にムダがあることの現れではないかと．
現状では Last-Mod 吐いてないからキャッシュが効かないとか，（サブリクエストを使わなければならない
雪だるま鯖では仕方ないとして）mmap() 使わずにバッファに dat を読み込んでるとか，
その他 HTML 整形処理などももっと軽量化する余地がないかとか，そういうあたりのことを......
あと，read.cgi 出力に mod_cache かましたらどうか，ってのもあるか．
そうしたことを考えれば，JavaScript 版を作るのは負荷対策というより
「こういうこともできるのか」という技術的好奇心の側面の方が強いという気がします．
- 130 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 10:50:47 ID:3rgozFxf0
- >>127>>118のは最初に作った旧版で synchronous にデータを取得するため
onreadystatechange() を使ってませんでしたが，今の
http://sunos.saita.ma/read-js/test/read.htmlは
asynchrous にデータを取得するので使ってます．
- 131 ：stream ◆PNstream2s ：2006/07/28(金) 11:08:13 ID:F/mZ8+KK0
- >>118のページに、「文字化けデモです」と注意書きを入れました。
- 132 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 11:13:30 ID:YlQHVubn0
- >>129
> そうしたことを考えれば，JavaScript 版を作るのは負荷対策というより
> 「こういうこともできるのか」という技術的好奇心の側面の方が強いという気がします．
どこまでカリカリにチューニングしたって JavaScript を利用すれば結局
サーバ側の整形処理そのものを省略できるんだから負荷対策にはなるんじゃない。
- 133 ：tato ：2006/07/28(金) 11:24:05 ID:chE9END/0
- >>130了解しました。
>>131ちなみに、今日使っているマシンは(IE6.0.2900.2180.xpsp sp2 gdr.050301-1519)はリロードしても文字化けしていません。キャッシュの設定はいろいろ試しましたが文字化けしません。
http://sunos.saita.ma/read-js/test/read.html
はEUCなんですね。
あと、サーバー自身がtext/plain;charset=xxxを吐き出していないような気がするのですがどうなのでしょう？
- 134 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 11:41:20 ID:3rgozFxf0
- >>132その主張は一面では正しいと思います．ただ，PATH_INFO であれ QUERY_STRING であれ
URL で板・スレを指定する限りにおいてはムダなリクエストが増えるという側面もあります．
ページをロードするたびに read.html と *.dat をそれぞれロードするというのはもちろんですが，
別の板やスレを表示する場合 read.html そのものは変化しないにもかかわらず
ブラウザから見ると別のドキュメントとして新たに取得し直してしまいます．
例えば
/test/read.html/operate/1000000000/ と /test/read.html/operate/1000000001/
/test/read.html?bbs=operate&key=1000000000 と /test/read.html?bbs=operate&key=1000000001
どの場合でも read.html 自体は変化しないのですが，ブラウザから見ると
すべて別個のドキュメントとしてそれぞれに read.html をロードし直してしまうのです．
もちろん，それぞれのページ内でさらに *.dat を取得します．
そうした余分なリクエスト増加も勘案すれば，read.cgi をリファインした場合と比較して
果たしてどうなのか，というのも要考慮かと......
>>133現状のはとりあえず UTF-8 前提になってるので charset 指定を外してます．
- 135 ：tato ：2006/07/28(金) 11:50:21 ID:chE9END/0
- 今日使っている文字化けしないマシンを調べたら、どこの設定をいじっているのかは不明ですが、キャッシュが残らないようになっています。
つまり、毎回読みにいっているわけですけれど、少なくとも、このShift_JISの文字化けは、
キャッシュさえ読まなければ解決する可能性が高い気がします。
キャッシュのせいで、文字化けしたり、キャッシュが効きすぎて書き換わらないなどのトラブルが起きるよりも、毎回読みに行くとしても
no-cacheなどのほうが良いかも？という意味では、
<meta http-equiv="Expires" content="Sun, 10 Jan 1990 01:01:01 GMT" />
<meta http-equiv="Cache-Control" content="no-cache" />
<meta http-equiv="Pragma" content="no-cache" />
を書いたり、url+"?"+(new Date()).getTime()でキャッシュを無視したりする方がよいかもしれません。
- 136 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 11:52:56 ID:YlQHVubn0
- >>134
全部同じ HTML でいいんだから１画面フレームで表示、てのもできるけど、そうでなくても
<script type="text/javascript" src="****.js"></script>
と指定すればこのファイルはキャッシュされるよ。
> それぞれのページ内でさらに *.dat を取得します．
これは多分、read.cgi も同じでしょう。
Ajax スレの方に書いたけど、plain.cgi とか使えば最新 50 もできるよね。
- 137 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 12:06:36 ID:3rgozFxf0
- >>136いや，だから JavaScript 部分を分離しようがフレームを使おうが何だろうが，
外側の read.html 自体は板・スレが変われば別ドキュメントとして扱われる，
だからそのたびに新たにロードされる（余計な HTTP リクエストが発生する）
ということを言いたいわけですが......
>> それぞれのページ内でさらに *.dat を取得します．
>これは多分、read.cgi も同じでしょう。
少なくとも，read.cgi 自体が *.dat を HTML 整形する限りに置いては
HTTP リクエスト・レスポンスは1回だけで済むわけですが......
それとも，read.cgi がサーバ内で *.dat を読み込むって意味で言ってますか？
ネットワーク越しに HTTP リクエストを受け付けてクライアントに *.dat の内容を
返すのに比べれば，ローカルファイルを open(), mmap() して読み込むだけの
方が遙かに軽いわけですが......
- 138 ：136 ：2006/07/28(金) 12:07:04 ID:YlQHVubn0
- あーもっと簡単な方法に気づいた。
/test/read.html#/operate/1000000000/
location.hash で指定。ダメかな？
- 139 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 12:13:11 ID:3rgozFxf0
- >>138余計なリクエストを発生させないという点では有効でしょうけど，
その形式が普及するまでの間，既存の板・スレ指定を行った URL が残る限りは
効果を発揮しきれないかと．まぁ過去にも一度 QUERY_STRING から PATH_INFOへの
転換を行ってるので，そうした新形式への変換は必ずしも不可能ではないかも知れませんが......
- 140 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 12:28:17 ID:YlQHVubn0
- >>139
> 既存の板・スレ指定を行った URL が残る限りは効果を発揮しきれないかと．
あーそっか。そうだね。
>>137
> ローカルファイルを open(), mmap() して読み込むだけの
> 方が遙かに軽いわけですが......
でも、read.cgi はそれを更に整形してからネットワーク越しに送ってるんだよね？
送られるデータの量よりは、リクエストの数の方が問題なのかな。
- 141 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 12:34:38 ID:o51wigyx0
- >>140
read.cgiはさらに負荷もあるですよ
- 142 ：tato ：2006/07/28(金) 12:39:40 ID:chE9END/0
- 考えられるShft_JIS用文字化け対策リストはこんな感じ？
>>111utf-8専用のディレクトリ/dat-utf8/を作る
>>125respnseTextではなくrespnseXMLでcharsetを明示処理 -->Safari1.2でも動作可
>>135キャッシュ無効no-cache -->ユーザーの設定が優先されるので駄目かも＆負荷？
>>135キャッシュ無視url+"?"+(new Date()).getTime() -->read.htmlを何度でも呼ぶ負荷が気になる?
utf-8にしてもresponseTextではBOMを付けるなどの弊害もある細工が必要なので、
私はXMLを使う>>125がお勧めですが、.datの構造を変えるのは手間？
だめなら、キャッシュを無視。
- 143 ：tato ：2006/07/28(金) 12:47:17 ID:chE9END/0
- 静的ファイルへのリクエストと.cgiの負荷を比べると、普通は.cgiの負荷の方が高いと思いますが、
なにしろ、リクエスト数の多い2chなので、その判断は現場の人でないとわからないかも?
- 144 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 12:52:12 ID:3rgozFxf0
- >>140-141read.cgi の処理による負荷があるのはわかります．しかし，
静的コンテンツであっても HTTP リクエストを処理することによる負荷もあります．
HTTP リクエストが増えればそれによる負荷増もあるってことで，
そのあたりを read.cgi をリファインした場合と比較すればどうなのか，と．
- 145 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 13:02:09 ID:zKffljcV0
- どんなにリファインしても.cgiの負荷が静的ｺﾝﾃﾝﾂの負荷より下がるとは思えないけどなぁ
- 146 ：stream ◆PNstream2s ：2006/07/28(金) 13:06:22 ID:7fX0/+L20
- 一応補足しておくと、read.cgiはCGIと表記はなっていますが、実際はApacheモジュールに近いものです。
mod_cgidso http://sunos.saita.ma/mod_cgidso.html
read.htmlはJavaScriptを使う関係で、2chの背景画像みたいに
別サーバーにおくというわけにも行かないですしねえ
read.htmlを使うとして
(1)UTF-8に変換(responseText) >>111
(2)datファイルを単純なXMLに変換(responseXML) >>125
(3)キャッシュ無効は、If-Modified-Since: 昔の時刻 を設定するのが一番どのブラウザでも安全かと
- 147 ：tato ：2006/07/28(金) 13:15:09 ID:chE9END/0
- ああ、そうだ。
>>136の方が書いていますが、
たとえば、read.htmlのソースを
<script type="text/javascript" src="read.html.js" charset="xxx"></script>
などにして、全部JavaScriptで出力してしまえば、
read.html.js自体はキャッシュされますから、
/test/read.html/operate/1000000000/ と /test/read.html/operate/1000000001/
/test/read.html?bbs=operate&key=1000000000 と /test/read.html?bbs=operate&key=1000000001
こんなふうに何度呼ばれても、再読込は1行だけかも。
HTTP リクエスト回数そのものの負荷は減らなくてもかなり軽くはなります。
あ、read.cgiから
<script type="text/javascript" src="read.html.js" charset="xxx"></script>
を出力するとリクエスト回数は減って、datのロードをクライアント側のAjaxにも任せられる?ハイブリッドみたいな?
- 148 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 13:23:21 ID:3rgozFxf0
- >>145HTTP リクエスト数がほぼ同一という前提ならそれは当然です．
さすがに，単一のリクエストにおいて動的コンテンツ処理の負荷が
静的コンテンツ処理の負荷より軽いなんてことを言うつもりはないです．
ただ，JavaScript 版（に限らず Java や Flash などでもそうでしょうが）で
ページをロードした場合，外側の html と内側の dat 双方の HTTP リクエストが発生します．
つまり（静的コンテンツではあるものの）HTTP リクエストが増加することは必至です．
しかも，その静的コンテンツも sendfile() で一気に送るのではなく，
gzip 圧縮という結構重い処理を介してます．そうしたことも考慮すれば，
HTTP リクエスト増加による負荷増も無視できない水準になるだろう，
それを read.cgi をリファインした場合と比べればどうなのだろうか，と......
要は，個人的には JavaScript 版 read.cgi を作ること関しては，
負荷対策を第一義的目標として掲げて行うことには懐疑的，
（負荷も考慮しつつも）技術的好奇心を主眼として行うのなら好意的，ってことです．
- 149 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 13:33:36 ID:YlQHVubn0
- iframe 使った読み込みした場合のデータのキャッシュって普通のコンテンツと同じかな？
使えるとしたら、Expires で超未来指定することで HTTP リクエストを軽減できるかも。
- 150 ：tato ：2006/07/28(金) 13:52:45 ID:chE9END/0
- それにしても、metaでもブラウザ側でもShift_JISを指定した上で、
IE6で通常のShift_JISファイルをXHRで読み込んで、文字化けするということは無いと思うので
gzip 圧縮か、Content-Type設定に原因があるかも。でも、仮にこれが解決してもXML処理の方がお勧めではあります。
- 151 ：149 ：2006/07/28(金) 14:17:19 ID:YlQHVubn0
- いや iframe じゃなくてもいいか。考えたから暇な人は読んでみて。
<script type="text/javascript">
var data = new Array; // まずスレッド用の配列を作る
var pos = -1;
</script>
<script type="text/javascript" src="/test/read.js/operate/1000000000/1-"></script>
<script type="text/javascript" src="/test/draw.js"></script>
サーバ側は js ファイルを CGI で吐かせるようにする。
data[++pos] = "*********"; // " はエスケープ（書き込み時に " になってればそのままで）
data[++pos] = "*********";
data[++pos] = "*********";
で、吐くデータが n 個（1 個以上; 適当に）を超えたらデータ部の後ろに
次のセクションを読み込むスクリプトを書いた上で、
$js .= qq{data[++pos] = "$_";\n} for map { s/"/"/g; $_ } @data; "
$js .= q{document.write('<script type="text/javascript" src="/test/read.js/operate/1000000000/$next-">');}
if scalar @data >= $n;
このリクエストの Expires を超未来にする、て感じ。
難点はあぼーんが反映されないってことだけど。
- 152 ：149 ：2006/07/28(金) 14:22:20 ID:YlQHVubn0
- × q{document...
◯ qq{document...
- 153 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 14:46:12 ID:3rgozFxf0
- >>151-152そもそも，ブラウザでページ自体をリロードしたらどうなるか......
「そういう使い方はしないで内容更新時にはページ内の更新ボタンをクリックして下さい」
とか呼びかけようとしても，read.cgi 利用者層の多くを占めるライトユーザには
なかなか普及しなさそうな気も...... read.html に対して
ExpiresActive On
ExpiresDefault "access 1 week"
とか指定しても，ページ自体をリロードすれば HTTP リクエストは
発生するようです．いったん取り込んだ URL なら 304 にはなりますが．
で，今の DSO 版ではない昔の read.cgi には，HTML 整形せず dat の形式のままで
行単位の内容を返す raw mode ってのがありました（今は廃止）．でも，HTML 整形するよりは
raw 形式の方が軽いとはいえ，結局サーバ側プログラム走らせることには変わらないんですよね．
そこに HTTP リクエスト増も加わるってことも考えれば......
- 154 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 14:58:27 ID:636jpKTQP
- 作ってから考えればいいんじゃね
- 155 ：149 ：2006/07/28(金) 15:08:55 ID:dbg/okTO0
- >>153
ttp://labs.cybozu.co.jp/blog/kazuho/archives/2006/02/utilizing_cache.php
このページに書いてあることを信用すると、 Expires ヘッダは
Last-Modified ヘッダと併用することでリクエストそのものが無くなるみたいだよ。
- 156 ：stream ◆PNstream2s ：2006/07/28(金) 15:18:29 ID:7fX0/+L20
- WindowsのIE6では、更新ボタンを押した場合は再読み込みされるよ
- 157 ：149 ：2006/07/28(金) 15:22:51 ID:dbg/okTO0
- >>156
そうなのか……それじゃぁ >>151-152は使えないや。
- 158 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 15:37:48 ID:3rgozFxf0
- >>155内側で読み込むデータってことね．それなら，今も実際に index.js で利用してて
効果は出てるようです．でも，外側の read.html のリロードまでは抑制できないかと．
で，>>151は内部で読む方のリロードを抑制ってことか．でもそれだと今度は
dat が更新されてもなかなか反映されないってことになりそうな......
あと，そういう形で行単位の内容を返すなら
・ \n を探すためファイル内容をスキャン．
・ JavaScript 文字列にするなら，さらに " や \ をエスケープするためにスキャン．
こういうことやるぐらいなら，タグ付け加えて HTML 化ってのがそういう処理に比べて
べらぼうに重いとは思えません．もしべらぼうに重いとすれば，それはムダな処理をしてるからかと．
ある程度は重くなるでしょうけど，少なくとも HTTP リクエスト増加による負荷増より
ずっと重いなんてことはあり得ないような．
- 159 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 15:44:15 ID:JuOh4RhP0
- 有効期限も長くし過ぎると、テストが十分でなくて不具合を混入させてしまったまま
リリースした時に困りますよ。失礼な言い方になるけど、ユーザーの大半は基本的に
馬○ですからね。不具合がある事を訴えることは出来ても、何が原因で
どうすればいいか思いつくことまでは出来ないのが多い。
まぁここに来て騒いでCtrl+F5を押せって言われる流れになるんでしょうけど。
- 160 ：149 ：2006/07/28(金) 16:12:12 ID:dbg/okTO0
- >>158
キモは、ブラウザのキャッシュに入ってるデータはリクエストしないってとこだったりするのだけれど。
行単位がダメなら、やっぱり iframe なのかな？でもキャッシュが効くかどうかもわからない。
新着を探すためには、最後の位置を覚えとかないといけないし。これは、read.js の他に read.txt も必要かも。
そしてやっぱり、更新ボタンを押したらリロードしちゃうんでは、ちょっと微妙かな。
read.cgi のキャッシュの仕組みがよくわからないけど、多分、
最新 50 の後に全表示とか、キャッシュにデータが重複してても構わず処理するんでしょう。
サーバ側は知る術が無いしそれは普通なんだけど、そうならやっぱり。
- 161 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 16:16:12 ID:lDXvnfU00
- １レス１ファイルにするのが一番良い。
- 162 ：ひろゆき＠どうやら管理人 ★ ：2006/07/28(金) 16:21:33 ID:???0 BE:227366-BRZ(2585)
- jsはwww.2chとか静的コンテンツ用のサーバにおいて、
datはqb5.2chの既存のサーバとかコネクションを切り分けるとかって
出来るんでしょうか？
- 163 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 16:24:12 ID:JuOh4RhP0
- んー、Gecko(Firefox)はできない可能性が高いけど、2ch.net同士だからなぁ。
- 164 ：149 ：2006/07/28(金) 16:26:09 ID:dbg/okTO0
- js が別のサーバに置いてあったとしても、
js を読み込む（実行する） html が読みたい dat と同じドメインにあれば、dat は読み込めるよ。
- 165 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 16:26:33 ID:3rgozFxf0
- >>162JavaScript 部分を HTML から分離して別のところに置く，ってのは
今の read.cgi や index.html でもやってます（www2.2ch.net/snow/index.js）．
ただ，URL で鯖・板・スレを指定している限り，外側の read.html が
各所に散らばる状態はいかんともしがたいかと．
- 166 ：ひろゆき＠どうやら管理人 ★ ：2006/07/28(金) 16:31:45 ID:???0 BE:89227-BRZ(2585)
- 外側の read.htmlといいますと？
- 167 ： 株価【800】 ▲ ◆cZfSunOs.U ：2006/07/28(金) 16:48:20 ID:YGISL4lC0
- >>166例えば，
http://qb5.2ch.net/test/read.html/operate/1153819270/
という URL でスレを表示させる際の
http://qb5.2ch.net/test/read.html
のことです．
- 168 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 16:49:13 ID:HmmSpj2e0 BE:75716238-BRZ(1035)
- 代理
名前： !kab▲ ◆cZfSunOs.U
E-mail： sage
内容：
>>166例えば，
http://qb5.2ch.net/test/read.html/operate/1153819270/
という URL でスレを表示させる際の
http://qb5.2ch.net/test/read.html
のことです．
- 169 ：動け動けウゴウゴ２ちゃんねる ：2006/07/28(金) 16:50:12 ID:HmmSpj2e0 BE:132502076-BRZ(1035)
- でっ。ごめんなさい
- 170 ：ひろゆき＠どうやら管理人 ★ ：2006/07/28(金) 16:57:20 ID:???0 BE:353478-BRZ(4585)
- http://www.2ch.net/read.html&u=http://qb5.2ch.net/operate/dat/1153819270.dat
とかじゃまずいんでしょうか？
317KB
新着レスの表示
スレッドリストへ戻る 全部 前100 次100 最新50
0ch BBS 2004-10-30