---

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

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

325 ：名無しさん＠お腹いっぱい。 ：02/03/25 02:14 ID:???

何か話が飛んでるような気がします。

subject.txtを読むのと、
subject.txt読んで更新チェックするのと、
dat直読みの巡回をするのと、
dat直読みでスレッド取得するのと、

今は何の話をしているんですか？

326 ：Dream ★ ：02/03/25 02:15 ID:???

>>323-324
感情論はよくわかりますし、実際問題、大変な作業を全く見返りを
求めずやってるのだ、ということは理解しているつもりです。

その反駁は、ですからよくわかるのですけれど、
「だったら、この現状をどうするんだ」
という視点からの発言もお願いしたいのです。
そういう場所ですから。

327 ：ななむす ◆nnmm.69A ：02/03/25 02:16 ID:???

read.cgi呼び出しのチェックの話。

単純に、たとえば１分以内の再呼び出しを弾くためには、１分間分のアクセスリストを
保持して、そのファイルをオープンして検索かけるわけですが、これは鯖単位とすると。。

１分間の呼び出し分だけファイルオープン数が増える（read）。
その何分の１かファイルオープン数が増える（write）。
わけで、高負荷なときはすさまじく重くなり、低負荷の時はあんまり意味のない機能かと。

328 ：Dream ★ ：02/03/25 02:19 ID:???

夜勤さんが言ってらしたのですが
「回線帯域も、サーバも、予算が潤沢にあればすぐにも解決」
する問題ですよね？実際。

そういう解決法ではない解決法として、じゃあ、monazillaとかそのような
比較的意志の疎通がとりやすい緩い結束
(なのかどうか、私自身は加わっていないのでわかりませんけど憶測で)
に、今後のサーバの「転送量とサーバ負荷のトレードオフ」のコントロールを
ゆだねられないとしたら、どのようにしたらよいのかを、ご提案いただきたいのです。

329 ：ななむす ◆nnmm.69A ：02/03/25 02:19 ID:???

>>326
たぶん、押し切って勝てるかどうかの問題かな。。。
夜勤さんやひろゆきさんたちの趣味の問題でもあるか。

みんな、理解はしていると思いますよ。
ただ、苦労して付いていく人がどれだけいるか、
２ちゃん住民の２ちゃんに対するコミットが変わりやしないか。。。

住民減って大歓迎なら、やっちゃってもいいと思う(笑

330 ：Dream ★ ：02/03/25 02:21 ID:???

>>327
２チャンネル専用プラグインを開発して、push型に更新するというのはどうでしょう（妄想）

331 ：ななむす ◆nnmm.69A ：02/03/25 02:23 ID:???

>>330
あの前提崩していいなら、ありだと思いますよ。

# でも、それなら P2P型プロジェクトの類の方が良いと思いますが。。。

332 ：名無しさん＠お腹いっぱい。 ：02/03/25 02:24 ID:???

横やりすまんが、ほんとはツール使われるのイヤなんじゃないの？
そうじゃなかったらこんな規制しないもん。いっそのことツール禁止にすれば？
反発あるかもしれんが、もともとツールなんてなかったんだし。どうよ？

333 ：Dream ★ ：02/03/25 02:27 ID:???

>>331
P2Pのタイムラグとか、解決できるんでしょうかね？
各ユーザ間の回線がどんどん太くなっていったら、あり得る話ですよね。

FTTHとかB-Flets100Mとか使って２ちゃん運営、というような話も誰かしてましたけど。
昔。
(みんな妄想です)

334 ：Dream ★ ：02/03/25 02:28 ID:???

>>332
ツール使われるのがいやだ、というより、
帯域使用料やサーバの慢性的な高負荷に耐えられない、
ということだと思うんですよ・・・
その要因になるものは、何とか排除したいなぁ、というのが今までの流れなのです。

335 ：ななむす ◆nnmm.69A ：02/03/25 02:29 ID:???

>>333
大幅に仕様変更するなら、P2P的なものの方が未来を見てるかな、と。
いや、なんならＱ２専用のイントラネットで２ちゃん運営とか（ばか

336 ：ななむす ◆nnmm.69A ：02/03/25 02:31 ID:???

>>332
私が夜勤さんの立場なら、８月からツール全面禁止の方向にしたと思います。。。

# でも、あのときそういうこといったら、とても反発が強かったです。
# 考え無しな発言だったと思います。Monazillaさんたちがんばってるんだもの。

ま、そんなこといってもしょうがないので。

337 ：名無しさん＠お腹いっぱい。 ：02/03/25 02:41 ID:???

>>336
あれ、そうだったんですか？
ブラウザより転送量が抑えられるので、
ツール使用を推奨していたと思ってましたが…

# サーバに負荷かけてでもgzip導入した、って話聞いたけど

338 ：夜勤 ★ ：02/03/25 02:42 ID:???

UpTime(choco) = 9:40am up 8 days, 2:05, 0 users, load average: 0.34, 0.45, 0.48
UpTime(vip) = 9:41am up 23 days, 11:47, 0 users, load average: 1.38, 2.03, 2.39
UpTime(love) = 9:39am up 33 days, 22:55, 0 users, load average: 12.02, 9.37, 9.15

今日はこの辺で、おしまい
明日移行は game サーバも一緒にとります。
数日してから game サーバにも導入してみましょう。

339 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 02:45 ID:???

やっと過去ログ読んだけど、議論がループしてるような気がする^^;
どっかで聞いたことがある話がチラホラ・・・

思い切って、全ユーザー課金にしたら？
月１００円とかなら出すよ。

340 ：名無しさん＠お腹いっぱい。 ：02/03/25 02:46 ID:kN2MP1de

私が夜勤さんなら、逆に、ブラウザ完全禁止にして、cgiからhtml吐かせる
部分を完全に削っちゃうけどな。というか、ユーザのPCに表示部を任せて
鯖側はデータのみの方が、転送量＆負荷的に有利だと思うが。

341 ：名無しさん＠お腹いっぱい。 ：02/03/25 02:46 ID:???

>>337
当初はmod_gzip使わないでやったからMonazillaツールのみgzip効果があった
現在はmod_gzip入っているのでブラウザでも問題なし、ということでは？

342 ：ななむす ◆nnmm.69A ：02/03/25 02:47 ID:???

>>337
超短期的には、gz圧縮がきかなかったからブラウザが正解。
短期的には、差分取得できるし圧縮もできたからツール使用が正解。
長期的には。。。
（結局はユーザーインタフェースとしてどちらが便利か＝鯖に負荷かけるか、だと）

>>338
ぺこり。

343 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 02:48 ID:???

>>340
それ、（･∀･）ｲｲ!
Ｓ／Ｃシステムから考えると一番いいと思うなぁ・・・

344 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 02:50 ID:???

bbs.cgiを最適化するというのは、
短期的に考えるといいかも知れないが、
長期的に考えると仕様変更に弱くなって辛いかもとか
思ったり・・・

結局、付け焼き刃じゃダメなんだって！

345 ：名無しさん＠お腹いっぱい。 ：02/03/25 02:51 ID:???

ツール強制になった時。
それは２ちゃんねる終焉の日。

346 ：Dream ★ ：02/03/25 02:53 ID:???

>>338
お疲れさまでした。

347 ：ななむす ◆nnmm.69A ：02/03/25 02:53 ID:???

>>343
read.cgi的動作をクライアントに任せるのは、確かに魅力的ですが、、、
read.cgi自体の負荷をもっと削る（特に ressplitter_splitあたり。>> 制御）
前提なら、私は指数級数的なアクセス増大の方が怖いです。。。
Apacheまで手を入れる前提なら、両手を挙げて賛成。

348 ：Dream ★ ：02/03/25 02:55 ID:???

妄想と至急策が混在しててすいません。

read.cgiのみは今後もhtmlで提供するけど、書き込みなどは
ツールじゃないと出来ない、といったのを妄想していました。いま。
意味ないですが。

349 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:09 ID:???

>>348
書き込みを規制してもあまり意味ないんじゃないの？
実際はROMの方が遙かに多いでしょ？
いや、データを取った訳じゃないから分からんけど。

350 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:10 ID:???

書き込み規制＝1ch
とか言ってみるテスト（ｗ

351 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:11 ID:???

>>347
＞Apacheまで手を入れる前提なら

私はやって欲しいけど、なーんの権限も持ってないからなぁ

352 ：名無しさん＠お腹いっぱい。 ：02/03/25 03:12 ID:???

>338
お疲れ様。

ということで本日の負荷グラフ最終版です。
ttp://mappy.mobileboat.net/~seek/up/index.cgi
No.807です。

353 ：名無しさん＠お腹いっぱい。 ：02/03/25 03:14 ID:???

鯖にはあまり手を入れないっていうのが前提ですね。
結局鯖に手を入れると夜勤さんの管理負担が大きすぎるので、そうしたいなら他のところで
やって、というのが本音のようなので。

354 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:14 ID:???

>>352
乙！

355 ：Dream ★ ：02/03/25 03:15 ID:???

>>349-350
うんうん(笑)

>>351
Apacheに手を入れるのって、具体的にどんなヒントがあるんでしょう？

356 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:15 ID:???

やはり、政略的な面から言わせてもらうと、
直ちに雑誌掲載禁止の措置を取るべきだと思う。
ネトランとかはマジで悪質だぞ。

357 ：名無しさん＠お腹いっぱい。 ：02/03/25 03:22 ID:???

なあ、技術的な話題に変えたつもりかもしれないが
やっぱり場違いくんだよ。話が見えていないんじゃないか。>>351
不確定な前提で話しすぎていて無駄だらけ。頼むからROMっててくれないか？

358 ：夜勤 ★ ：02/03/25 03:22 ID:???

>>356
さんせ〜い。

359 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:25 ID:???

>>358
いますぐやろうよ（ｗ

360 ：名無しさん＠お腹いっぱい。 ：02/03/25 03:28 ID:???

>>359
作った人間が決める事

361 ：謎の”管理”人（ｗ ：02/03/25 03:28 ID:???

夜勤もいねーし一言。
管理者側からすっと「お客さんﾏﾝｾｰ」なわけだ。
でもこの２ちゃんは大きくなりすぎちゃって、
サイトを開く家（場所）がないと・・・。
確かに鯖いっぱい借りて分散すればいいわけだが、
それには金がかかる。
そこら辺の問題が一番なんでしょ？違うかったらｺﾞﾒｿ

362 ：謎の”管理”人（ｗ ：02/03/25 03:28 ID:MM0zLSKt

>358
ありゃまだいたし（ｗ

363 ：謎の”管理”人（ｗ ：02/03/25 03:29 ID:???

何気に動揺・・・ageてｽﾏｿ・・・（鬱

364 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:31 ID:???

>>361
３ちゃんを作って分散を・・・
って兄とかいちごとか色々あるね（ｗ

365 ：名無しさん＠お腹いっぱい。 ：02/03/25 03:33 ID:???

>>357じゃないけど、AJA6H/Ws ◆MPnX7dHAは発言がズレてると思う・・・

366 ：謎の”管理”人（ｗ ：02/03/25 03:35 ID:???

>364
ﾚﾝﾀﾙ借りて思う事。
「持ち主から苦情来たらどうすんべ・・・」
で、実際今そーいった問題が来てるわけだ。
転送量とかってのね。
いくら圧縮かけたり、巡回禁止しても、
これだけ２ちゃんが大きくなったら対応するのは難しいと思う。
課金ってのは好きじゃないけど、
今の現状考えたらいたしかたなし・・・ってとこかな。

367 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:40 ID:???

>>366
まぁ、私は８月から覚悟してましたので・・・
規制がかかるくらいなら、課金を選びますね。

ただ、●にも問題があるからびみょー・・・
メリットなさ過ぎだし、カードでしか支払えない。
せめて、銀行から払えればいいのだけど。
私はカード持ってますけど、一般的には弱いと思う。
禿しくがいしゅつの意見で悪いけど。

368 ：ボヤッキー ：02/03/25 03:41 ID:???

>352
お疲れ様です。
http://www6.ocn.ne.jp/~boyakkie/average.html

369 ：謎の”管理”人（ｗ ：02/03/25 03:44 ID:???

>367
わかるよ。今のままじゃね・・・。
まぁそれは今後経営者達が考えればいいんじゃね？
俺が今言いたいことは、
こんだけ夜勤とかがんばってるけど、
所詮いたちごっこで、また同じ問題が起きるって事。
まぁそれだけ人気あるからしゃーないけど（ｗ
でもここはちょっと２ちゃんのターニングポイントだね。
１００円や２００円払ったって俺はいいと思う。
それだけ楽しめればね(^^ゞ

370 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:51 ID:???

>>369
そーそー、bbs.cgiにいくらテコ入れしても結局は耐えられないよ。
そして、最適化で難解になったコードに後でまた苦しめられる二重苦・・・

課金が強制的になれば、月１００円でも
そうとうな収入になると思うのだが。

グッズが出ても買うよ。
私がマガジソかった理由は、単純に
オマケのステッカーが欲しかったという理由だから（ｗ

371 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 03:51 ID:???

しかし、商業化すると更に鯖負担が増すという罠（ｗ

372 ：謎の”管理”人（ｗ ：02/03/25 03:54 ID:???

>371
そしたらまた考えれ
商業化するならそれくらいは悩まないとねぇ（ｗ
まぁ無料奉仕の限界って事じゃね？

373 ：ななむす ◆nnmm.69A ：02/03/25 03:54 ID:???

>>370
bbs.cgi せっかく部分ごとに{}囲んでるのだから、もっともっとnextとかlastとか
駆使してBLOCKオーバーヘッドと変数放り込みループ削るだけでもだいぶ(以下略

374 ：名無しさん＠お腹いっぱい。 ：02/03/25 03:55 ID:???

>>370
100円じゃおそらく認証等の費用で足が出るんでわ

375 ：Dream ★ ：02/03/25 03:57 ID:???

>>373
bbs.cgiってmod_perl出来たら、どのくらい負荷が軽減すると思います？

376 ：謎の”管理”人（ｗ ：02/03/25 03:57 ID:???

>374
100円ってのは根拠のない例えです。
実際何人の人が２ちゃｎ見てるかもわからねーし。
でもそれくらいなら払えるじゃん？
それだけの事（ｗ

377 ：夜勤 ★ ：02/03/25 03:59 ID:???

>>373
それを　たった今　トオルさんと二人でやっているとこだったりして、

378 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 04:01 ID:???

>>377
がんがれ！

379 ：謎の”管理”人（ｗ ：02/03/25 04:02 ID:???

>夜勤
がんばって！
俺の言いたいこと言ったんで、
あとは管理者に任せます。
でも２ちゃんのこのみんなで協力ってのはいいよねぇ
影ながら応援しています(^^ゞ

380 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 04:03 ID:???

>>375
mod_perlって、コンパイル時にメモリに常駐しちゃう奴だっけ？
実際にこれで動いてるシステムってあるのかなぁ？

381 ：名無しさん＠お腹いっぱい。 ：02/03/25 04:03 ID:???

>>307
subject.txtを隠すとどこにどんなメリットがあるのかさっぱりわからん。
ていうか隠せるのか？

382 ：ななむす ◆nnmm.69A ：02/03/25 04:07 ID:???

>>375
実は mod_perl あまりよくわからないのん(ちょっと怖いという印象が)。

>>377
実は昨日ひとり寂しくやりました。
DispError(...) if ...;
系の文章がすごく多くなりましたよ。えぇ(笑

できるだけ複合文使わないよーにね、ってお伝えください。

383 ：Dream ★ ：02/03/25 04:12 ID:???

>>381
一つには、これ使ってクラッカーがランダムにスレッドを目標に設定して
荒らしている、ということがあるようです。
隠せるか？ということでは「やり方はあります」という程度です。
それはBasic認証でツールが直に要求して、という方法もあるし。

＃盗むの簡単、なりすます野簡単だよ？ということになるかも知れませんが、
＃それは通信法の適用範囲になるでしょう。きっと。

384 ：Dream ★ ：02/03/25 04:13 ID:???

>>382
毎回コンパイルしなくなる、という点で、ちょっともしかしたら
劇的な効果があるんじゃないかって思ってるんですけど、
副作用について、私もよくわかりません。

385 ：夜勤 ★ ：02/03/25 04:16 ID:???

bbs.cgi の負荷軽減と　gzip 圧縮の話しだけど、
今は　bbs.cgi で書き込まれたら
gzip を　peral から二回呼び出しているのよね

CAll gzip index.html
CAll gzip subback.html
subject.txt は、　mod_gzip の方でやっている

でこれを　index.html subback.html subject.txt を一気に
index.html.gz subback.html.gz subject.txt.gz にするスクリプトを C で書いて
bbs.cgi からは一発で呼び出したら、軽くなるかな?

386 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 04:16 ID:???

>>384
bbs.cgiをC言語で書くというのはがいしゅつ？
どっかにCGI用のライブラリとか転がってないかな？

387 ：名無しさん＠お腹いっぱい。 ：02/03/25 04:17 ID:???

>383
subject隠したらsubbackを読むようになるだけだから
転送量が増える分だけ２ちゃんねる側の損じゃん。

388 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 04:17 ID:???

あ、微妙に夜勤★さんとｶﾌﾞﾀ（ｗ

389 ：ななむす ◆nnmm.69A ：02/03/25 04:17 ID:???

>>384
その通りで、効果があるとは思うのですが、いい噂を聞かないというか、何というか。。。
（とりあえず夜勤さんマターだからおまかせ、ってこともあり）

390 ：夜勤 ★ ：02/03/25 04:19 ID:???

>>386
C で書いてもいいんですけどね、
ただ　規制とかの機動性がなくなっちゃうんですよね
いろいろな人が臨機応変に触れなくなるという罠。

391 ：Dream ★ ：02/03/25 04:20 ID:???

>>387
むずかしいもんですねぇ。。。

392 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 04:20 ID:???

>>390
なるほど。

>>391
同感・・・

393 ：ななむす ◆nnmm.69A ：02/03/25 04:21 ID:???

>>385
軽くなると思いますー。
。。。でも微妙かも。なんかオーバーヘッドが気になる。

>>386 >>390
やりたいですね(笑
いつも、さっぱりきっぱりトオルさんに遠慮されてしまいます。
>>387
！

394 ：Dream ★ ：02/03/25 04:23 ID:???

>>385
ソースを見ていないので私にはbbs.cgiのことはわからないのですが、
cgi内部からあえて子プロセス使うのは、どうかなって思います。
(実際は、Ｃコードがどれだけ最適化・効率化されているのか？といった点で変わると思います)

395 ：ななむす ◆nnmm.69A ：02/03/25 04:28 ID:???

gzip + gzip + mod_gzip
->
子プロセス + zlib*3

やっぱり、確実に早くはなると思うが、、、といったとこかな。

396 ：夜勤 ★ ：02/03/25 04:29 ID:???

main()
{
char bbs[] ; // command line から 板名をとる
/*bbs を　test/ からの相対パスにする (../bbs)*/
zz_gzip(bbs,"index.html","index.html.gz");
zz_gzip(bbs,"subback.html","subback.html.gz");
zz_gzip(bbs,"subject.txt","subject.txt.gz");
}

で動くコード誰か書いてー
実験すね価値はあるような予感。

397 ：Dream ★ ：02/03/25 04:29 ID:???

>>393
軽くなりますかねぇ？
Perlのルーチン効率化して、その上で、サーバの負荷的な面で考えてどうなんでしょう？

398 ：Dream ★ ：02/03/25 04:30 ID:???

>>396
そうですね。やっぱり試してみないとわからないところです。

399 ：Dream ★ ：02/03/25 04:32 ID:???

夜勤さん、トオルさん的には、もうsubject.txtは
隠す必要はなくなったのでしょうか？
＞クラッキング対策としての要望というか。

400 ：夜勤 ★ ：02/03/25 04:35 ID:???

攻撃受けたときの事を考えると
隠したいですけど　>>399

401 ：名無しさん＠お腹いっぱい。 ：02/03/25 04:39 ID:???

subject隠したらsubback・・・

402 ：ななむす ◆nnmm.69A ：02/03/25 04:40 ID:???

>>395
ファイルオープンの負荷とかわすれてた。。。

なーんか
http://www.hoops.ne.jp/~yk2yk2/mn/perl/gzipctl.pl
こういう方向性を考えてしまう。

# せっかく index.html も subback.html も subject.txt も bbs.cgi が
# 内部生成してるんだから、ストリーム的に圧縮した方が、と。

403 ：夜勤 ★ ：02/03/25 04:42 ID:???

めんどくささの問題と変更しても良いかどうかの問題で

subject.txt は形式、名前かえたら　大変なことになるけど、

subback.html は、名前変えようが、中身変えようが
自由自在なわけで、

404 ：Dream ★ ：02/03/25 04:42 ID:???

>>402
うん。そう思うところはあります。
Ｃで呼び出すと、Ｃが子プロセスになって、その孫プロセスで圧縮するわけですよね？
しかも、データを標準出力で受け渡して。
だったら、Perl内部で完結した方が、負荷は少ないような気がします。

405 ：ななむす ◆nnmm.69A ：02/03/25 04:45 ID:???

>>404
両方作ってテスト、ですかね。。。。

406 ：名無しさん＠お腹いっぱい。 ：02/03/25 04:45 ID:???

subbackは変幻自在なノカー！

407 ：夜勤 ★ ：02/03/25 04:45 ID:???

なんか雪降ってるですか。。。
除雪車が動き回っているぞー

408 ：Dream ★ ：02/03/25 04:47 ID:???

>>405
そうしないとわかんないですね(笑)
プロセスプロセスいっても、一瞬で終わるかも知れないし。

sub do_gzipとか作って、
&do_gzip("$data");
とかでルーチン内でやっちゃうっていうのは、けっこうPerlではよくある話なんですけど。

409 ：名無しさん＠お腹いっぱい。 ：02/03/25 04:47 ID:???

札幌は降ってるノカー？
北見は降ってないじゃないカー。

410 ：夜勤 ★ ：02/03/25 04:52 ID:???

現状を報告しますと

index.html , subback.html は bbs.cgi 内で
投稿があるたびに以下が行われるです。

system("gzip -c $INDEXFILE > $INDEXGZFILE");
system("gzip -c $SUBFILE > $SUBGZFILE");

subject.txt は、クライアントからリクエストされるたびに
mod_gzip が動いているはず。

411 ：Dream ★ ：02/03/25 04:57 ID:???

>>382
ななむすさんって、bbs.cgi見られる人だったのですか？

412 ：試してないよ ：02/03/25 05:01 ID:???

#include <stdio.h>
#include <sys/mman.h>
#include <zlib.h>
#ifndef MAP_FAILED
#define MAP_FAILED (void *)(-1)
#endif
#defineCOMPRESS_FLAG"wb6"/* wb1-wb9 */
void compress_one(const char *fname)
{
　int fd;
　void *buf;
　int fd = open(fname, O_RDONLY);
　if (fd >= 0) {
　　struct stat st;
　　if (fstat(fd, &st) == 0) {
　　　buf = (char *)mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
　　　if (buf != MAP_FAILED) {
　　　　char gzname[256];
　　　　sprintf(gzname, "%s.gz", fname);
　　　　gzFile file = gzopen(gzname, COMPRESS_FLAG);
　　　　if (file) {
　　　　　gzwrite(file, buf, st.st_size);
　　　　　gzclose(file);
　　　　}
　　　　munmap(buf, st.st_size);
　　　}
　　}
　　close(fd);
　}
}
void compress(const char *bbs, const char *fname)
{
　char fnbuf[256];
　sprintf(fnbuf, "%200s/%30s", bbs, fname);
　compress_one(fnbuf);
}
int main(int ac, char **av)
{
　if (++av, --ac) {
　　compress(*av, "index.html");
　　compress(*av, "subback.html");
　　compress(*av, "subject.txt");
　}
　return 0;
}

413 ：ななむす ◆nnmm.69A ：02/03/25 05:01 ID:???

新聞見てニ速＋へ。社会から遠くにいた今日一日だったのだなぁ。。。

>>410
少なくとも $INDEXFILE 作成 → $INDEXFILE open → $INDEXGZFILE
よりは、$INDEXGZFILE も $INDEXFILE と同時に作る方法が軽いと思います。

。。。が、今日は寝るです。仕事どうしよう。寝れるのかなヽ（´ー｀）ﾉ
皆さんお疲れさまでした。

>>411
見られないですよー。
こちらからはいくらでも公開しちゃうのだけど(笑
４種くらい手持ちのを見つつ、想像しつつ、です。

414 ：Dream ★ ：02/03/25 05:02 ID:???

>>413
お休みなさいです〜

415 ：試してないよ ：02/03/25 05:03 ID:???

ちょっと見ただけでも
　sprintf(fnbuf, "%.200s/%.30s", bbs, fname);
とか、ぼろぼろだ

416 ：ななむす ◆nnmm.69A ：02/03/25 05:03 ID:???

>>412
!! お疲れさまですです。

417 ：AJA6H/Ws ◆MPnX7dHA ：02/03/25 05:03 ID:???

>>413
乙〜〜！

418 ：Dream ★ ：02/03/25 05:05 ID:???

>>410
system("gzip -c $INDEXFILE > $INDEXGZFILE");
と
`gzip -c $INDEXFILE > $INDEXGZFILE"`;
と、どちらが負荷が少ないのかなぁ？と思いましたが、どちらも大して違わないかも知れません。
さらにいいますと、その内容であれば、Ｃで別プロセスに任せるより、そのままの方がよいと思います。

419 ：名無しさん＠お腹いっぱい。 ：02/03/25 05:10 ID:???

kage.exe　Version０．９９．１．６に。

420 ：Dream ★ ：02/03/25 05:16 ID:???

sub do_gzip [ `gzip -c $_[0] > $_[1]`; }
として、&do_gzip("$INDEXFILE","$INDEXGZFILE");
等という呼び出し方をすれば、若干スクリプトが効率化するかも知れませんね。

余談ですいませんでした。

421 ：名無しさん＠お腹いっぱい。 ：02/03/25 05:21 ID:???

おお。かちゅ〜しゃの巡回ボタンが更新チェックになっとる。

422 ：名無しさん＠お腹いっぱい。 ：02/03/25 05:51 ID:???

動作確認した。圧縮率は外からも指定可。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <ctype.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <zlib.h>
#ifndef MAP_FAILED
#define MAP_FAILED (void *)(-1)
#endif
char compress_flag[30];
void compress_one(const char *fname)
{
　int fd;
　void *buf;
　fd = open(fname, O_RDONLY);
　if (fd >= 0) {
　　struct stat st;
　　if (fstat(fd, &st) == 0) {
　　　buf = (char *)mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
　　　if (buf != MAP_FAILED) {
　　　　char gzname[256];
　　　　gzFile file;
　　　　sprintf(gzname, "%s.gz", fname);
　　　　file = gzopen(gzname, compress_flag);
　　　　if (file) {
　　　　　gzwrite(file, buf, st.st_size);
　　　　　gzclose(file);
　　　　}
　　　　munmap(buf, st.st_size);
　　　}
　　}
　　close(fd);
　}
}
void compress_file(const char *bbs, const char *fname)
{
　char fnbuf[256];
　sprintf(fnbuf, "%.200s/%.30s", bbs, fname);
　compress_one(fnbuf);
}
int main(int ac, char **av)
{
　int mode = 6;
　++av, --ac;
　if (ac == 2 && isdigit(*av[1])) {
　　mode = atoi(av[1]);
　　--ac;
　}
　sprintf(compress_flag, "wb%d", mode);
　if (ac == 1) {
　　compress_file(*av, "index.html");
　　compress_file(*av, "subback.html");
　　compress_file(*av, "subject.txt");
　}
　return 0;
}

423 ：名無しさん＠お腹いっぱい。 ：02/03/25 06:03 ID:???

bbs.cgi内部で圧縮するのが一番いいのは確かだけど
Zlib入ってるのかな？
MD5とかも入ってなくて(^_^;)が苦労してたような。
include/に、zlib.hもなかったし。

424 ：名有りさん＠お腹へった ◆fSunOs.U ：02/03/25 06:09 ID:???

何かこんな時間に......乙カレーです．

ところで，こういうの使えばfork()せずに済むかと．
http://cpan.org/modules/by-category/17_Archiving_and_Compression/Compress/Compress-Zlib-1.16.readme
http://cpan.org/modules/by-category/17_Archiving_and_Compression/Compress/Compress-Zlib-1.16.tar.gz

fork()してＣのプログラム使うのなら，daemonizeして非同期実行させた上で，
５秒ぐらい待ってその間に発生した圧縮処理を１つにまとめてしまうのも考えかと．

fd = open(CHKFILE, O_WRONLY|O_CREAT|O_EXCL, 0700);
if (fd == -1) return;
sleep(5);
unlink(CHKFILE);
/* 処理続行 */

283KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30