【２ちゃんねるビューア】　巡回機能の巻。Part3

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

837 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:13 ID:???: >>836
2ちゃんねるの場合 political layer の所が難しいよな。
Big-Server はサーバの表面程度しかいじれない。
ひろゆきはやる気もスキルもない。
838 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:15 ID:???: >>835
subback.htmlにどういうアクセスをしてきたものを弾くんでしょう？
通常使用でも見ることがあると思いますが
839 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:15 ID:???: gikozilla騒動について知らない、歴史を軽視するような
香具師は、monazilla part2の、、、あ、offaw落ちか、、、
http://www.google.com/search?q=cache:EU7vRQnwjxQC:pc.2ch.net/test/read.cgi/tech/1005282763/+&hl=ja
140～を参照セヨ
840 ：Dream ★ ：02/03/27 00:19 ID:???: >>838
その辺は今話し手も仕方ないと思いますし、実装するとしたらなおさらいわないと思います。
私実装する人間ではありませんし、どんな権限もないです。
841 ：Dream ★ ：02/03/27 00:22 ID:???: ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→http://pc.2ch.net/test/read.cgi/software/1016905060/671
西安さん　→http://pc.2ch.net/test/read.cgi/software/1016905060/672
842 ：AJA6H/Ws ◆MPnX7dHA ：02/03/27 00:29 ID:???: 過去ログを縦読みしたけど、
昨日からなーんも進展がないような気がするんだけど・・・^^;
843 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:35 ID:???: >>842
現状の2ちゃんねるの問題が、それだけ深刻だと言う事
844 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:38 ID:???: >831
転送量や負荷を抑えるために
subback.htmlより小さいsubject.txtを読んだりread.cgiより負荷の小さいdat直読みしたりするツール
の使用が推奨されてるわけで、
subject.txtやdatを隠して誰が得するのか説明しろｺﾞﾙｧ(ﾟдﾟ)

ゲイツか？
845 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:39 ID:???: subject.txtを使った荒らしが減る。
846 ： ◆hAnYaNVA ：02/03/27 00:40 ID:???: TCPの3-Way-Handshakeは重い、という話をきいた
ことがあったので、あちしのツールではKeep-Aliveによる
Persistance-Connectionがなるべく途切れないように
しているわけだですけども、intervalがあるなら、当然
Connectionは毎回切れるわけで、そういうものなのか、と。

intervalを間に挟んだり、複数の鯖を交互に使用したりして
軽減される負荷というのは、Keep-AliveしてHandshakeを
削減するのよりも大きいのかな？という疑問はありますです。
847 ：Dream ★ ：02/03/27 00:41 ID:???: >>844
一定の枠を用意して、みたいないいカタすると官僚のようだけど、
ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
ツール作者さんには、subject.txtやdatを公開するって形だと、どうなんでしょね？

＃ずっと私は、それを提案してきているんですけど
＃誤解されていますか？
848 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:42 ID:???: 公式発表的には、subject.txtは隠されているのですが。
つか、あなた、ブラウザから取得できますか。
849 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:42 ID:???: >>847
それなら隠すといわずに取得に制限を加えると言った方がいいのでわ
850 ：Dream ★ ：02/03/27 00:44 ID:???: >>846
インターバルを挟む、という思想は、ツールによる断続的で集中的な
リクエストを防ぐ、という視点に大きく立脚しちゃっているものだと思います。
作者さんの視点で、どういう方法が、サーバの負荷と転送量という問題に対して
効果的である、という、啓蒙というか、教育というか(私みたいなのに対して)
をしていただけると、とてもうれしいです。
851 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:45 ID:???: >>846
>>725-726 ではとっとと切断、って言って終わってるけど、
もうちょっと考えるべき事だと思う。

「じゃあ Keep alive せずに Rapid fire しろっていうことか?」
と誤解する人が出るのが怖い。
852 ：Dream ★ ：02/03/27 00:46 ID:???: >>849
ああなるほど。

＃ここまでに、このスレッドでも前スレでもしつこくさんざん書いてたから了解済みだ
＃という思いこみでした。
＃すみませんでした
853 ：Dream ★ ：02/03/27 00:48 ID:???: >>851
是非お願いします。
SYN ACKの認証が正直きつい、というのがそもそも、dat直取りで巡回を
されたくない、という話の始点だったと思うんです。
私自身は、その程度の認識しかなく、
「だったらどうやるのが効果的なのか？」
については、是非お聞かせいただきたいと思っております。
854 ：Dream ★ ：02/03/27 00:52 ID:???: もちろん、dat直取りのもう一つの要因としては
転送量に影響する、というところもありますけど、これは、
要求されるのはHEAD情報だけで、datを直に取ってるわけではない、
というお話だと思いましたが・・・・
その場合でも、SYN←→ACKのハンドシェイク的に、サーバ負荷につながっていないのか？
とか、いろいろ、お聞きしたいことがありますです。

あと夜勤さんに、
http://www.yakin.cc/pv200201.html
には、HEAD要求は含まれていますか？というのを確認させていただきたいと思います。
PVという言い方の印象では、GETのみ、で、ページ単位のカウントのような気がします。
(イメージファイルとかそういう者を除いている、という意味で)
お願いします。
855 ：AJA6H/Ws ◆MPnX7dHA ：02/03/27 00:53 ID:???: >>843
なるほど
856 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:58 ID:???: 場合わけをきちんとしようや。
・更新があるばあい
　・Head(stat) [+ Get(read)]
　・ims-Get(stat&read)
・ない場合。
　・Head(stat)
　・ims-Get(stat)
で、どっちにしろ、更新があれば中身をみたくなるわけで、
むしろIf-Modified-SinceをつけたGetの方が軽いのでは？
というのがすくなくとも8ヶ月前の結論だったわけですが。
857 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:59 ID:???: >>854
あの～普通に巡回といわれるものはすべてIf-Modified-Since付きのGETですよ。
巡回時に自動でHEAD→GETとわざわざ無駄なことやってるものは即刻修正すべし、です。
858 ：Dream ★ ：02/03/27 01:01 ID:???: >>857
ああ、はい。
巡回じゃなくて、更新チェックですよね。はい・・・
859 ： ◆hAnYaNVA ：02/03/27 01:04 ID:???: ＞ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
＞ツール作者さんには、subject.txtやdatを公開するって形だと、
＞どうなんでしょね？

ところで、これは現在のsubject.txtの状態と具体的に
どのあたりが異なるのでしょうか？
860 ：Dream ★ ：02/03/27 01:07 ID:???: >>859
いまはhtaccessやcgi内部で判別してアクセス受け付けてるようですが、
たとえば、基本認証使ってリクエスト受ける、というイメージです。
イメージ的には。
861 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:08 ID:???: >>859
ぎこはにゃ～ん作者登場。
862 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:13 ID:???: >>860
ナニを認証するのさ？●？
863 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:15 ID:???: >>860
それが何の解決になるの？鯖負担が増えるだけでは？
荒らしツールはどれかのツールに簡単になりすましができるけど。
864 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:16 ID:???: >862
ツール（と作者）、じゃないかな。
セキュリティ的にはヨワヨワでないも同然だけど、
そこを不正アクセス禁止法で補助するような感じがする。
865 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:16 ID:???: >>863　荒らし対策の話をするスレなのか？
866 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:17 ID:???: >>865
違うはずなんだけど、まとめ役がそっちに話を持っていくんだもの。
867 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:19 ID:???: >>860
イメージとか、イメージ的では正直意味がとれないよ。
具体的な説明求む。
868 ：Dream ★ ：02/03/27 01:22 ID:???: >>867
すいません。イメージなイメージ的にエクスキューズな単語ですけど、
＞たとえば、基本認証使ってリクエスト受ける
これそのものずばりではないかと愚考します。
869 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:22 ID:???: >>866　責任転嫁すな。
870 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:24 ID:???: ん、だから普通にsubject.txtをGETしても
HTTP/1.1 401 Authorization Required
が帰ってきて、ちゃんとパス送らないと
受信できねって事だろ。
で、このパスを勝手に解析すると不正アクセス防止法に触れる可能性があると。
871 ：Dream ★ ：02/03/27 01:25 ID:???: >>865
荒らしが過負荷の要因になっていない、または、別の手段で対応が出来る、
ということであれば、そういう仕組みは一切要らないかと思います。
たとえば、特定の業者がdatクロールして利益を得ようとしているわけです。
たとえば、全くランダムなdatから書き込みを抽出して、それを、
subject.txtで特定のスレッド拾って、bbs.cgiにPOSTしたりしているわけです。
そういう行為を、負荷低減策として検討する必要がないのであれば、
datもsubjectも、現行のままでよろしいのではないかと思います。
872 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:27 ID:???: >>870
法律なんか気にするな！
873 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:29 ID:???: >>871
それが問題なんだからそっちを対処しようよ。

手に入れたデータまたはその統計を商業利用しようとしている
ところから金を取れるように何か利用規定を設ければいい。

具体的には抜き打ちでIP統計とって、異常に多いところの
IPがどっかの会社だったら「金払え」って言えばいいよ。

抜け道はあるかもしれないけど、それはそれで
バレた日にはその会社は２ちゃんねらに潰される
874 ：873 ：02/03/27 01:31 ID:???: 抜け道はあるかも → 抜け道はたくさんあるけど
だった。

少なくともちょっとは金取れるようになるよ。
そしてその金で回線増強なりなんなりできる、と。
875 ：Dream ★ ：02/03/27 01:32 ID:???: >>873
でもですね、やっぱしあれなんですよ。
荒らしが発生していない日でも、厳然としてサーバはぱんぱん
帯域かつかつ。なんだそうです。
876 ：867 ：02/03/27 01:32 ID:???: >>868
いや、基本認証使ってリクエスト受けると、基本認証する分だけ
負荷が増すと思うんで、その辺どう考えてるのか知りたいなと。
877 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:33 ID:???: 現状だとUAをモナジラと詐称するだけで、
荒らしツールだろうとなんだろうとsubject.txtは受信できちゃうわけで、
しかもそれは法にはふれない。犯罪じゃない。
（UAを偽る＝鯖を騙す＝詐欺罪って話もなきにしもあらずって感じらしいが）

そこを認証にすれば、不正アクセス防止法違反という立派な犯罪にできる。
だから荒らしツールを抑制できる。
悪質なら訴えれば逮捕される。
って事だな。

まぁ、俺ならそんな事されたらsubback.htmlで同じ事するけどね。
それもなくなったとしてindex.htmlから生成すればいいし、
それもだめだったら
http://pc.2ch.net/test/read.cgi/software/1016905060←ここのキーを
現在時刻からさかのぼって存在をチェックしてランダムに荒らすようにだってできる。
ブラウザで見れてカキコできる時点で、なんでもできるわな、そりゃ。

つか、むしろそういう規制された方が燃えるね。
なんとしても荒らしてやろう！ってな。
878 ：873 ：02/03/27 01:34 ID:???: >>875
この話は批判要望に書くべき内容だった。すまんこ。

荒らしが原因の日もあるだろうけど問題なのは
慢性的にクロールしてる企業がいるで重い
ってとこかと
879 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:35 ID:???: かちゅーしゃのアクセスが多い、ってのはそういう企業が作ったツールが
とりあえず有名なかちゅーしゃのUAを偽ってる、ってパターンが多かったりしてね
880 ： ◆hAnYaNVA ：02/03/27 01:36 ID:???: でもそれは、オープンソースの死だよね。
dat、subject.txtのgetにpassが必要で、
それをツールに埋め込んでしまう時点で。
881 ：Dream ★ ：02/03/27 01:38 ID:???: なにか起死回生の良いアイデアありませんでしょうか？
882 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:38 ID:???: >>880 >>768 で一度指摘されたが、返答なし
オープンソースの場合、隠しているとはどう考えても言えないから
法に頼るのも難しいと思われるが
883 ：877 ：02/03/27 01:38 ID:???: >>880
パス埋め込んでもかんけねーよ。
認証なんてなんの暗号化もされてないんだから、
ローカルでプロクシ立てて通信内容のぞき見れば、
すぐにパスなんて分かるっつーの。
仮にプロクシ立てられなくてもTCP/IP通信内容をのぞき見るツールだってあるんだし。
884 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:41 ID:???: というか自分がなにを発信しているか、受信しているかはすぐわかる。
885 ：Dream ★ ：02/03/27 01:42 ID:???: >>882-883
なんか代替案がありましょうか？
886 ： ◆hAnYaNVA ：02/03/27 01:43 ID:???: BASIC認証はたとえなので、Digest認証くらいは
使うものだと当然思っていましたが、、、
別にこれがSSLのClient Certificationでもそんなに
話は変わらないと思うのですが。
887 ：Dream ★ ：02/03/27 01:45 ID:???: 誰かの書いた内容について、批判したり、だめな面を指摘するのは
すごく簡単だと思うんですよね

でも、ここ重役会議やっているわけじゃないんですよ。
どうしようかね？って話してるつもりなんです。

私の提案に不具合や不足があったらとっとと引っ込めます。
良い案を考えていただけるととてもうれしいんです。
(否定すんなよ、ていうんじゃないですよ、もちろん(笑))
888 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:46 ID:???: だから平凡なパスを埋め込むというのは愚行。
送信内容の一部を暗号化して・・・ってのなら効果はあるけどね。
一部にPGPを使うとか。（遅そー）
889 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:46 ID:???: そもそも、大体subject.txtをいかに強いセキュリティをもって隠したところで、
subback.htmlだってなんだってあるんだから無駄って話でしょ。
890 ：Dream ★ ：02/03/27 01:47 ID:???: >>886
ええ、仕様を決めているんではなくて、要求分析というか
まだそこまでいっていないブレインストーミング的な話ではないかと思います。
そう宣言しているレスが、残っているはずです。
891 ：Dream ★ ：02/03/27 01:48 ID:???: >>889
なんでそこではなしがとまっちゃうかな？
ずっと同じ方ですか？
じゃ、どうすればいいの？
892 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:48 ID:???: 公開鍵が公開されてなければ（ツール内に隠蔽されてれば）いけるかも。
893 ：892 ：02/03/27 01:49 ID:???: しかしこの方法はソース丸見えなのには(j2ch-cashだっけ？)使えないな
894 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:49 ID:???: >>891
どうしようもないって事かと
895 ：Dream ★ ：02/03/27 01:51 ID:???: >>894
いや、あなたがそういう感想なのはわかりましたので、
だったらもうあなたの意見わかったのでもういいです。おつかれさまでした。
896 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:55 ID:???: どうせやられるんだからsubbackよりsubjectの方がまだましだ。
異様にアクセス多いIPだけ完全アクセス禁止にしろ。
897 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:56 ID:???: >>894
今回の問題については、100% 完全無欠のシステムを作るのは無理。
だけど、できることはあるはず。UserAgent 詐称だって、
それをやる人がどれだけ存在するかどうかの問題。

規制したことで、トータル的に負荷が減るならやる価値はある。
そのためにも統計とデータが必要。
これからの2ちゃんねるは、様々な実験が必要なんだよ。
898 ：Dream ★ ：02/03/27 01:57 ID:???: 【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/l50

ちょっと早いですけれど、次のスレを用意しておきました。
899 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:57 ID:???: >>896
そうだね。それが一番現実的かつ簡単。

そのIPアドレスがどっかのプロバイダでないにもかかわらず
アホみたいにアクセスが頻繁だったら禁止ってのはいいかも。
900 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:58 ID:???: >>875
荒らし対策しても意味無いってこと？
901 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:59 ID:???: ツール側と鯖側でsubject.txtを強度な暗号化して通信したとしても、
結局自分のPCから発信してるわけで、
串とかで通信内容のぞき見られたら、
荒らしツール、dat総ざらいツールでもそのまま使えちゃうんじゃないの？
まったく同じリクエストを送信するだけじゃないの？
902 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:01 ID:???: >901
は、SSLについてもっと勉強してください。
903 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:01 ID:???: >>900
先日のkaba鯖アタックのときは、対策が非常に効果的だったよ。
対策してないときは、ロードアベレージ 150 は軽く越えてたはず。
904 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:09 ID:???: >>898

>>1のテンプレが古い。
905 ：Dream ★ ：02/03/27 02:10 ID:???: >>901
でも、その行為は、これまでのグレーではなく、
レッドになるわけですよね？法的には。

「そういう使い方をされたくないために意図された」
ものを乗り越えるんですから。
906 ：Dream ★ ：02/03/27 02:11 ID:???: >>904
ああ！すいません。
907 ：Dream ★ ：02/03/27 02:13 ID:???: >>904
http://pc.2ch.net/test/read.cgi/software/1017161683/10

このあたりでお許し下さい。
908 ：Dream ★ ：02/03/27 02:15 ID:???: >>903
そうなんですか？
対策効いて沈静化したのか、攻撃終わって沈静化したのか
わかりませんでした。
909 ： ◆JOKESIZE ＠JOKESIZE ★ ：02/03/27 02:15 ID:???: どなたか批判要望板の容量を教えてください。
１０００行く前に１０２４ｋの制限でdat落ちする可能性がおおいので
長文レスが多いもので、、、って漏れか（ｗ
910 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:20 ID:???: >>909
このすれも300kも全然いってないから大丈夫
911 ：Dream ★ ：02/03/27 02:24 ID:???: >>910
こっちあげでいって、９５０くらいまで使いますですか？
わたし、いったんお休みいたします。
早めにスレ立てましてすんません。
912 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:31 ID:???: GickoBrowser修正改良版
Information

(2002/03/26)　暫定的にかちゅのUAを借りてsubject.txt取得するようにしました
913 ：西安 ◆CYANh33g ：02/03/27 02:33 ID:???: >>912
なんでかちゅ・・・・。
しかもそれって実質 kage の UA よね・・・。
914 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:47 ID:???: ◆hAnYaNVA さんじゃないけど、インターバルの件でどうしても納得いかない。

「インターバルを設ける理由」から
「巡回を不便にして巡回自体(回数/スレ数)を減らす」目的を除き
純粋に「複数のリクエストを送る必要がある」場合。

Keep-Aliveしたまま接続断を待つ/サーバーを待たせるのは論外とし、
同じサーバーに対してのconnectionは
一つに限定する(タブブラウザなどは複数？)場合、

本当に、
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
が、
　connect-
　　request-response-request-response-request-response
　-close
よりサーバーに優しいか、結論は出ているのかな？

詳しい条件等は全然知らないので、2chには当てはまらないかもしれないけど
Apache自体はKeep-Aliveの実装によって50%近く負荷が下がったらしい。
game鯖等が軽くなったのは、インターバルを設けた効果ではなく、
単にread.cgiのrawモードを不可にした効果に思えるのだけれど。
915 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:47 ID:???: リクエストの集中が問題というかもしれないが、
仮にKeep-Aliveにしも、サーバーが処理するリクエストは、
各接続に対して同時に１つだけなのだから
接続要求の度にacceptすることを考えれば
Keep-Aliveしたままの方がトータルの負荷は少ないと思う。
そもそも、同時接続数が256では足りないような状態のサーバーに対して
単独のクライアントからのリクエストが連続しない程度で
負荷分散になるとはとても思えない。

それでも、Keep-Aliveにしたら次のリクエストを待つ間の
idleなconnectionが負荷を高める原因だと言うのならば、
リクエストをパイプラインして送ればいい。
　connect-
　　request+request+request - response+response+response
　-close
これならidleなconnectionも発生しないし、無駄なconnect/closeもない。
HEAD等の軽いリクエストを数十件まとめて送り
レスポンスにかかる時間を比較しすれば
サーバーが短時間で処理を完了して解放されるのがわかる。

どこか間違ってる？あるいは何か見落としてる？
916 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:18 ID:???: 話が追いきれてないけど、書いとく。
# 今は話がループしてるっぽいし。

●で認証を行うか、ツールで認証を行うかと聞かれれば、
私は●を進めますが。何故かというと
1.ツール認証はhttp内で行うには抜け道が多いから
2.●で認証は無料ユーザにも発行することができ、
　ココの負荷を把握することができるから。
の二点が理由なんですが。

●の発行で無料用の話って出てないよね？
917 ：Dream ★ ：02/03/27 03:28 ID:???: 【２ちゃんねるビューア】　巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50
でいま、２ちゃんの負荷低減とかを話してます。

ところで、２ちゃんねるはいま、htaccessを使ってRewriteCondをつかい、
各ツールなどにdatなどを供給している訳なのですが、
「httpd.conf」に一本化し、htaccessを一切使わないようにすれば、サーバの負荷低減がはかれる、
というお話をなさった方が居られました。
お聞きしたいのは、この方法をに変えると、どのくらい負荷が低減するのか？
といった、見積もり的な試算は可能なのか？ということと、
具体的に、これを裏付けるベンチマーク結果などは、存在するのか？
という２点です。
もし、おわかりの方、この問題に詳しい方が居られましたら、上記スレッドで
お話をいただければと思います。
よろしくお願いします。

マルチポストしてきました。うざくてすんません。
918 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:40 ID:???: スレが立てられない。
だれか2ちゃん専用ブラウザ「かちゅ～しゃ」Part588を立ててくれ。
http://pc.2ch.net/test/read.cgi/win/1017034701/904
919 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:47 ID:???: >>917
>>314
できもしないこと話してどうするんですか?
920 ：Dream ★ ：02/03/27 03:52 ID:???: >>919
はい。
劇的に効果があるんだったら、再度提案してみたいし、もし、
劇的に効果があるなんて言えない内容だったら、もう忘却してしまったらいいかと思っただけです。
921 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:54 ID:???: >>917を夜勤に無理強いする。

負荷軽減を要望するが、変化を望まない夜勤がボトルネック。
922 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:57 ID:???: >>920
今すぐ忘却してしまっていいと思います。
923 ：918 ：02/03/27 03:59 ID:???: Dream ★さんスレ立てありがとうございます。
でもソフトウェア板…
924 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:59 ID:???: やっちゃったようですなぁ・・・
925 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:00 ID:???: シロートの思いつきですが、datにgzipでアクセスする代わりに、
あらかじめbbs.cgiが圧縮データを生成して、それを普通にgetしたら
サーバ負荷と転送量の二律背反は緩和されません？
アクセス頻度は書き込み<<読み込みなハズだし、
bbs.cgiも一カキコだけ圧縮してアペンドすれば負荷は小さそうだし。
926 ：Dream ★ ：02/03/27 04:01 ID:???: httpd.confって、それ自体にスクリプト噛ませて、動的に認識させることが出来ましたよね？
特に、Perlディレクティヴかなんかを使えたと思うし、とにかく、夜勤さんに
負担や負荷かけない方法がとりえるんであれば、お願いしてみてもいいかと思いました。
夜勤さんが「出来ない」といっている事情と、こちらがデータそろえて、方法も添えて、
これでいかがでしょう？っていう提案をして、それを天秤に掛けて判断していただくしかないでしょう。

「その方法だと負荷が軽くなる」

という一言だけで、人を動かそうなんてしちゃだめです。
やっぱり、根拠と方法、目論見見積もりがなければ、人の心なんて動きません。
927 ：Dream ★ ：02/03/27 04:02 ID:???: >>923
あーおれってばかだ。ごめんなさい。いますぐいきます。
928 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:02 ID:???: >>925
gzip圧縮したものに何か追加するには
全部解凍→追加→再圧縮しなくてはならないのです。
929 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:08 ID:???: >>928
両方生成するとか．．．
930 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:09 ID:???: >927
つーか本来はソフトウェア板にあって然るべきスレッドだったり。。。
931 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:10 ID:???: >928
ええ。ですから一レスごとにgzipしたものをアペンドできないかなと。
クライアントも１レスずつ解凍する実装が必要だし、圧縮率はgzip本来の
レベルからは程遠い悲しい物になるかもしれませんけどね。

そうでなく書き込みごとにdatから丸ごと生成するとしても、bbs.cgiが実際に動作する
回数がread.cgiやdatがアクセスされる回数よりも少ないならメリットがあると思います。
932 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:12 ID:???: ついにソフト板にもかちゅユーザー進出か。
WIN板とまたがって幾つスレ立てれば気が済むんだ。
933 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:14 ID:???: >929
あ、補足どうもです。
サーバ自体の(html生成の)動作のためにも
今まで通りのdatの生成はしたほうがいいと思います。
934 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:15 ID:???: >>931
read.cgiが表示するために必ず解凍しなくてはならないとなると
負荷の面で相当厳しいと思われます。
935 ：名無しさん＠お腹いっぱい。 ：02/03/27 04:16 ID:???: 夜勤氏にはあきらめて頑張ってもらう。

これが今夜の結論だな。
936 ：名無しさん＠お腹いっぱい。 ：02/03/27 07:46 ID:???: >>926
夜勤たんが「できない」って言ってるのは、割に合わないからだろ。
結局金だよ。この問題は。

283KB

新着レスの表示

スレッドリストへ戻る全部前100 次100 最新50

0ch BBS 2004-10-30