レス数が1000を超えています。残念ながら全部は表示しません。

[深刻] ２ｃｈ負荷問題ふたたび勃発

1 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:05

８・２６問題が再浮上かも。
http://teri.2ch.net/test/read.cgi/accuse/1011385033/
「いよいよ　何らかの手を打たなきゃどうにもならん状態になってきたようです」

関連ネタ
http://pc.2ch.net/test/read.cgi/tech/1002820903/360

2 ：2 ：02/01/19 21:07

2

3 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:07

先日の「第２次稲垣祭り」が相当こたえたっていう噂も。
またかよ…

4 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:09

sleep入れてスループット落とせば?

5 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:12

>4
リトライが増えて逆効果になるかも。

6 ：4 ：02/01/19 21:17

どうかな。遅くなるだけなら、普通の人は「待つ」んじゃないかな。
結果的に、単位時間あたりのリロード回数が減ることが期待できます。

さらに、直近n回にアクセスされたIPアドレスを覚えておいて、
アクセス数に比例してスループットを下げていけば、
「礼儀正しい」ユーザへの影響は少ない。
(proxyの問題はつきまとうけど)
でもこれはサーバプロセスがないと難しいね。

7 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:18

鯖自体はあまりいじれないってことじゃなかったっけ？

モー板つぶせよ

8 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:18

>>4
スループット目標下げりゃいーんだけど、
それやるとサーバレンタル屋がタダで貸してくれんのだとさ。

もともと目標設定すらなくて、
「速い！」てのを売りにしたいんだとそこのレンタル屋は、
要はIT世間でよくモメるパターンの話題の一つだってことだあな。

こういうのは、どっちかが折れて決着になるのが世の常。。。

9 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:21

dat直読み制限では、根本的な解決にならん気がするけど、
これ如何に？＞夜勤氏

10 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:22

>>5
ラーメン屋の出前の数には限りがある。
注文が増えても、ある一定のところで件数は横バイになるよ。

>>6
表示要求がきたらブラウザにn秒待ってからホントのデータを渡すように
metaタグとCGIの仕組みを組むとかすればある程度できるかも・・・ね

11 ：4 ：02/01/19 21:24

>8
スループットは下げられない、と。

じゃ、データ量を減らすしかないね。
「最新50」からリロードすると
「新着レスの表示」相当になるようにするのはどう?

12 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:26

read.cgi経由でデータ読む輩が増えると思われ。
これでは逆効果。＜dat直読み制限

13 ：4 ：02/01/19 21:31

>11
> 「最新50」からリロードすると
> 「新着レスの表示」相当になるようにするのはどう?

そんな都合のいい仕掛けは無理じゃん! と自分ツッコミ。

14 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:32

いつもどおりの泥縄政策だな。

ってゆーかunix板にスレ立てんなYO!

15 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:35

真の英雄Linux板でやってもらうか（ｗ

16 ：4 ：02/01/19 21:37

ていうか、有効で素人さんにもわかりやすい対処法がないまま
危機に突入しても、盛り上げようがないよね。

17 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:45

>>16
盛り上がる前に問題を消去ないし縮小する方がいいでしょ・・・

18 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:45

datをダイレクトに読んだ場合の負荷を綿密に計算しているのだろうか？
それも、転送量との兼ね合いを考慮した状態でね。
転送量の増加が必ずしも負荷の増加につながるわけではないけどね。

19 ：名無しさん＠お腹いっぱい。 ：02/01/19 21:57

「オイスター作戦その一」の真の目的とは？？

658 名前：夜勤 ★ 投稿日：02/01/19 21:39 ID:???
>>653
まったくそのスレッドよんでいないけど、
目的が違っていると思うから　逆効果も何もないと思いますが、

20 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:06

全く読んでいないのに目的が違うと思っちゃう夜勤ﾏﾝｾｰ

21 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:10

>>19
なんで元レスの URL 書かないの?

22 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:13

>>18
負荷って言っても何の負荷かによるけれども
（てか、wでみたときの負荷？iostatで見たときの負荷？netstatで見たときの負荷？一体なあに？）
レスポンスは落ちるだろう。
でもreadまちのコンテキストがいっぱい並ぶのでスループットの下がり具合は
どうだろうか。

要はレスポンスの落ちこみ方によるんだな。
バッファキャッシュの当りかたがよくなって案外落ちなかったりしてね・・・

23 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:14

>>20
今回の改造の目的は転送量の削減でも負荷の軽減でもないからじゃない?

24 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:15

牡蠣→課金らしい。

25 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:32

無知でなんだが、dat直読みの場合ってgzip圧縮かかるの？
かからないならread.cgi使う事で転送量は多少減るんじゃない?
かかるなら...意味ねーな。

26 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:38

>25 こんどはCPU負荷で落ちるから。

27 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:55

>>24
カーカキンキン、カーキンキン？
某ｃｈじゃあるまいし。

28 ：名無しさん＠お腹いっぱい。 ：02/01/19 23:58

寄付金集めればいいじゃん。
結構集まるでしょ。

29 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:03

レベルの高いLinux板に解決してもらおうよ。

30 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:03

１クライアントＩＰごとにトラフィック量を細かく制御する
ことができればいいんじゃないかなぁと思いますけどね。
こういうの、サーバレベルで可能なのかなぁ。

31 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:04

>>28
それは 1ch というんでは。

32 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 00:08

要するに今回の目的は、DAT直読みで課金ってことですか？

33 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:17

あぼーん禁止にすれば差分読むの簡単になって転送量が減るのでは？

34 ：名無しさん ：02/01/20 00:23

>>32
> 要するに今回の目的は、DAT直読みで課金ってことですか？
そういう方向みたいですね。

ID:pikopikopo---n@tora3.net
PASSWORD:detaramenahito

35 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:26

負荷問題への提案

1. CGIの改善 (read.cgi改良スレ読んでないんですぅ、が)
　そろそろ C使いに、効率的なCGIを作ってもらう時期.

2. サーバ構成の改善
　クラスタリング ＋ Layer4スイッチ ＋ キャッシュ・サーバ
　みたいな構成にして、板毎のサーバ分割から、動的負荷分散へ
　移行してみてはいかが？
　＃ちょっと萌えるテーマだ.

3.ビジネス・モデル
　i-mode 1000円っつうのはシャレにもビジネスにもならん気がする.
　とりあえず、金取れる所から、小額(200〜300円/月)でもとる方が、
　現実的だと思う.
　あと、「コミュニティ」以外の体裁を整えて、付加サービスとして
　２チャンネルがついてくる、という形も、検討すべきだと思う。

36 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:37

とりあえず、広告でもクリックしてみよう。

37 ：名無しさん＠お腹いっぱい。 ：02/01/20 00:49

>>36 十回程クリックしてみましたが何か？

38 ：35 ：02/01/20 01:04

って既にC言語なんだ.

http://www.gedoh.org/aki/2ch/current/bbs/

現状把握に時間がかかりそう>>俺方面

39 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:05

>>35
> 　そろそろ C使いに、効率的なCGIを作ってもらう時期.
今も C だよ。
もっと効率的にしろ、ってこと?

40 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:06

http://www.yakin.cc/
88.9 Mb/sか。たしかにヤバイ状態かもしれない。

41 ：35 ：02/01/20 01:15

ﾁｮﾄすまん。

read.cgi改良スレッド３
http://pc.2ch.net/test/read.cgi/tech/1002820903/

と話が錯綜して、よく把握できないっす。

42 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:25

有料化したら無料の所のドミノ倒しが再現するだけでは？

dat読み制限ってことは、
2ch依存症のヘビーヲタのリロードがかなりの割合を
占めてるんだろうね。
という漏れもxyzzy+2ch-mode中毒者（汗

43 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:38

>>40
非営利なサイトで88.9Mb/sは尋常ではないわな。
下手なサーチエンジン系サイトより多いかも。
クラスタリングや負荷分散が必要なレベルに
なってきてるっていることは間違いない。

44 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:40

いや、アレだろ。read.cが単独でlistenして、1プロセス毎に
30クライアントくらいずつまとめて面倒みるのが‥‥

45 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:40

dat読み課金だってyo!

46 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:42

1ch有料化と時期同じく2chも有料化。
あぶれた難民は在野に下るなんてシナリオどう？

ちたぁ粛清されんじゃねえか？

47 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:46

＞dat読み課金だってyo!
ブラウザで見れば関係ありませんね : )

48 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:49

>>43 キャッシュ・サーバも有効そうです。>>再読み込み方面

まっとうな専用キャッシュ・サーバは、
結構古めのHWに専用OS使っていて、スループットが高そう。
だけど、むちゃくちゃ高価。

っつうわけで、安くて高性能なキャッシュサーバを立てる
方法はないのでしょうか？

49 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:49

どれだけ負荷分散しようが、
同じサーバー群からデータが出ていくわけだから意味ないのでは？
それより、2ch専用のcacheサーバプログラムをつくって配布するべきだろう。

50 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:53

あと、祭り発生時、読み書きが激流のように発生している時、
サーバ←→キャッシュ・サーバ間のトラフィックを押さえる
方法はないのでしょうか？
HTTPの範囲指定GETを使うとか、専用プロトコルを使うとか..

51 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:56

>>49
ユーザ側に配布するのですか？
あるいは、ミラー・サイトやアクセス・ポイントみたいな話ですか？

52 ：名無しさん＠お腹いっぱい。 ：02/01/20 01:58

カキコできるスレ →無料 誰でも読める
DAT落ちのスレ →有料、monazilla系のツールでしか読めない。IDとパスが必要
html化した過去ログ →無料 誰でも読める

53 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:00

！！！＞http://teri.2ch.net/test/read.cgi/accuse/1011457309/

54 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:09

>>40
1/14〜15のレコードは明らかに稲垣祭りだね。
冬厨時期と少しずれていたのが幸いだったかもしれない。
これが１週間早かったらと思うとゾッとする。

55 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:09

>>50
read.cgi側で、response headerに付けるキャッシュ有効期限を長くしたらいいんじゃないの。

>>52
「dat落ちのスレ」の何が問題なんだろう???
(「dat直読み」自体が問題なのかな。広告が出ないので)

56 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:12

>>55
> 「dat落ちのスレ」の何が問題なんだろう???
この課金法だとブラウザの人にとってはいままでどおりってことじゃない？

57 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:15

88.9MB/Secの転送量・・・
サーバ→クライアントの下りだけ考えてみると、

・http://pc.2ch.net/unix/のリロード(HTML部のみ) 76KB
　→約1198回/Secの転送

・このスレの最新50リロード(HTML部のみ) 14KB
　→約6503回/Secの転送

BIGIPだのキャッシュ鯖だの要るな確かに。

58 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:17

どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
f4

59 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:19

>>56
そりゃそうなんだけど、
「専用ブラウザの人の『dat落ちスレ』負荷」なんて問題になる?

60 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:21

＞どっかのベンチャーからキャッシュサーバと回線を無償で貸してくれないかな。
＞あの2chの負荷に耐えたとなれば宣伝効果はあるだろう。
それってまさしく、８月破綻まえのモデルでは‥‥

61 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:21

>>55 キャッシュ有効期限を長くする
最新情報が見えなくなる→リロード→負荷増大

62 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:22

>>19

63 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:23

>>19がどうした?

64 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:25

UNIX板の面目を果たすために、
安価かつ高性能なキャッシュ・サーバの
構築方法を提案できたらいーな。

レンタル鯖 or WebProg板方面逝った方が、情報収集しやすいのかな？

65 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:27

トリップ持ってる2ch.netの人間が、要件を整理して提示しないと何ともならんな。
どこかにあるのかね。

66 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:27

＞64
行くなら通信技術板じゃないの？

でも正直今の2chはロードバランサやキャッシュサーバで
なんとかなるレベルを超えてる気がする…。
Big-serverも変なプライド捨てて素直に制限かけるべきと思う。

67 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:30

いずれにせよ対策方法自体を2ch.netの外にもっていかんと
前の破綻前と同じ路線の対策しか打てない
↓
今すでにキャッシュの有効期限決め＋データ圧縮をやってるものが
こうして動いている
↓
httpdとOSに手入れず、
gzip以上に転送データを小さくする方法があればいいけど。
↓
ロードバランサーでは2ch.netの出入りパケットが減るわけがない
（特定の板の処理負荷を減らすことができるだけ）
↓
キャッシュサーバを置いてもクライアントへ出ていくデータが減るわけではない
（httpdの処理負荷減らすだけになる）
↓
あぼーん

68 ：sage ：02/01/20 02:37

>>57,>>66
祭り発生状態の板/スレだけ、
ピンポイントで制限 or キャッシュ＋負荷分散できたら、
他の板の住人はちったーしやわせになれるんでわ？

69 ：sage ：02/01/20 02:38

>>67 回線占有幅が問題なのですか？

70 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:41

主に汎用ブラウザ(IE,NN)方面について、
HTTP圧縮はサポートしていないのでしょうか？

71 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:44

＞70
その話は5ヶ月前に既出。
すでにread.cgiが実装してる

72 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 02:47

パケットシェーパー入れるのが手っ取り早いんじゃない。

73 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:49

ひろゆき曰く、祭り自体は大した問題ではない。
その後に新参者が定着し転送量が高値安定するのが問題。

gzip化で時間稼ぎの間にP2P実用化、のシナリオ通りには
やっぱ行かなかったね。半年しか持たんとは。

74 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:50

とりあえず、ここいらみて8月危機を復習しとけ。
http://hpcgi1.nifty.com/BWP/diary.cgi?action=view&date=20010830

75 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:52

しかし逆に考えれば
これだけの巨大な情報システムが
草の根ネット的に無料で運営されてきた
というのもすごいような

76 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:53

結局今回問題なのは転送量かサーバ負荷かどっち？
サーバ負荷ならあの人の言うとおり mod_perl 入れれば少しは
マシになるのでは。

77 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:56

つーかさ，寒波募集したら？

78 ：49 ：02/01/20 02:57

>>51
後者です。
だれか作ってみない？

79 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:57

「転送量」は単なる指標に使っているだけなのか、
それとも「通信回線の帯域圧迫」>>「サーバのCPU、I/O負荷増大」と理解していいのか?

80 ：名無しさん＠お腹いっぱい。 ：02/01/20 02:59

UNIX板で2chの問題を解決しようというのは反対。
また変な感謝age荒らしが来たらたまらん。

81 ：山師 ：02/01/20 03:01

CPU足すわけにもいかんし
エンタープライズ系が使えるわけでもないし
サーバー増やすのは限界だし
modぶち込むには、HE社の技術を説得せんといかんらしいし（できるかもしれないけど、交渉が必要　すぐにはできないらしい）

82 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:01

>80
おまえ一人の殻に閉じこもってろよ。
他人とコミュニケーション取ろうとするな。

83 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:06

>>80
今回はまだ何もしてないのに感謝age荒らしの心配なんかするな。

84 ：呼んだ？ ：02/01/20 03:10

感謝age

85 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:11

こういう２ｃｈの状態はインターネット業界みんな起こりうる状態で
あって、注目に値すると思うぞ。

ただ単純にサーバ増やしたり、回線を増やすことを考えるのではなくて
少ない資源でどう対処するかを考える事も技術の進歩になるのだから。

86 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:15

ITバブルの頃って、
取らぬ狸の皮算用で過剰投資が問題になったが、
現実にビジネス・モデル＆負荷問題が起きている例で、
どうやって問題解決していくか、
漏れもケース・スタディーとしてすごく興味がある。

87 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:16

あのflashでいってた、「いつか限界がくる」の
その限界が来そう、って事だろ。
鯖の力を増やせば、その分帯域も喰うから、
いっぱいいっぱいの状態にしてある、って話も
きいたぞ。

88 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:18

つか、２ちゃん救うことに意義が見つけられない・・・

89 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:21

>>86
けど実際問題コードチューニングするのも限界があるし、
まして今安定稼動してるシステムに手を入れる暴挙なんて極力避けたいしなぁ。
負荷問題の解決方法は結局のところマシンのリプレースしかないと俺は思うんだけど。

90 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:24

SE or コンサル感覚でいくと、
結局ビジネス・モデルの確立が、
問題の根っこにあるとは思う。

３リオで、ギコネコ・キャラクター商品売って見るとか...

91 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:26

>>80,88
なんか自慢げな書き方だなあ。お前が2ch救えるわけでもないだろうに。
技術的に興味のある話題ってだけでいいだろ。

92 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:27

>88
>つか、２ちゃん救うことに意義が見つけられない・・・
そう考えずに、こういうケースが目の前で動いてるって
考えればいいんでは？

こういう状況ってなかなか作れるものではないと思うのだが。

93 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:31

まずは性能モデルでもつくってのんびり眺めてみては？
構成が見えんのがツライところだが。

94 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:36

>89
確かに。
でもまだやれることは本当に無いのだろうか。
インタラプタ言語をやめるとか、プログラムで無意味なループの
処理を最適化するとか、不必要なデータファイルを消去または、
DATテープに移すとか．．ｅｔｃ．

95 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:38

だいたい、半年前と状況は変わってなくて、
対策打ってその効果が目減りしただけ。

そろそろ技術うんぬんの話でもなくなってきた模様と思うが・・・

96 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:39

>44のとかどうよ。forkが1/40になったら、だいぶん効くと
おもわないか？

97 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:39

>>74 感謝!!

あと、こっちも参考になりました。
ttp://home.att.ne.jp/wind/monsta/ga/2ch_kiki.htm

98 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:41

>>95
やっぱりそうなんだろうか･･･。
俺もずっと考えてたんだけど、俺の頭じゃ･･･。

2chうんぬんはまあ、いろいろあるけど、
純粋に技術的におもしろいと思ってみてたんだけど。

99 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:41

>>94
それやっても通信データ量は削減されない それも半年前と同じ。
CPU使用量とDASD使用量をさげても問題は解決されないのです。
データそのものの大きさを減らす→利用者数が増加している局面では
　　　　　　　　　　　　　　　　効力に限りあり
データそのものの入出力回数を減らす→キャッシュされにくいデータを
　　　　　　　　　　　　　　　　　　扱う場合、あまり減らせないことが多い

100 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:42

>>96
効いてしまってますますデータ転送量が多くならないか？

101 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:44

read.cgiをmodにする。ってのはやっちゃいけないのか。。
apache捨ててhttpdを自前で作るってのは？

102 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:44

とりあえずLinuxやめてSolarisにでもしてみい。
元々Linuxは限界付近の挙動が怪しげな上に、kernel 2.2.20じゃSMP
マシン使ってる意味が無い(全部では無かったかもしれんが)。
2.4系はもっと怪しげだし。

103 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:45

過去ログへのアクセスは
googleのキャッシュ/web.archive.orgに転送。

104 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:46

そうなるとこのケースはサーバと回線を増やす以外方法がないのでしょうか？

105 ：102 ：02/01/20 03:46

あ、転送量の方も問題なのか。しつれい。

106 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:46

CGIでの要求応答で、2〜4回に1回、1秒ほどsleepするのはどーだろう。
毎回sleepされたらレスポンス問題になるが、
2〜4回に一回、ちょっと遅くなる程度であれば
案外人間気にしないんじゃないか？

107 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:47

で、プロセスが爆発して、メモリは足りなくなり、apacheはあっというまに
MAX_CONNECTIONまでいって、接続を待たされる、と。

108 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:49

>>106
レスポンス落とす系の案は前回の時にも出たが、夜勤に却下されてる。

109 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:50

半年前に削減したときよりも転送量が多くなってるということは・・・

半年前のサーバには、少なくともCPU高負荷が問題ではなかったはず。
（問題だったらそこが処理上のボトルネックなのだから、
　転送量が増加してまた問題にならないよね？）

110 ：山師 ：02/01/20 03:50

>>101
TUXとかかい？
http://ns1.php.gr.jp/pipermail/php-users/2001-September/002301.html
動的なページに効くかどうか知らんが･･･。

111 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:50

Linuxなら、RedHatのTUXとかいいんでないかい？（既出？）

112 ：山師 ：02/01/20 03:51

げ、かぶった

113 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:52

>106
アクセスピーク時には結構響きそうだな．．
＃CONNECTできない言いそう。

114 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:56

>>107
vmstatのreが増加してプロセスが増える分にはいんでない？
それにhttpd自体そんなにでかくないし、
あれってa.outのプロセスじゃないんでしょ？メモリは大丈夫。

が、httpdのプロセス数上限にひっかかるので、そこはそのとおり。

そういえば半年前はクライアント側の接続待ちもダメつってたね、
夜勤さん。。。

1. 転送データ量を減らす
2. その対処の結果、
　　ブラウザ側でがタイムアウトになったり、
　　レスポンスが顕著に遅くなったりしてはならない
3. 利用者数は月日とともに一様増加するので、
　　スループットも同様に一様増加する。

　　

115 ：名無しさん＠お腹いっぱい。 ：02/01/20 03:58

>>110
PHPってすげー便利そうですが、本当にベンチマークいいんだろうか？
www.SourceForge.org とか、自前のUltra-10 にSourceForge 入れた
感想として、「レスポンス悪い」って印象持ったんですが。

TUX+PHPとか使うと違うのかなぁー。

116 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:04

DiskAccessをいかに減らすかって重要ですね。
Memoryをいっぱい積んでmfsって可能かなあ。

117 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:08

ピークになったら、106で書いてるsleepの代わりに、
「ごめんよ〜いま大変込んでるの・・・」
ってhtml返答してあげるつーのもだめ？
その返答が妙に短い時間で処理できてしまうと
その返答が数多く発生してナニかと思うのでnanosleepでms単位に調整とるとか。

したらブラウザで「接続できないぞ」「タイムアウトがでるぞ」ってのはないし、
サーバレンタル屋の気持ちになって考えてみても、
http的には問題なく伝送できているからウチのマシンのせいじゃないもんね
ってことでタテマエ上問題にはならんはず。

118 ：山師 ：02/01/20 04:13

>>115
PHPそこそこ早いよ。特にPHP4になってから劇的に早くなった印象がある
TUXもちょっと試したところじゃ確かに早い
でもTUX+PHPってどうかな？　安定性も未知数だし

その前に鯖屋（HE）が嫌がると思うけど

119 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:17

＞117
そんなものが宣伝になるか。

120 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:20

>117
>ピークになったら、106で書いてるsleepの代わりに、
>「ごめんよ〜いま大変込んでるの・・・」
>ってhtml返答してあげるつーのもだめ？
これを実現するにはやはり負荷分散装置が必要かなあ。

これは要するにサーバの状態を監視してて、いっぱいいっぱいならば、
違うサーバが「大変混んでるの」ページで応答することだけど．．う〜ん。

＃２ｃｈねら〜がそれで納得するかは疑問。

121 ：山師 ：02/01/20 04:22

>>106,>>120
リロードが多発して大して変わらないと思われ

122 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:26

リロード対処には、やはりキャッシュサーバしかないのでしょうかね？

123 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:32

>>72 パケット・シェイパー (帯域制限する機械)
と sleep 入れる方式と、どうちがうだろーか？

124 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:33

>>122 書き込みが頻発せず、
かつアクセスが一部のスレへ集中していれば、
効果あると思います。>>キャッシュサーバ

125 ：名無しさん＠お腹いっぱい。 ：02/01/20 04:44

・・・

126 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 04:55

>>123
全然違う。sleep入れたってhttpが走ってる間は全速力でパケット流れるでしょ。
帯域制限なら、50Mbpsまでと決めれば、RWINサイズとか動的に変化させて
ほぼそれに落ち着くと思われ。

大体、sleep 1秒入れて何がどれだけ減るのさ？
httpdのプロセスは複数起動してると思うし。

127 ：名無しさん＠お腹いっぱい。 ：02/01/20 05:05

ぁそゆこと？

転送量増減に合わせて、動的にsleepの確率＆時間とか調整するのかと思った...

sleepの確率＆時間が固定では、ほとんど効果ないんではないかいな？

128 ：名無しさん＠お腹いっぱい。 ：02/01/20 05:23

そんぢゃー、パケット・シェイパー ﾏﾝｾｰ

129 ：名無しさん＠お腹いっぱい。 ：02/01/20 06:21

結局2chに貸してるとこだって自前の鯖じゃないんだから
小手先の対策しかできないんじゃないかなと。

130 ：名無しさん＠お腹いっぱい。 ：02/01/20 08:22

提案

１．PerlでCGIではなく、mod_perlにする。（CPUネックの場合）

PHPにするという手もあるが、急ぐ場合はmod_perlでいいのでは？

２．datファイルを見直す。

datファイルって読むときflockかかるんでしょ？このLockの粒度を小さくするためにRDBMSやDBMをいれて、１メッセージ単位でLockをかけるようにする。

131 ：御伝言 ：02/01/20 08:52

>>81 参照

ついでに、
>>67, >>73, >51, >>78 のあたりもおねげーします。

132 ：名無しさん＠お腹いっぱい。 ：02/01/20 08:57

ぅあ、2. は
どっか(fj?)でdbm+Perl掲示板を嘲笑する記事読んだ覚えあり。

つか、dbmベースじゃ、お祭り状態の2チャンネルは実現できないっしょ？
＃濁流のように書き込まれて、あっという間に1000スレになる(藁

133 ：名無しさん＠お腹いっぱい。 ：02/01/20 09:12

>>126

ちょっと違っている。sleep入れるとパケットの受信が遅くなるから、正常なTCPの実装なら自律的にRWINサイズは小さくなる。
ただ、帯域制限だと、どの程度の帯域かを指定できる。

134 ：名無しさん＠お腹いっぱい。 ：02/01/20 10:09

鯖側ばっかだけどクライアント側(操作)に制限(リロードタイムインターバル)
とか　ちゃちゃってかけることできないの？

135 ：名無しさん＠お腹いっぱい。 ：02/01/20 11:00

それって、HTTP標準にあるの?

136 ：名無しさん＠お腹いっぱい。 ：02/01/20 11:26

まず過去ログを2chの外に出そう。
MXで交換すればいいだろ。2chにsum置いといて偽造防止。

137 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:03

>132

＞どっか(fj?)でdbm+Perl掲示板を嘲笑する記事読んだ覚えあり。

どんな骨子なの？
<>をデリミタにして1000件ものデータを読み書きするのとどれがどうだっていうのか気になるところ(笑)

138 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:27

デリミタはtabに変更しよう。
または固定レコードにするとか。

139 ：132 ：02/01/20 12:47

>>137 元ネタは検索中. 元CSL現琉球大あたりの「有名人」の、1997年頃の発言。

骨子は、というと、
(1) 近頃Web掲示板とか立てている人多いけど、
　　NNTPプロトコルで負荷問題扱ってた人から見ると、
　　まじめにパフォーマンス考えてるのか？と突っ込みたくなる。

(2) たとえば、CGI+dbm+flock で実装している場合、
　　毎回dbmロードして、flockで排他制御かけてりゃ、
　　パフォーマンス悪くて当然。

(3) 通の選択は、DB管理専用デーモン立てといて、
　複数のHTTPリクエストを複数のCGIで受けて、一つのDBデーモンに処理依頼する。
　CGI-デーモン間の通信は、共有メモリ＆排他制御(か、ソケット)を使う。
　これが常識。

てな感じでした。

140 ：もなー君@お腹いっぱい ：02/01/20 12:52

>29
Linux板の住人に頼んだら、Win板とUNIX板を
閉鎖することによって負荷を軽減させると思われ｡

141 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:53

木形式のクライアントサーバモデルって感じ？

１つデータベースを用意して第１〜第８2chで共有みたいな。

142 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:55

>139
ありがとう。
んーでも、それも一長一短だよね(笑)

143 ：名無しさん＠お腹いっぱい。 ：02/01/20 12:58

>>139

ドテ。プレインファイルよりdbmの方が効率が悪いってリンクが張られるのかと期待していたんだけど。
デーモン用意してそこで集中制御した方がパフォーマンスいいの、そんなの当たり前じゃん。（ぷ

そんなややこしいことするより、きちんと行LOCKされるRDBMSを使った方がいいのでは？

144 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:01

いっそ独自プロトコルを作る。
これなら圧縮し放題。
かちゅ〜しゃの様なクライアントを作って希望者はそちらを使う。
httpと平行させても多少は軽くなるのではないか？

145 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:06

RDBMSに一票

146 ：139 ：02/01/20 13:06

ウチが数年前に作ったBBSですと、Oracle WGS＋RMIサーバ＋Servletですが何か？

147 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:15

問題点を整理しましょうよ。

1) 転送量が大きくて困る
2) CPU 負荷が高くて困る
3) どっちもで困っている

前回は 1) が問題で、CPU 負荷はどうでもいいから転送量を下げることを目標にしたんだよね。

148 ：139 ：02/01/20 13:16

一応マジレスしておきますと、

>>142 Perl+dbmの方がステップ・アップする良い指針だと思ったのですが、
短所はどういう所でしょうか？
＃DBデーモンの数は複数、forkして処理、readは排他しない、とします。

>>143 現在の２チャンネルは、デーモン方式なのでしょうか？
あと、RDBMS使うのは良いとして、
大きなテキストの格納とか、検索性能とか、全文検索とか考慮した場合、
２チャンネルの場合どのRDBMSを使うのがよいでしょうか？

XML-DBとか出てますが(藁

149 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:16

>>147
2)フルアセンブラとか？安易だが。

150 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:17

>>146 負荷問題なら Servlet という手もあるかもしれない。
でも夜勤さんがオッケーしないかもしれない。

151 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:18

>>147
0) ビジネス・モデルが確立していないので、費用負担に限界がある.

152 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:21

データベースサーバ（夜勤さん）−複数の低負荷CGI（有志）

153 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:24

>>147
1),2),3) 負荷テスト・ツールを使って、
テスト系で性能測定＆パフォーマンスチューニングすべき＞＞夜勤さん、ＨＥさん

速度パフォーマンスを売りにするなら、
回線帯域幅とサーバ数だけじゃまずいんじゃないかなー

154 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:26

CPU負荷を下げる場合でも、まずは、何がCPUに負担をかけているかを分析した方がいいのでは？
たとえば、祭り状態のとき、

1.一つのdatファイルに集中してアクセスされる。
2.datファイルを得るのは1プロセスで、他は当然に待ち状態になる。
3.forkがいっぱいおきる。
4.メモリの使用率が増え、PAGINGが増す。

なんてことも仮定できる。

155 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:27

ここってSolaris？

156 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:28

>>155
IIS

157 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:30

>>155
まじ．．．？

158 ：名有りさん＠お腹へった ◆fSunOs.U ：02/01/20 13:32

現行HTTPの状態でも　まだある程度転送量削減の余地はあると思うんだよね
去年８月の騒動の時にも指摘していたのに　放置されたままだったんだけど......

それは　read.cgiは"Last-Modified"吐くようになったけど　各板の*.htmlは吐いてない
ということなんだよね　恐らく*.htmlが"server-parsed"になってるためだと思うんだけど
なので

・　"server-parsed"の必要がなければ切る
・　広告の挿入等のため"server-parsed"の必要があるのなら　.htaccessで
　　　XBitHack full
　と指定した上で　各*.htmlファイルのパーミッションを"g+x"にしておく

という対処で　*.htmlでも"Last-Modified"吐かせることができるはずなんだけど


あと　OSの入れ替えというのは困難かも知れないけど　もし可能であって
マシン負荷が問題というのなら　Linuxから*BSD or Solarisに入れ替えると
いうのも考えられるけども......

159 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:38

>>152 2ch.netの外に、キャッシュ・サーバ作るという感覚で、いいんでないかい？

160 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:44

>>154-158
たしか2chはLinux+Apacheだったはず
で、夜勤さんのレス見る限りでは現在問題になっているのは転送量だけ
みたいだね。
loadavg見た訳じゃないけど、恐らくCPUはかなーり暇してるんじゃないかな？

161 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:47

2chの運営で利益がでるのって広告収入だけだよね？
とりあえず、広告をなんとかした方がいいかと
あんなんじゃ誰も見ないし、常に右端に表示されるとかでないと・・・

現状の方法では、どんな頑張っても何ヶ月も持たないと思う
ビジネス・モデルをなんとかせんことにはいかんともし難い

162 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:50

転送量って言っても、これ以上の圧縮は難しそうだな。

163 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:52

とりあえず、事業化の方向だそうだ。
http://yasai.2ch.net/test/read.cgi/event/1011398301/

今回の騒動は事業化への布石（ｼﾞｻｸｼﾞｴﾝ）かもしれない。

164 ：転送料金 ：02/01/20 13:55

>>161
2ch_browser + Web < Web広告収入
まで持っていかないと2ch_browserに移行した際にWebビュー数と
広告収入が減少してかなーりヤヴァイ状態に成るんじゃないかな？
だから
2ch_browser + Web < 2ch_browser広告収入 + Web広告収入
という図式が確立出来れば良いんだけどね。。。
でもオープンソースソフトに広告を載せるのは難しいよねぇ。。。

165 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:57

htmlやめて、curlでも使えば？(藁
http://www.curl.com/html/

166 ：名無しさん＠お腹いっぱい。 ：02/01/20 13:58

>>164
2PL(GPL)みたいなの作ってここからの広告表示を必ず表示。
・・・無理かなぁ。

今でもカチューシャ分は食いっぱぐれてるんだよね。

167 ：sage ：02/01/20 14:04

とりあえず、無駄な画像（背景画像など）を消すとか、htmlコードを最適化するだけでずいぶん違いそうな気がするのだが。

168 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:08

>>167
ローカルホストにsquidを入れるとか(藁
でもsquidってせいぜい20%程度なんだよね。。。

169 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:09

ようは事業化のためで、既に決定されていたことみたいだね

206　切込隊長 ★　sage 　Date:02/01/20 09:48
>>204

　現実面では、とりあえずマニア店、広告あたりがデフォルトスタート
ですね。発表のタイミング次第では、交渉がまとまったものも同時に
告知できるかもしれません。

　まあ・・・法人化という意味では、２ちゃんねるを法人化せずに、
２ちゃんねるの外部に会社を作ると言うコミケ方式でいこうかと考えて
ます。ともあれ、俺はひろゆき抜きの事業化は考えないので、立ち上げ
て軌道に乗るまでのお付き合いかと思います。

>>205

　ある程度決まってから意見を聞かないと無責任かなと。
　あれいいね、これいいねでは何も進まないのを恐れていました。

　それと、少人数で事業化を進めてきたので、取りこぼしたアイデア
やリスクを考える意味でも広く意見を引き続き伺いたいと思っている
ところです。というのも、寄付の議論でもありましたように、やはり
規模がまだそれほど大きくなければ寄付でいくのがベストだというのは
早期から分かっていたことで、今できないのはやっぱり後悔してる
部分でもあるんで。

　あと、夜勤さんの負担の問題や、削除人の皆さんへの還元などを
どうするかということですかねぇ。まだこの辺は詰め切れてない部分
ではあるのですが。

　ともあれ、転送量問題から半年で事業化のめどを立てるという
目標は達成したので、後は収益性、採算性の検算をどうするかに
頭が逝ってます。

170 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:11

転送量

http://www.yakin.cc/

171 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:19

そろそろJava使いにサーブレットで作ってもらうか（藁

172 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:21

>>171
その前にプロトコル考えてくれ！
何で作ろうとHTTPDに乗っかったままじゃあんまりかわらん！

173 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:23

>>172
同意。ボトルネックはhttp+gzip

174 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:24

2chへのアクセスしか許可しない設定でhttp proxyをそこら中にたちあげるってのは？
無料ではやれないか、、

175 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:28

>>174
その串にどう人を分散させるかも考えないとね。
でも、即時性がウリの2chにキャッシュサーバを置くのはどうかと。
結局みんなリロードしまくって・・・。

176 ：宇多田ヒカルさんの将来の旦那ですヽ(`Д´)ﾉｹｯｺﾝｼﾃｸﾀﾞｻｲ ：02/01/20 14:28

http://www2.odn.ne.jp/~aaq77600/unix.swf
　
頑張って
　
癌歯って・・・・・・

177 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:32

やっぱp2pキャッシュかなぁ〜

178 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:33

>>177
デコードプロキシとか。

2ch->超高圧縮ファイル->デコードプロキシ->html->PC

179 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:37

NNTP の実験はどうなったんだっけ。

180 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:44

>>177 p2pキャッシュの動向を教えて！！

181 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:45

>>180
http://pc.2ch.net/test/read.cgi/tech/998915621/l50

182 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:46

>>181
あ、これ次期2chの話だったんだ。

183 ：squid ：02/01/20 14:48

>>175
reload_into_ims on
これだけでリロード対策OK!

184 ：名無しさん＠お腹いっぱい。 ：02/01/20 14:50

>>183
後はどうやってプロキシごとに限りなく最新の情報を得るかだね。
一分ごと更新？

185 ：宇多田ヒカルさんの将来の旦那ですヽ(`Д´)ﾉｹｯｺﾝｼﾃｸﾀﾞｻｲ ：02/01/20 14:54

http://obuchi.naikaku.com/angriff/upred/source/2117.jpg
↑次期主力型２ちゃんねるサーバー状況　FILES　NO.01
　
どうよ？

186 ：squid ：02/01/20 15:02

>>184
reload_into_ims on
にするとsquidが勝手に Pragma: no-cache を If-Modified-Since に
置き換えてくれるから大丈夫だと思うけど。
つーか、read.cgiはそのままでもHITしまくってるので
単に串入れただけでも結構効果有るんじゃないかな。

187 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:04

>>186
なる、納得。おてがるに対応するなら手だね。

188 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:12

専用ツールのみアクセス可とかカードを使った有料化は
存続のためにはやむを得ないのかもしれないが、それを
やった時から2chではなくなってしまうような気がするなあ。

厨だDQNだヒッキーだと罵られつつも、誰でもどこからでも
気軽に参加できる（＝ごく普通のWebブラウザが最低ライン）
というシステムが、常に新しい大量の水（きれいとは限らないがｗ）を
2chの中に流し続けていた。堰を造って治水を始めた瞬間から、
規模だけでかい、生ぬるく腐敗したそこらへんのWeb掲示板に
成り下がってしまうような気がする。
そして最後はfjやNiftyフォーラムと同じ運命を．．．なんてね。

技術系の板で書くことではなかったな。スマソ

189 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:13

>>186
よく考えたらすごいかも知れない。

２ｃｈ本体への負荷はプロキシ台数分に。
プロキシへの負荷は１／プロキシ台数分に。
理想的な条件ではおいしい気がする。

190 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:15

>>188
独自プロトコルにした場合もCGIやJavaによるWebから閲覧可能なクライアントももうければ解決するのではないでしょうか。
と、技術屋志望の男は思っています。

191 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:16

Unix 板の避難所作ってよ。

192 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:22

だから、専用ツールを使うヘビーユーザにだけ課金しようという魂胆なんでしょ。
プロトコルは秘匿できないから、技術的にうまくいかないと思うけど。

サンリオとでも提携して、モナーグッズで儲ければいいのにね。

193 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:27

３リオ ﾏﾝｾｰ

194 ：名無しさん＠Ｅｍａｃｓ ：02/01/20 15:29

8頭身モナー抱き枕キボンヌ。

195 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:30

proxy分散して置けるくらいなら、そのマシン使ってサーバそのものを板単位で分散させた方が楽では？
CDN的に近いproxyに誘導するとかいうことまでやる気なら、それはそれで意味あるけど。

196 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:30

モナー型アフィーナきぼん

197 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:35

絶対、山梨王が拒否すると思う

198 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:36

要はHTMLリロードの転送量減らせばいいような
単純に板はスレッド一覧だけ表示にしてしまうってのはどう？
一回のリロードで20kb以下に落ちるような・・・・

初心者的単純な考えだな〜

あとかんがえられるのはHTMLの表示スレッド数を5件に落とす！

199 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:38

いまだに問題点がはっきり出てこないってことは、
今回の危機は運営側のｼﾞｻｸｼﾞｴﾝだと思うな。有料化の口実。

でもいつまでも無料で続けろとは言えんしなあ。

200 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:42

>>199
そこが問題だね。金がなければ立ち行かない。けど
課金すれば2chの中身が大きく変わってしまうことは
必死。
この辺がしおどきなのかな〜

201 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:42

書いた直後の板リロード辞めて
書き込んだスレを最新50でリロード

キャッシュとか、コード最適化の前にまずはできるところから
転送量削っていこうよ

202 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:44

まぁ、運営側が何考えていようと、枠組みを破壊しない範囲で(藁
自分にとって都合の良い抜け道を用意しておくってーのが、
よろしいんではないかと、書いてみる。

203 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:46

>>199
「今回の危機」って何?
.cgi 変更に伴う混乱のことだったら、運営側がやったに決まってるじゃん。

204 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:46

htmlのリンクには、確かに使いにくい所も一杯残っている(藁

205 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:46

専用ブラウザは便利だし差分転送もやってくれる（らしい）ので、
ベタなWebブラウザ読みより転送量削減には大きく貢献する
と思うんだけど、便利さゆえに閲覧回数が飛躍的に増加するから
かえってマイナスってことなのかな。

206 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:48

まあ、要は2chばっか見てるな、と。
たまには外にでて遊べ、と。

207 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:50

一日一時間までとか

208 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:51

>>205
単に金取りやすいところから取ろう、ってだけじゃないの?

209 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:52

広告も、バナーはやめてもいいんじゃないかなあ。
googleの広告成功の秘訣はテキストオンリー＆検索文字列に対する的確な
広告の表示なわけで。
２ｃｈも広告営業を強化して、できるだけ各板の趣向にあった広告をテキストベースで
スレのトップにでも掲載すれば、多少はクリック率も上がりそう。

問題は２ｃｈに広告を掲載するのは企業としてのプライドが許さないってところがありそうなこと。
広告が掲載されているスレでボロボロに叩かれている可能性もあるわけだし（ｗ

210 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:53

[ERROR]２重リロードですか？

211 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:58

実際「金払ってもいい」って奴からの募金募ってもどのくらい効果あるだろうか・・・

212 ：名無しさん＠お腹いっぱい。 ：02/01/20 15:58

[ERROR]童貞ですか?
彼女がいるひとはそのままリロードしてください・・・・

213 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:00

>211
金はないが、身体でなら払ってもいい。
コーディングとか、夜のお相手とか。

214 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:03

>>213
逝っとけ。
http://teri.2ch.net/shop.html

215 ：広告こんな感じ？ ：02/01/20 16:03

0 名前：ホゲサッカー・ドットコム 投稿日：02/01/15 20:05
World Cupのチケットが当たる！
http://www.hoge-soccer.com/hoge/hoge.html

1 名前：1 投稿日：02/01/15 20:07
ﾅｶｰﾀについて語りましょう。


2 名前：2 投稿日：02/01/15 20:09
>>0
ﾌﾞﾗｸﾗ

216 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:15

書き込み時にcgiに現在の最新レス番号を渡して、
書き込み後は新着レスのみ表示。

217 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:27

dat直読み禁止して専用ブラウザで課金するとしても、
subback.html と read.cgi で無料で同じことできちゃうよねえ。

218 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:27

>>216
インターネットにゅーすかい。

219 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:35

jbbsやnihenみたいな外のBBSにリンクさせて
負荷分散すればいいかも。
ニュース関係が＋、７と３つもあるんだから一個か二個
過去ログごと引き取ってもらえれば．．．．

220 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:37

もう２ちゃんの技術がどうこうっていう問題ではないだろ？
いま２ちゃんに一番足りないのは、「お金」
一番高額な帯域幅は、ユーザーを減らすか、使いにくくするしか対策はない

221 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:40

ニュー速&ラウンジを外部委託しる
転送量も劇的に減るし

ニュー速の負荷を耐え切ったら
サービスプロバイダーの評価も劇的にアップするであろうって誰か言ってなかったっけ?

222 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:40

あるいはチャット状態をどうにかするか。

223 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:42

今の所の問題はリロードだと思う
>>198の
＞単純に板はスレッド一覧だけ表示にしてしまうってのはどう？
これはかなり有効だと思われ
>>216の
＞書き込み時にcgiに現在の最新レス番号を渡して、書き込み後は新着レスのみ表示。
で今回の危機は回避可能

224 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:42

>>220 いま２ちゃんに一番足りないのは、
切込投資家さんの遊び心を満足させる「経済活動」

でも、技術面も心もとなかったりして...
P2P掲示板、がんばってくれ。

225 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:43

使いにくくするのなら
>>198と>>201なんてどう？

226 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:43

貼っとく
http://teri.2ch.net/test/read.cgi/accuse/1011456825/388-389

227 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:43

ネットニュースのsucking（クライアントの振りしてオフィシャルな
ニュース鯖から記事を一括ダウソして、プライベートなmyニュース鯖に
再構築して、お家でﾏﾀｰﾘとニュースを読む）を思い出した。

これと同じ仕組みを誰かが作って、表向きは無料のブラウザから
アクセスしているが、裏ではｺｿｰﾘかちゅ〜しゃつかって今までどおり
読むとか（藁

228 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:43

>>219
ちょっと賛成。

2chは同一の掲示板スクリプトを使用するサイトの集まりです。
本家はリンクと２，３の掲示板を管理しています。
みたいな。

229 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:44

>>227
ID 取るときの契約書に
「そういうことやっちゃだめ」って書かれるんでない?

230 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:44

んで、P2P掲示板と、read.cgi改良と、2ch.net外キャッシュ・サーバ
に協力するにはどうしたらいい？

231 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:45

>>228
ring project みたい。

232 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:46

>>228
でも８．２５危機の直後、板引き取りますを宣言してくれた
2chライクな掲示板が、負荷に耐えきれず次々と陥落して
いった事実がな．．．

233 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:47

>>230
P2Pは今やってるグループの研究成果次第。
read.cgiは誰かが独占的に修正するのが吉かと。もしくはCVSw。
キャッシュサーバは常時接続組が実験して結果報告？

234 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:47

RDBMSに書き込み情報入れるのは、２ちゃんのようなシステムでは非効率
もしRDBMS使うとすれば、スレッド並び順保存くらいしかないだろ

235 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:48

>>234
じゃあどうしよう？

236 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:48

>>234
> ２ちゃんのようなシステムでは非効率
なんで?

237 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:50

>>234
カキコされたテキスト自体は普通のファイルシステム（ストレージ鯖）に
置いて、そこへのポインタ情報のみをRDBで管理するということね。
確かにカキコ自体をテーブルにInsertするのはどうかと思ふ

238 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:50

ちょっとお聞きしたいのですが、
今回の有料化っていうのは負荷対策の一環なんでしょうか？
それとも、負荷と有料化はまったく別の話？

239 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:52

負荷に見当った増強できるように有料化するんでない?

240 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:52

>>238
＞有料化

・・・はい？

241 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:55

だ〜か〜ら〜〜前回の例でいうと
無償で回線提供してくれているところが負荷が高すぎるわ！！
金よこせって言い出した

単純に言うとこうだな

242 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:56

>>240
http://teri.2ch.net/test/read.cgi/accuse/1011457309/23

From: [23] ひろゆき ◆L3IpNS4A <>
Date: 02/01/20 01:37 ID:fFqmr2Uc

ツールは、認証IDをつかうと、
ブラウザじゃできないことができる、、
んで、認証IDは有料ってかんじ。

243 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:56

>>238
批判要望板の該当スレ見れば分かると思うが
別に普通に読んだり書いたりするのが有料化されるわけじゃない
「有料」って言葉に過剰反応した厨房が勘違いして騒いでるだけ

244 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:57

>>238
金さえあれば、負荷が高くなっても、マシン買って、帯域代はらえばいい
いま２ちゃんに一番足りないのはお金
ま、お金のことをこの板ではなしあってもしょうがないけど

245 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:57

http://pc.2ch.net/unix/　を表示させると

【1:238】[深刻] ２ｃｈ負荷問題ふたたび勃発
1 名前：名無しさん＠お腹いっぱい。 2001/03/31(土) 04:36
:

【2:708】Apache関連
：
：

と1枚もののHTMLで表示でますわな。

こうじゃなくて、
【2:708】Apache関連
とか、スレ単位に表示するようにしといて、
http://pc.2ch.net/unix/で直接getするのはそれらを16コあつめた
frameタグが書いてあるHTMLになってる　ってどないでしょ？

1回のhttp://pc.2ch.net/unix/のgetで
まるまる74KBのHTMLが転送されにくくなるんじゃないかな、と。
（スレ6〜16くらいまではスレ1〜6にくらべると
　変化している可能性が少ないんじゃないかとおもうので、
　一番すくないときはスレ1〜6の分だけで済むかな？なんてね

246 ：名無しさん＠お腹いっぱい。 ：02/01/20 16:59

あと、
過去ログはトリポッドとかいろいろ借りて、
定期的にそっちにとばすとかだめかしらん？
トリポッドってCGIつかえるっしょ。

夜勤サンが一日一回トリポッドへ過去ログを転送するCGI動かす
必要がでてくるけどね。

247 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:02

>>243

> 別に普通に読んだり書いたりするのが有料化されるわけじゃない
DAT読みは普通じゃないの？

248 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:03

＞frameタグが書いてあるHTMLになってる　
利便性０

249 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:03

>>246
転送するのにわざわざ CGI を使う必要があるのかと問い詰めたい。

>>247
「普通に」=「web ブラウザで」と読みたい。

250 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:04

大岡山にサーバ置いてもらって
daemontoolの負荷試験を兼ねて運営してもらうつーのはどーだろうか。

251 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:04

普通ブラウザ
ふつーかちゅーしゃ
ふつ〜navi2ch

252 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:04

＞２４７
”読んだり書いたり”
だと思われ

253 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:06

>>250
＞大岡山にサーバ置いてもらって
検閲されて、気に入らない奴はログ公開されそうだ

254 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:06

大岡山＝投稿大
daemontool＝http://www.emaillab.org/djb/daemontools/daemontools-howto.html
でしょうか？

255 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:08

>>248
ブラウザからみても利便性かわらないよ。
imodeはimode専用CGIだし、
PDAもimode専用CGIで見るだろうから。
もっとも、frameタグ使えない機種とかテキストブラウザでは
利便性落ちるが・・・lynxとかw3mが該当すんのかな？

>>249
よーしお父さんtelnetでコマンド打ってもいいけど
万一夜勤さんがダウンした場合に備えて、
厨でもできそうな手でやっときゃ万全かなと。

256 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:10

>>247
http://teri.2ch.net/test/read.cgi/accuse/1011457309/23
でひろゆきが言ってるのは

http://teri.2ch.net/test/read.cgi/accuse/1011456825/132
みたいなことであって
dat直読みのこととは関係ない

dat直読みは２ｃｈブラウザでしか出来なくなるというだけで
課金されるわけじゃない、今まで通り無料



・・・・という風に批判要望板見てると解釈出来ると思うけど間違ってる？

257 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:11

>175
過去ログとか画像とかのスタティックなものには効果あるだろうね。
ただ、この手の掲示板(笑)で、過去ログのや閲覧の有料化をすると、
一気に冷える可能性もあるね。

258 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:11

>>253
いや、DJBにいい知恵だしてもらえるかなと思ったんだけどだめか。
（つーかDJBから「氏ね」って英語で言われそうだな）


しかし・・・2chも伝送量・ユーザ数は
基幹なみになってきたんだなあ。
IBMを叩くスレってみたことないから、
IBMにサーバおいてもらってAS/400の宣伝につかってもらう
つーのはだめかしらん。

259 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:11

>>255
横に１６個Frameなんぞ並べられたら使いにくいと思うが。

260 ：宇多田ヒカルさんの将来の旦那ですヽ(`Д´)ﾉｹｯｺﾝｼﾃｸﾀﾞｻｲ ：02/01/20 17:14

http://obuchi.naikaku.com/angriff/upred/source/2117.jpg
↑次期主力型２ちゃんねるサーバー状況　FILES　NO.01
　
どうよ？

261 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:15

>>259
違う違う、タテに並べるの！！

262 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:16

>>257
googleのキャッシュのせいで全然儲からなかったりｗ。

263 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:18

>>261
縦16個も十分きついと思うが。

264 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:25

>>258

2ch自体がブラックなイメージがあるからなぁ････。

265 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:28

>>264
実際、逮捕者の数はこの掲示板がトップでしょ。

266 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:28

>>264 その位の遊び心が欲しい...ってIBMじゃ駄目かなやっぱ。

267 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:31

>>266 サーバ筐体の色は、黒。

268 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:36

PlayOnlineのサーバみたく「特注で黒く塗ってもらいました」と自慢する、と。

269 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:44

>>258
やっぱり、unixなrs6000のほうがいいんじゃない？
でも、ibmのメインフレームosもunix95だかの認証取ってたりするし・・・

やはりここで、メインフレームのパワーを見せ付けるために、
やっぱ、s/390+linuxしかないね
(もちろん１台構成)

270 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:46

>>265
でも、人数が多いから、逮捕者も多いのは当然だろう
逮捕者の割合ではかわらんとおもうけど？

271 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:46

なんかLinux板に同じ題名のスレが建ってるからあっちに任せよう。

272 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:49

>>271
任せるって？
別にこのスレだってなにか任せられているわけじゃないでしょ？

273 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:53

じゃ、こっちはサンリオ萌えのスレにしよう。

ピューロランドで等身大キティとモナーの共演が見たい俺様。

274 ：名無しさん＠お腹いっぱい。 ：02/01/20 17:57

等身大キティ

ﾌﾞﾙﾌﾞﾙｶﾞｸｶﾞｸ

275 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:03

頑張れロリコン共。

276 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:03

271はいつも等身大ですが何か？

277 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:06

>>276 キティ違い

278 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:13

>>263
画面のタテ幅でアラインされるから確かに16コもタテに並ぶと
ちっちゃすぎてたまらんな・・・

んじゃ、http://pc.2ch.net/unix/の部分の表示処理のCGIだけ
外のサーバに置いて、そことpc.2ch.net間でやりとりさせて似たようなことをする

ってやると、今度はそこのサーバの転送量問題になるか。
うまくいかんのう・・・
スレ単位

279 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:20

>>117
>>201
以外にはCGI的になんとかする方法はないような感じだなこりゃ。
あとは過去ログ外だしでその分の転送量をそぐか。

そろそろ万策つきましたな。Linux板にまかせるか（笑）

280 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:20

>>234

2ch型でもRDBMSに合うと思うけど。具体的にDB設計したほうがいい？

281 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:21

http://pc.2ch.net/test/read.cgi/linux/1011518241/

282 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:27

過去ログの負荷ってどのくらいなんだ? この負荷が結構あるようならば、P2PCacheに追い出したらどうだ?
静的だから改竄はデジタル署名で防げて、技術的なハードルも低いと思うが。

283 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:30

過去ログを外に出しても、またそこの転送料とかで問題になるんでない？

284 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:31

>>234
DB使う場合はにどのデータベースエンジンをターゲットに
されますか？

285 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:31

最初にこの話を聞いて、cpu負荷についてぱっと思いついたこと
「intelのアイテニゥムは・・・。」
「じーおんは・・・。」
「AMDのAthlonMPプロセッサは・・。」
というふれこみでintel,AMDから寄付してもらう
ありえんな

書いててばからしい
宇津だ。

286 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:40

・ビジネスモデル案

1 板ごとに貼る広告を変える
　　→ヒット率アップ。
2 ヒット率で収入が変わる広告に変える(valuecommerceとか？）

・負荷を下げる案

sourceforgeとか使ってみんなでread.cgiを改造


なんて感じはどう？

287 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:41

　　　　　　　　　　　http://1.████
　　　　　　　　　http://1.██▓▓▓▓██
　　　　　　　　http://1.█▓.._▓.._▓▓▓▓█
　　　　　　　http://1.█▓.._.._▓▓▓▓▓▓▓█
　　　　　　　http://1.█▓.._▓▓▓▓▓▓▓▓█
　　　　　　http://1.█▓▓▓▓▓▓▓▓▓▓▓▓█
　　　　　　http://1.█.._▓▓▓▓▓▓▓▓▓▓▓█
　　　　　http://1.█▓▓▓▓▓.._▓▓▓.._▓▓.._▓█
　　　　　http://1.█▓▓▓▓.._█.._▓.._█.._▓▓▓.._█
　　　　http://1.█▓▓▓▓▓▓.._▓▓▓.._▓▓▓▓.._█
　　　　http://1.█▓▓▓▓▓█▓▓▓▓█▓▓▓▓▓█
　　　　http://1.█▓▓▓▓▓▓████▓▓▓▓▓▓█
　　　　　http://1.█▓▓▓▓▓▓▓▓▓▓▓▓▓▓█
　　　　　　http://1.███.._█.._█.._█.._█.._██
　　　　　http://1.█.._█.._█.._█.._█.._█.._█.._.._█
　　　　http://1.█.._█.._██.._█.._█.._█.._█.._█.._█
　　　　　http://1.██.._█.._█.._█.._█.._█.._█.._█

288 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:44

えっちねた板とか見てると思うけど、
本文に埋め込む広告はあきらかに需要があるよね。

289 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:52

1板1サーバは無理だろうが、もっと分散できませんかね？
技術論よりは運営形態論の次元な気がする。

290 ：名無しさん＠お腹いっぱい。 ：02/01/20 18:54

>>288
奴らは只で宣伝出来るからやってると思われ…
つか、ビジネスモデルはhttp://yasai.2ch.net/test/read.cgi/event/1011398301/へ逝け。

291 ：198,201 ：02/01/20 18:58

>287のようなお馬鹿がいるから
httpハイパーリンク切っちゃうとかしない？

それだけでも20バイトは削れると思うよ
>287がこれやるだけで5kb転送ふやしているからねぇ

292 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:09

>291
それはいいかもしれない。
ただ、>287みたいなバカは一部だよ。

293 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:27

ﾐﾝﾅﾊﾝｶｸｶﾅﾃﾞｶｷｺﾒﾊﾞｶｲｹﾂﾀﾞﾖ

294 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:35

スレの題に、負荷問題再び、ってあるけども、

今回騒がれてるdat直読み禁止は、負荷対策が目的ではなく、
2ch専用ブラウザ郡専用の有料付加機能のための実験だったんないのかなぁ？
その付加機能にしたって、
今、IEやカチューシャで出来ることに制限をかけて有料にする。
って事でなくて、
新たに、便利な機能を付け足して、その機能を使いたい人だけ課金する。
って事でないのかなぁ･･･。
その、便利な機能ってのが何かは、まだ見えてこないけども。

295 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:36

LZ77の特性を生かした文章を書くのもいいね。
同じフレーズをくりかえしくりかえし…

296 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:38

Everybody, write in English.
Wouldn't it be a nice solution ?
Because every UNIX user always reads
English man pages, Web pages.
It's not painful.

297 ：I don't think so ：02/01/20 19:46

>>296
I fell pain reading YOUR English.

298 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:47

It's nice.>>296
But, I know better solution.
It is,
disconnect your computer, and hung yourself!

299 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:52

>>284 たしかに、掲示板のようなシステム (RDB的な検索が重要でない)の
　でのDB選択/設計って、興味深いですね。

　NEC の今は亡き PC-VANや、Dell ComputerのECサイトでは、
　ObjectDB使って{た|る}そうですが、いかがなもんでしょうか

300 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:53

>弐九六-弐九八
諸君掲示板書込漢字記述推奨。
是文字数短縮之方法也。
日本人可読漢字。英語不可率高。

301 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:56

禿同也

302 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:58

10111010001000101110111000101

303 ：名無しさん＠お腹いっぱい。 ：02/01/20 19:59

>>参〇〇-参〇壱
回線切断首釣汁

304 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:00

ここはプログラマ板ですか？

305 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:02

文字数短縮、然、文字種増大。
故圧縮率悪化。我不考是良思考。

306 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:04

とりあえず、>>216 のようにすれば幾分かはましになるだろう。
まあ、もう牡蠣ｎする方向で決まってるようだから
どうでもいいみたいだけど。

307 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:08

倉庫行きスレ見たら
> Monazillaツールを使うと、すぐに読めます。
だって。
http://pc.2ch.net/test/read.cgi/unix/999166513/ とか。

308 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:11

1つのアイデアで実現性は疑問、さらにXSLサポートなブラウザしか駄目だけど

スタイルをXSL表現にする。(CSSでも一緒かな）
ブラウザに返すデータをできるだけ短い名のタグにして返す
スタイルはブラウザでキャッシュされるからデータ量が減る
ってのはどう？

309 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:12

なんにしろ、このような問題はでてくるから考えておいた方がいいかと
まだまだ改善の余地はあるし、他の方法を考えるのも面白い

310 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:19

だいたい減らしていい板もあるんじゃないの
速報系だけで３つもあるし

ここもごそっとしたらばにでも移れば？

311 ：　 ：02/01/20 20:24

>>310
それは利用者側の論理だ。運営側からみたら、それは致命的。

312 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:26

>>310
どうやって移すの?
住人全員説得してくれる?

313 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:27

個人的には、UNIX板と過激な恋愛板とコスプレ板を統合してくれると
巡回の手間が減って有難いのだが。

314 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:30

>>313
UNIXの過激なコスプレ板？

315 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:35

>>314
過激なUNIXコスプレ恋愛板。

316 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:38

>>315
いやだなぁ、「過激なUNIX」。
「UNIX越すプレ」も嫌だけど。

317 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:41

「よーし、お父さんRMSコスで過激にエッチしちゃうぞ〜」

みてられん。

318 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:41

コスプレオタとUNIXオタとの過激な恋愛板。

私、あなたが今すぐこのコスしてくれなきゃ死ぬ！
まて！もうちょっとでリダイレクトが終わるんだ！！

319 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:41

>>313
頼むそれだけは勘弁してくれ。
同じ趣向の持ち主が集まっているならともかく、まったく興味を持たない
人間も同居しているんだ。今だって興味ないネタでも我慢しているのだよ。

320 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:43

ちょっとこれワラタ。
http://isweb30.infoseek.co.jp/computer/dnasuoht/cgi-bin/img-box/img20020115232257.jpg

321 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:44

今日一日で、http://www2.odn.ne.jp/~aaq77600/unix.swf
がジョークだという事が良〜くわかりました！

322 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:45

>>321
お前は何を見てきたのか？
絶対こいつ今表示されてる物しか読んでないよｗ。

323 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:46

>>320
お前はさっさと消滅しろ。

324 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:46

へ、前のバージョンとかあるの？

325 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:49

あの時と今回は状況が違う。

326 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:52

どんな映画でもそうだけど、
「２」はつまんない。

327 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:53

>>325
だね。
ちょっとくらい板が潰れると悲壮感が書き込みに出るのかも．

328 ：名無しさん＠お腹いっぱい。 ：02/01/20 20:55

板を減らしたところで、住人が類似の板に移動してカキコを
続けるので、転送量＝アクセス数増大の問題は回避できないと
思われ。そりゃ、板廃止直後には一時的にアクセス数が
変動することはあるだろうけれども。

「あれ、○×板がなくなっちゃった。じゃあもう2chはやめよ」という
ライトユーザは、そもそも転送量爆発の主たる原因にはなってない
と思ふ

329 ：名無しさん＠お腹いっぱい。 ：02/01/20 21:04

>>328
要は書き込む人数の問題。
三つの板が統合すれば立つスレッドは１／３になる。
どの板も半分はクソスレだからダメージは軽微かモナー。

ところでモームス羊と狼って何が違うの？？

330 ：名無しさん＠お腹いっぱい。 ：02/01/20 21:11

>>329
厨房パワーはリニアじゃない。3つの板の厨房が集まるとパワーは8倍。

331 ：名無しさん＠お腹いっぱい。 ：02/01/20 21:13

問題は解決しそうなのか？

332 ：名無しさん＠お腹いっぱい。 ：02/01/20 21:14

今度は俺が何とかしてやるから
事の顛末を記せ。

333 ：名無しさん＠お腹いっぱい。 ：02/01/20 21:14

>>330
スレ立てすぎです。は役立たずかな？

試しに各板の制限数を５ずつ減らしたら劇的に減ったりとかしないかな。
劇的は無理か・・・。

read.cgi ver5.26+ (01/10/21-)