XOOPS 8

**nobodyさん** · 2005/07/20(水) 19:52:34

XOOPS Official Site
http://www.xoops.org/
XOOPS Cube 日本公式サイト
http://jp.xoops.org/
xoops wiki（初心者用のFAQから技術情報まで、XOOPS情報の宝庫）
http://xoops.sourceforge.jp/wiki/
XoopsDocument ドキュメント
http://xoops.riaf.org/

過去スレ
XOOPS
http://pc2.2ch.net/test/read.cgi/php/1031736248/
XOOPS 2
http://pc5.2ch.net/test/read.cgi/php/1067311026/
XOOPS　3
http://pc5.2ch.net/test/read.cgi/php/1081855254/
xoopsスレ 4
http://pc5.2ch.net/test/read.cgi/php/1092151787/
XOOPS 5
http://pc5.2ch.net/test/read.cgi/php/1106563315/
XOOPS 6
http://pc8.2ch.net/test/read.cgi/php/1111233328/
XOOPS 7
http://pc8.2ch.net/test/read.cgi/php/1117665347/

**nobodyさん** · 2005/09/06(火) 08:40:50

バージョンって数さえ上がってればいいのか？（藁
じゃ、cube（3)になったらこっちの勝ちだな（藁

**nobodyさん** · 2005/09/06(火) 09:18:00

>>100
全く的外れ

本家は別にアメリカではない
英語をしゃべっている人を見ると全部アメリカ人だと思うタイプだろ

**nobodyさん** · 2005/09/06(火) 10:00:20

池沼ども、すっこんでろ
もうそのネタ飽きたんだyo
やりたきゃCubuスレでやってくれ

**nobodyさん** · 2005/09/06(火) 14:26:27

っで、XOOOPS2.2.3はどうでつか！

**nobodyさん** · 2005/09/07(水) 00:53:26

>>102が無知を指摘しちゃったから>>103が興奮しちゃった図

**nobodyさん** · 2005/09/07(水) 19:44:43

つうか、このスレって池沼のすくつだな　ゲラゲラゲラ

**nobodyさん** · 2005/09/08(木) 01:34:30

>>106
その筆頭だな

**nobodyさん** · 2005/09/09(金) 23:57:52

PCのスペックによっても変わってくると思いますが、AMD64　X2で
どれぐらいのアクセス数に耐えれますか？
一日のアクセス数が15万ぐらいまでは無理でしょうか？
メモリは２Gで、HDDはウエスタンデジタルのraptorを考えております。

**nobodyさん** · 2005/09/10(土) 00:14:00

どんなのを目指してるのか知らないけど、
15万hitなら回線が持たないと思われ。
まさか1G回線？？ええのぅ・・・

**nobodyさん** · 2005/09/10(土) 00:25:48

>>109
回線は、置いといて、
サーバー的に限界がありますか？
ネタでサーバー一台だけで、無料レンタルとかしたらどうなるのかと
実験しようと思ってます。
ご意見きかせていただければ幸いです。

**nobodyさん** · 2005/09/10(土) 00:41:38

>>110
ごめん。でしゃばった。
役に立つかはわからないけど、過去の経験。
一日1万hitの携帯（写メ投稿）サイトを管理したことあるけど、
シングルのPenIV2.0Gだった。
特に重いとは思わなかった。
他のスペックは知らない。

今一日120hitの寒いサイト運営してて、
PenIV2.4Gのメモリは512で常に100％なのに全然軽い。
Linuxは覚えたてだけど、
Linuxのswapの管理がwindowsより優秀なのかな？よくわからん。

参考にならんか・・・

**nobodyさん** · 2005/09/10(土) 00:44:17

>>110
他の自宅サーバ無料HPサービスみたいに
きちんと「実験です」と銘打って運営してみれば？
それで文句言うやつは有料サーバ使え！って感じで。

**nobodyさん** · 2005/09/10(土) 00:46:41

>>111
>>112
そのつもりなのですが、あまりに処理量が少ないと問題とおもいまして。
XOOPSのボトルネックってどこですか？
経験上あれば教えていただければ幸いです。

**nobodyさん** · 2005/09/10(土) 00:54:56

ボトルネックはPHPそのもの。
コンテンツ増えればそれだけ表示遅くなる。（コンテンツの数だけ処理する必要がある。）
モジュールの数も増えれば表示が遅くなる。
バナー増えても表示遅くなる。（特にflashバナーが重いと思う。（個人的見解））
mywikiや@wikiの感覚でxoopsレンタルやるのは無謀番町だと思う。

自鯖にwikiおいて編集してみた後に、
mywikiや@wikiのページでアカウントとって編集してみれば何言ってるのかわかると思う。

**nobodyさん** · 2005/09/10(土) 00:58:15

@wikiにアカウント取らなくても、よくわかってるつもりなんですが･･･。

PHPよりMYSQLのDBあたりが先にきませんか？

**nobodyさん** · 2005/09/10(土) 01:01:57

>>115
スマン。
MySQLで15万hitは想像つかない。
でも、xoopsの場合かかわってくるものが多いから、SQLの処理よりPHPの処理の方がボトルネックになると思う。

あぁ、酔ってるからおいさんの世迷言と思ってね。
まことにスマン。

**nobodyさん** · 2005/09/10(土) 02:25:01

>>108
15万ヒットが1日まんべんなく分散してるなら全然へっちゃらですよ。
普通は分散しないから設計が難しい。

**nobodyさん** · 2005/09/10(土) 03:20:14

DBサーバは分けないの?

**nobodyさん** · 2005/09/10(土) 06:23:49

まずはMRTGで負荷しばらく記録して様子みとけ

**nobodyさん** · 2005/09/10(土) 10:29:05

>>118
分散も考えましたが、ネットワーク経由になると
そのあたりがボトルネックになりませんか？

**nobodyさん** · 2005/09/10(土) 10:43:30

LAN内の100M or 1G のトラフィックより、CPU負荷とかストレージの負荷の方が重要
DBの速度はストレージへの読み書き速度に依存する部分が一番大きい

**nobodyさん** · 2005/09/10(土) 12:48:34

どこまで、リアルタイムに更新する必要があるかだけど
XOOPSの手前に串立てとけば？

**nobodyさん** · 2005/09/10(土) 13:45:24

>>120
普通分けた方が早くなるでしょ
もっというならWebサーバも分散すればもっと負荷分散できる

それより環境によってどこがボトルネックかなんて違うわけだから
なんとも言えないでしょ

OS,Apache,PHP,Mysqlのチューニングの仕方によってもかなり違うだろうし

**nobodyさん** · 2005/09/10(土) 14:38:03

まぁ、もう>>108は話についてこれてないと思われ

**nobodyさん** · 2005/09/10(土) 14:58:39

サーバーモンキー増産中

**nobodyさん** · 2005/09/10(土) 15:07:56

とりあえずお前らが素人ぞろいなのはわかった。
客にそんな説明したらぶっとばされるよ。

**nobodyさん** · 2005/09/10(土) 15:48:52

客かそうでないか見極めるのがプロ。

**nobodyさん** · 2005/09/10(土) 15:49:43

客がそんだけ分かってるんならこんな状況にはならんだろ

**名無しさん＠そうだ選挙に行こう** · 2005/09/10(土) 20:58:15

>>124
squidかなにかでキャッシュってことっすかね？

**名無しさん＠そうだ選挙に行こう** · 2005/09/10(土) 22:04:27

>>129
124じゃないよｗ
そんなにリアルタイムの更新ないなら
入り口に烏賊でも何でも串立てて、
その後ろにロードバランサ突っ込んで動かせば？

ってか解んないなら、それなりのとこ頼んだ方がいいよ
Apache,MySQL他も適切にチューニングしないと意味ないし

**名無しさん＠そうだ選挙に行こう** · 2005/09/10(土) 22:14:28

>>130
チューニング関係はなんとかいけそうと思う。
まあ一台に突っ込んでどこまでできるかってのが条件だったりします。
リアルタイム更新で何とかできればな・・・。

**名無しさん＠そうだ選挙に行こう** · 2005/09/10(土) 23:08:44

>>131
>まあ一台に突っ込んでどこまでできるかってのが条件
俺ならXOOPS使わないか、思いっきりハックする

**名無しさん＠そうだ選挙に行こう** · 2005/09/11(日) 03:26:29

>>131
WebサーバとDBサーバを分けるだけなら後からでも簡単にできるから
予想がつかなくてビジネス的にもシビアじゃないなら(実際そうなんでしょ)
1台でいいよ。複数のWebサーバと複数のDBサーバでというなら話は変わってくるが。

**名無しさん＠そうだ選挙に行こう** · 2005/09/11(日) 11:13:25

>一台に突っ込んでどこまでできるか
なら最初に現実的なボトルネックを探す手段を考えるべき
HDDのスペック変えるとかをチューニングとして考えてるのであれば面白いことになりそうだけど

HDDなら外部にNetAppを置くと色々と良いよwww

**名無しさん＠そうだ選挙に行こう** · 2005/09/11(日) 14:51:29

>>134
NetAppつかって、どうやって無料で提供できますか？
やり方が思いつきません・・・。

**名無しさん＠そうだ選挙に行こう** · 2005/09/11(日) 16:08:29

ウホッ、いいマジレス

**名無しさん＠そうだ選挙に行こう** · 2005/09/11(日) 18:01:50

NetAppなんて知らねー

**nobodyさん** · 2005/09/12(月) 00:58:35

>>134
134氏が無料で提供してくれるのでしょうか？

**nobodyさん** · 2005/09/12(月) 20:00:25

うｎ

**nobodyさん** · 2005/09/13(火) 20:22:12

＞一日のアクセス数が15万ぐらいまでは無理でしょうか？
＞メモリは２Gで、HDDはウエスタンデジタルのraptorを考えております。
load average: 0.10, 0.04, 0.01
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2% us, 0.0% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1024892k total, 849256k used, 175636k free, 34292k buffers
Swap: 2031608k total, 1584k used, 2030024k free, 99396k cached

load average: 16.76, 4.41, 1.48
Tasks: 181 total, 1 running, 180 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4% us, 0.1% sy, 0.0% ni, 0.0% id, 98.9% wa, 0.0% hi, 0.6% si
Mem: 1024892k total, 1009128k used, 15764k free, 304k buffers
Swap: 2031608k total, 135448k used, 1896160k free, 38528k cached
テスト機　Xeon3.20GHz×１　メモリ＝１GB　DDR2/400MHz SDRAM　HDD＝SATA 6Ch　RAID5　OS＝Linux　CentOS4.1
１分間XOOPSサイトを立ててF5キー連続押しで、もう～そりゃ大変！
テスト機はBフレッツ固定IP、アクセスは別回線より実施すますた。
（完全なインターネット環境上からテスト実施すますた）
ジーアイ・ジョー氏のプロテクトモジュールは必須だが、それにしてもXOOPSはあれ・・・だ。
基本的に、Apacheサーバを２台。内１台はDNSも持つALLインワンのApache機でオケ！
これがスタティックページ表示用。
もう一台がApache専用機で、こちらはダイナミック専用として、さらにMySQL専用サーバ機を繋げ。
Apacheサーバ２台は、mod_proxyを使って連動。おまけとしてRewriteMapで決め撃ちしとけ。
MySQLサーバは、チューニング用のファイルがMySQLの文書ディレクトリ内にあるから、
それをコピペして使え。メモリ2GB用のがええやろ。これで、15万アクセスはなんとか逝けるやろ。
つうか、そこまでXOOPSにこだわる理由が解からんが、健闘を祈る！

**nobodyさん** · 2005/09/13(火) 20:25:50

上のテストは、当然ジーアイ・ジョー氏のプロテクトモジュールは無しだ罠。

**nobodyさん** · 2005/09/13(火) 20:28:58

load average: 16.76, 4.41, 1.48

F5攻撃でこれだと公表しちゃって大丈夫かいな

**nobodyさん** · 2005/09/13(火) 20:30:50

既知の情報だ罠。
つうか、XOOPSサイトでプロテクトモジュール設定無しは、あれだ罠。w

**nobodyさん** · 2005/09/13(火) 20:31:52

鯖管ならインストール禁止にする可能性もあるな

**nobodyさん** · 2005/09/13(火) 20:32:08

もっとも、実機でローカルでなくインターネット回線を使ったデータは、これが最初かもね。

**nobodyさん** · 2005/09/13(火) 20:34:44

驚くのはCPUのロードアベレージもあれだが。
メモリも凄い！スワップをガンガン喰う。
僅か１分間のテストだったが、これが数分続いたらスワップは食われてまう罠。
Swap: 2031608k total, 1584k used, 2030024k free, 99396k cached
Swap: 2031608k total, 135448k used, 1896160k free, 38528k cached

**nobodyさん** · 2005/09/13(火) 20:35:00

NetAppは冗談だとしてもさ…
マシンスペック結構高目だよな

**nobodyさん** · 2005/09/13(火) 20:47:50

XOOPSで嫌韓系のサイトなんか作ったら一発だな

**nobodyさん** · 2005/09/13(火) 21:05:00

ある意味DoS向けだな
アホかと

**nobodyさん** · 2005/09/13(火) 21:11:23

実際問題XOOPSを使わざるを得ないとしたら
どういう対策をすればいいんだろう

protectorでDoSはある程度防げるとして
ハードのスペックを上げる以外でいい方法はないものか

ボトルネックの調査した香具師いない?
PHPがネックだと言った香具師はどういう理由でそう思ったの?

**nobodyさん** · 2005/09/13(火) 22:57:51

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

**nobodyさん** · 2005/09/14(水) 01:26:29

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

**nobodyさん** · 2005/09/14(水) 02:35:23

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

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

**nobodyさん** · 2005/09/14(水) 02:35:59

>>151
負荷対策

**nobodyさん** · 2005/09/14(水) 05:59:00

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

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

**nobodyさん** · 2005/09/14(水) 07:25:27

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

**nobodyさん** · 2005/09/14(水) 08:57:01

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

**nobodyさん** · 2005/09/14(水) 10:06:50

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

**nobodyさん** · 2005/09/14(水) 10:09:39

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

**nobodyさん** · 2005/09/14(水) 12:37:22

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

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

**nobodyさん** · 2005/09/14(水) 12:39:42

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

**nobodyさん** · 2005/09/14(水) 16:25:07

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

**nobodyさん** · 2005/09/14(水) 18:45:29

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

**nobodyさん** · 2005/09/14(水) 18:53:34

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

**nobodyさん** · 2005/09/14(水) 19:36:50

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

**nobodyさん** · 2005/09/14(水) 19:39:46

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

**nobodyさん** · 2005/09/14(水) 22:09:24

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

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

**nobodyさん** · 2005/09/14(水) 22:26:55

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

**nobodyさん** · 2005/09/14(水) 23:43:01

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

**nobodyさん** · 2005/09/14(水) 23:46:38

>>168
本人？

**nobodyさん** · 2005/09/15(木) 00:44:30

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

**nobodyさん** · 2005/09/15(木) 01:07:33

米兵　where are you ?

**nobodyさん** · 2005/09/15(木) 03:35:33

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

**nobodyさん** · 2005/09/15(木) 09:03:16

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

**nobodyさん** · 2005/09/15(木) 13:19:24

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

**nobodyさん** · 2005/09/15(木) 14:39:13

逆数な件

**140** · 2005/09/15(木) 15:23:10

XOOPSのデフォルトテーマ・モジュールナッシング状態でベンチ（環境は前回と同じx86_64）
$ ab -n 100 -c 10 http://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

**140** · 2005/09/15(木) 15:24:18

普通の性的？なHP（金髪ｵﾈｲﾀｿのGIFやJPG映像満載ページ）
$ ab -n 100 -c 10 http://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

**140** · 2005/09/15(木) 15:25:18

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

**nobodyさん** · 2005/09/15(木) 15:52:11

乙です

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

**nobodyさん** · 2005/09/15(木) 16:33:33

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

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

**140** · 2005/09/15(木) 16:52:25

今売り出し中、複数ブログ作成CMSのニュークリアス登場！（テスト環境は同じ）
各CMSは、単にディレクトリにｲﾝｽｺしたままのデフォルト状態。
$ ab -n 100 -c 10 http://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

**140** · 2005/09/15(木) 16:52:54

CMS界の両雄でも、枝分かれしちゃったのね、残念！（テスト環境同じ）
$ ab -n 100 -c 10 http://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をベンチ下結果、マンボが一番処理が重い！

**140** · 2005/09/15(木) 16:56:04

テスト環境

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

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

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

**140** · 2005/09/15(木) 16:58:56

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

**nobodyさん** · 2005/09/15(木) 17:19:40

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

**nobodyさん** · 2005/09/15(木) 18:06:59

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

**nobodyさん** · 2005/09/15(木) 19:09:14

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

**nobodyさん** · 2005/09/15(木) 19:19:55

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

**nobodyさん** · 2005/09/15(木) 19:21:43

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

**nobodyさん** · 2005/09/15(木) 19:24:50

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

**nobodyさん** · 2005/09/15(木) 19:33:56

リクエストの成否（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

**nobodyさん** · 2005/09/15(木) 19:34:55

>>182
MySQLの設定ｷﾎﾞﾇ

**140** · 2005/09/15(木) 19:45:01

>>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

**nobodyさん** · 2005/09/15(木) 20:47:58

>>194
ありが㌧

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

**nobodyさん** · 2005/09/15(木) 21:34:37

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

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

**nobodyさん** · 2005/09/16(金) 10:39:18

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

**nobodyさん** · 2005/09/16(金) 11:10:11

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

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

**196** · 2005/09/16(金) 11:26:33

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

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

**nobodyさん** · 2005/09/16(金) 15:48:43

やむなく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

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