>>150
＞どういう対策
何に対する対策？

>>150
>protectorでDoSはある程度防げるとして
激しく間違い
勉強しなおしてこい

>>152
protectorの機能としてF5アタックなどのDoSのための機能があるのですが
それでも「ある程度防げる」とは言えないのですか?

激しく間違っている理由を教えてもらえないでしょうか?

>>151
負荷対策

>>154
じゃあ、如何に人気のないサイト(コンテンツ)を構築するか
その手腕にかかってるな。

人気があれば、やっぱ人は多く訪ねてくるわけだし
チューニングに拘るよりも、その人気をどうにかして
ハードの投資に転化できるかとかそっちの方法を
考えた方が良いんじゃないかね。DoS対策とかは別だが。

>>153
httpdはDoSを受けるので防げるとは言えない

同じIPからのF5攻撃をPHPで防ぐというのは
そもそもリクエストを受信して、無視するか処理するかを判断してるわけで
大量のF5が来たら捌ききれなくなるのは同じ

落ちにくくなるって意味では、「ある程度防げる」でもよくね？

そのくらいの言い回しが通用するならそれでもいいんじゃね

>>158
>落ちにくくなるって意味では、「ある程度防げる」でもよくね？
httpdはリクエストを受け続けるんだから別に落ちにくくなったりしない

iptableでやったほうがよっぽど有効

自前でサーバ持ってない奴の保険じゃないのか、Protectorは。

っで、結局のところ負荷対策は、XOOPSを使わないつうことでOK?

負荷対策の定義もできねえくせに何言ってんだか。。
携帯対応の僕ちゃんと同レベル。

>>161
米兵もAnti-DoSはオマケって認識だし、リクエストフィルタなんかもそうだと思うが
その辺は共有レンタルサーバで運用している人向け。
ただXOOPSに特化した部分も結構あるので、専用サーバの人も
オマケの部分はもっと上の層で対策し、特化してる部分はProtectorでカバーすべき。
まあ専用サーバで商業的運用するなら、根本的に使うモジュールを吟味し
危ないところは修正したりも大事だけどね。

F5 attackしていて処理を中断され真っ白画面になったら
アホな攻撃者は落ちたかと思ってattackをやめたら「ある程度防げる」と
言えるのでは

ハサミが取れるカニみたいなもんか

>>164
おおむね同意だな
商用で使うなら、プロテクター要らないレベルまで
コード検証しろって思うがな

>>165
真っ白で落ちたかもって池沼だろ
そんなのちっとも「ある程度」じゃないだろ
てかアタック掛けるのにブラウザでF5する奴なんて厨房以下だろ

XOOPSはF5すると落ちるといって公式サイトもそうなのかと思って
F5アタックした香具師が実際にいたという事実について

>>168
ユーザに池沼が結構いるという事実の立証。

>>168
本人？

本人なわけない
onokazuに止めて下さいと書かれていたよ

米兵　where are you ?

うちはDay/30万Hitだけどなんとかなってる。
レンサバの人に頼んでチューニングしてもらったんでどんな構成かは分かんないけど。

>>173
自社サーバなの？
スペック教えてくれ、それと回線も、ヨロシコ

ところで、XOOPSの負荷低減にAPCとかPHPアクセラレーター系って効果あんの？
つうか、負荷とか考えるならXOOPSなんか使うなが、正解か。

逆数な件

XOOPSのデフォルトテーマ・モジュールナッシング状態でベンチ（環境は前回と同じx86_64）
$ ab -n 100 -c 10http://www.hoge.net/ （同時10接続の100リクエスト）
Benchmarking www.hoge.net (be patient).....done
Server Software: Apache
Server Hostname: www.hoge.net
Server Port: 80

Document Path: /
Document Length: 4074 bytes ←XOOPSデフォルトでモジュールなし状態

Concurrency Level: 10　←一度に１０の同時接続数
Time taken for tests: 6.855289 seconds
Complete requests: 100　←完了リクエスト
Failed requests: 70　←失敗数　orz
(Connect: 0, Length: 70, Exceptions: 0)
Write errors: 0
Total transferred: 473228 bytes
HTML transferred: 429128 bytes
Requests per second: 14.59 [#/sec] (mean) ←処理数/秒
Time per request: 685.529 [ms] (mean)
Time per request: 68.553 [ms] (mean, across all concurrent requests)
Transfer rate: 67.39 [Kbytes/sec] received

普通の性的？なHP（金髪ｵﾈｲﾀｿのGIFやJPG映像満載ページ）
$ ab -n 100 -c 10http://www.hoge.jp/
Server Software: Apache
Server Hostname: www.hoge.jp
Server Port: 80

Document Path: /
Document Length: 17120 bytes　←GIF満載のスタティックなNowでYoungなページ

Concurrency Level: 10　←一度の接続数は１０
Time taken for tests: 1.743968 seconds
Complete requests: 100　←リクエスト完了数
Failed requests: 0　←リクエストエラー無し！
Write errors: 0
Total transferred: 1736300 bytes
HTML transferred: 1712000 bytes
Requests per second: 57.34 [#/sec] (mean)　←処理数/秒
Time per request: 174.397 [ms] (mean)
Time per request: 17.440 [ms] (mean, across all concurrent requests)
Transfer rate: 971.92 [Kbytes/sec] received

つうことで、漏れの糞なサーバでは偉大なXOOPS様はムリポ！

乙です

･･･透明あぼーんさせていただきますた(やべー)

>>177
> XOOPSのデフォルトテーマ・モジュールナッシング状態でベンチ（環境は前回と同じx86_64）

ベンチマーク乙!
前回と同じってどの環境?

今売り出し中、複数ブログ作成CMSのニュークリアス登場！（テスト環境は同じ）
各CMSは、単にディレクトリにｲﾝｽｺしたままのデフォルト状態。
$ ab -n 100 -c 10http://www.hoge.jp/nucleus/
Benchmarking www.hoge.jp (be patient).....done
Server Software: Apache
Server Hostname: www.hoge.jp
Server Port: 80

Document Path: /nucleus/
Document Length: 7825 bytes　←XOOPSデフォルトよりでかいね

Concurrency Level: 10
Time taken for tests: 4.447131 seconds
Complete requests: 100
Failed requests: 0　←グッド！
Write errors: 0
Total transferred: 811100 bytes
HTML transferred: 782500 bytes
Requests per second: 22.49 [#/sec] (mean)　←そこそこの数字だね。
Time per request: 444.713 [ms] (mean)
Time per request: 44.471 [ms] (mean, across all concurrent requests)
Transfer rate: 178.09 [Kbytes/sec] received

CMS界の両雄でも、枝分かれしちゃったのね、残念！（テスト環境同じ）
$ ab -n 100 -c 10http://www.hoge.jp/mambo/
Benchmarking www.hoge.jp (be patient).....done
Server Software: Apache
Server Hostname: www.hoge.jp
Server Port: 80

Document Path: /mambo/
Document Length: 20241 bytes　←XOOPSデフォルトより糞でかいね

Concurrency Level: 10
Time taken for tests: 9.751595 seconds
Complete requests: 100
Failed requests: 83　←ここも凄い、XOOPSを超えた！
(Connect: 0, Length: 83, Exceptions: 0)
Write errors: 0
Total transferred: 2078663 bytes
HTML transferred: 2033617 bytes
Requests per second: 10.25 [#/sec] (mean) ←ちょいと厳しい数字だね。
Time per request: 975.159 [ms] (mean)
Time per request: 97.516 [ms] (mean, across all concurrent requests)
Transfer rate: 208.07 [Kbytes/sec] received

以上、各CMSをベンチ下結果、マンボが一番処理が重い！

テスト環境

テスト機　Xeon3.20GHz×１　メモリ＝１GB　DDR2/400MHz SDRAM　HDD＝SATA 6Ch　RAID5　
OS＝Linux　CentOS4.1　x86_64

回線　Bフレッツベーシック　固定IP

テストでは、インターネットで外部よりテスト機サーバに接続しベンチテストを実施いたしますた。

>>183のCMSは、説明するまでもないけどmamboでつ。

そもそもこれは猿が５分で使えるってものだろ？
webベースのCMSなんて目くそ鼻くそ。

>>174
スペックは公開されてないから分かりません、聞いたら教えてくれるだろうけど
サーバーは再販ではなく自社サーバー、回線はFTTH（フレッツ）らしいです。

> 同時10接続の100リクエスト
さぁこの負荷をどうみるのかっ

ベンチの結果おもろいね
ZOOPのPloneはどうよ？

>>188
つうか、> 同時10接続の100リクエスト は大杉！

つまりnucleusはオーバースペックw

リクエストの成否（Complete requestsとFailed requests）
abで発生させたリクエストがすべて成功していればいいが、一部が失敗するようならWebサーバの処理が追い付いていない。
これは、特にプログラムを実行してページを生成する場合に起こりやすく、同時接続数の限界を超えていると考えるべきだろう。
http://www.atmarkit.co.jp/flinux/rensai/apache15/apache15b.html

・アクセス先htmlファイル
　Document Path:　　　　　/*****/
・アクセス先ファイル容量
　Document Length:　　　　******* bytes
・送信リクエスト数
　Concurrency Level:　　　10
・リクエスト完了までの所要時間
　Time taken for tests:　 29.254 seconds
・総リクエスト数
　Complete requests:　　　100
・取りこぼしたリクエスト数
　Failed requests:　　　　****
・1秒あたりに処理されたリクエスト数
　Requests per second:　　*.** [#/sec] (mean)
・1秒あたりに処理された所要時間
　Time per request:　　　 *****.** [ms] (mean)
・1秒あたりに受信された容量
　Transfer rate:　　　 ****.** [Kbytes/sec] received
http://www.itmedia.co.jp/help/tips/linux/l0500.html

>>182
MySQLの設定ｷﾎﾞﾇ

>>193
ちと１GBメモリでは、他も遣ってますので出すぎの設定と思われますが。
mysql-4.1.10a-2.RHEL4.1
まんまコンフをコピペすます。
# The MySQL server
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

>>194
ありが㌧

もちっと煮詰めると、また変わった結果になるかもだね

>>175
効果はあるにはあるんだが、一般的なPHPプログラムのように
劇的な効果は多くの場合ない(経験)。XOOPSしか使ってないなら使わない方がいいと思う。
PHPAとZend Optimizerの２つしか試してないが。

米兵のサイトか本でもアクセラレータ系の検証をしていたと記憶する。
探してみな。

zend optimizerって結構な値段するのにそんな効果ないのか
その金でメモリーでも買った方がましなのかな

PHPAはタダで配布されていて、Yahoo.com(USA)で使われてる実績ありんす。
APCてのもあって、これもタダで配布されてます。
両方とも、同じような構造で/tmp以下にキャッシュを置くタイプ。
但し、両方とも32bit版までしかない。
XOOPSでは両方とも試したが、殆ど実感できないくらいだった。orz

レンタル鯖で運用されてる不人気XOOPSサイトなんか、間違ってアクセスしちゃうと
忘れたころに表示される。
負荷分散の話以前に、起動すら重過ぎる。（笑

>>197
PHPAとZend Optimizerは両方とも無料だよ。
レンタルサーバだと後者が入ってるところが多いから
気が付かないうちに使ってる人も多い。それでアクセラレータによる
不具合に気が付かないで悩んでる人も...

結構な金額なのはZendの開発環境から運用まで統合されてる
Zend Performance Suiteの方でしょ。

やむなくXOOPSを使わなければならない場合のサーバ仕様
OS　Linuxの適当なの（x86_64)
CPU　AMDあたりでマルチ（x86_64)
メモリ　２GB以上を強く推奨
HDD　適当に
備考：将来MySQL鯖とローカルで一発接続できるように、事前にNICは２枚挿し。
固定IPで運用してる場合、NIC一枚だとMySQL鯖側にも固定IPないと面倒。
最初から、ローカル側にもNICを準備しておけば即効でMySQL鯖を立てて接続できる。
尚、米兵のプロテクタモジュールはお守りとして、いれとく。
F5厨対策としてIPtableでここ↓のフィルタ使って糞ﾁｮﾝ・品地区は遮断しとく。
http://www.hakusan.tsg.ne.jp/tjkawa/lib/krfilter/index.jsp

こんなところでしょうか？職者の皆様のご意見を賜れば、幸いにございます。