お世話になっております。
現在、下記環境でMODX Revolutionを使用しているのですが、
MODX経由で処理するものと単純なPHPで処理するを比べると、
MODX経由で処理したものがCPUネックでスループットが出ない状況です。
MODXの性能改善点(チューニングポイントやパラメータ等)について、
ご存じの方いらっしゃいましたらご教授いただけないでしょうか。
また、MODXを使用されているサイト等で100PV以上のスループットを
達成できている事例ございましたら、可能な範囲で情報いただけると幸いです。
どうぞよろしくお願いいたします。
■状況
MODXで動的要素あり(文字のみを出力する)のページ：16PV/secでCPU100%
===============
<html>
<!-- キャッシュ有効 -->
<head>
...
</head>
<body>
[[!DBAccessSnippet_1]]
[[!DBAccessSnippet_2]]
[[!DBAccessSnippet_3]]
[[DBAccessSnippet_4]]
[[DBAccessSnippet_5]]
<body>
</html>
===============
MODXで動的要素なし(文字のみを出力する)のページ：60PV/secでCPU100%
===============
<!DOCTYPE HTML>
<html lang="ja">
<head>
<meta charset="utf-8">
</head>
<body>
<p>性能促成用ページ。(動的要素なしのMODXページ)</p>
</bogy>
</html>
===============
phpで単純な文字のみを表示するページ：1000PV/secを超えるがCPU80%程度
===============
<?php
echo 'Hello';
?>
===============
-----
■HW構成
サーバ：Amazon EC2
インスタンスタイプ：m1.large
CPU:4ECU(2ECU 仮想コア×2)
■SW構成
MODX:MODX Revolution 2.2.6-pl (traditional)
OS:CentOS release 6.3(Final)
apache:2.2.23
MPM:Worker
PHP:5.4.11(phpはapacheのFastCGI(mod_fcgid)でphpを動作)
tomcat:7.0.27
※DBはmysqlの5.5.27-logを使用しております。
-----
MODXの性能改善点について 【解決済み】
Re: MODXの性能改善点について
とりあえず私のわかる範囲でお答えします。
・性能改善点
ありません。
「システム設定」→「エリア:キャッシュ」の中の
「データベースキャッシュを有効」と「DBセッションキャッシュ」
を有効にすることで負荷を軽減できそうですが、質問者様の意図した結果にはならないかと思われます。
・CPU使用率が100%になる
他のCMSとの比較結果(Wordpress等)がないので何ともいえませんが、単純にサーバーの性能が低いからだと考えられます。
別のCMSですが、Amazon EC2での負荷テストが掲載されています。
Magento Enterprise Edition + Amazon EC2の性能のそこ力を知る _ Magento.FLATz.JP
http://magento.flatz.jp/magento-enterpr ... 5%E3%82%8B
どうしてもその環境でCMSを使いたいというのであれば、より低い負荷で動作させられるCMSを使用するべきです。
・MODx Revolutionで100PVを達成しているサイト
公式に明言されてるところは見たことはないです。
本家サイトなら軽く100PV以上達成できてるのではないでしょうか。
MODx本家サイト
http://modx.com/
・性能改善点
ありません。
「システム設定」→「エリア:キャッシュ」の中の
「データベースキャッシュを有効」と「DBセッションキャッシュ」
を有効にすることで負荷を軽減できそうですが、質問者様の意図した結果にはならないかと思われます。
・CPU使用率が100%になる
他のCMSとの比較結果(Wordpress等)がないので何ともいえませんが、単純にサーバーの性能が低いからだと考えられます。
別のCMSですが、Amazon EC2での負荷テストが掲載されています。
Magento Enterprise Edition + Amazon EC2の性能のそこ力を知る _ Magento.FLATz.JP
http://magento.flatz.jp/magento-enterpr ... 5%E3%82%8B
どうしてもその環境でCMSを使いたいというのであれば、より低い負荷で動作させられるCMSを使用するべきです。
・MODx Revolutionで100PVを達成しているサイト
公式に明言されてるところは見たことはないです。
本家サイトなら軽く100PV以上達成できてるのではないでしょうか。
MODx本家サイト
http://modx.com/
Webサイト制作知識のまとめ
http://ws-matome.jp/
http://ws-matome.jp/
Re: MODXの性能改善点について
dokutoku様
お世話になります。
早々にご返信いただきまして誠にありがとうございます。
>・性能改善点
→教えていただきました設定箇所は有効にしておりませんでしたので、試してみたいと思います。
また、MODXのシステム設定は全て確認できておりませんでしたので、横通しで再確認いたします。
>・CPU使用率が100%になる
→チューニング前の初期状態ですと、MODXの動的要素があるページを１アクセスするだけで、
20～25%程度のCPUを消費しておりまして、さすがにCPU使用率が高すぎると感じました。
切り分けていくとMODXを介して処理をすると、CPUが高騰し急にスループットが低下することに気づきました。
ですが、MODXのフォーラムでCPU高騰に関する情報は特に見られませんでしたので、
設定漏れや何かチューニングポイント等があるかと思い、投稿させていただきました。
CMSの変更は諸事情により難しいため、サーバスペックの増強も検討させていただきます。
>・MODx Revolutionで100PVを達成しているサイト
→承知致しました。
確かに本家サイトは100PVを達成できているかもしれません。
よろしくお願いいたします。
お世話になります。
早々にご返信いただきまして誠にありがとうございます。
>・性能改善点
→教えていただきました設定箇所は有効にしておりませんでしたので、試してみたいと思います。
また、MODXのシステム設定は全て確認できておりませんでしたので、横通しで再確認いたします。
>・CPU使用率が100%になる
→チューニング前の初期状態ですと、MODXの動的要素があるページを１アクセスするだけで、
20～25%程度のCPUを消費しておりまして、さすがにCPU使用率が高すぎると感じました。
切り分けていくとMODXを介して処理をすると、CPUが高騰し急にスループットが低下することに気づきました。
ですが、MODXのフォーラムでCPU高騰に関する情報は特に見られませんでしたので、
設定漏れや何かチューニングポイント等があるかと思い、投稿させていただきました。
CMSの変更は諸事情により難しいため、サーバスペックの増強も検討させていただきます。
>・MODx Revolutionで100PVを達成しているサイト
→承知致しました。
確かに本家サイトは100PVを達成できているかもしれません。
よろしくお願いいたします。
Re: MODXの性能改善点について
こんにちは。
コンテンツの内容にもよると思いますが、MODX側のキャッシュ機構を利用したり、cacheliteなんかを使って独自にスニペットの出力をキャッシュしたりと、MODX単体の努力だけで解決するには相当なパワーのサーバが必要になってくるんじゃないでしょうか。
とりあえずMODXインストール直後のページ表示でキャッシュONの状態でベンチマークしてみれば、そこが限界点と言えると思います（後は色々仕組みを入れていけば落ちていく事になりますので）。
私の管理しているサイトでは複数台構成で、フロントにnginx、バックエンドにMODXの構成にして、低価格VPSでも1000PV/s以上は稼げるサイトが幾つかあります(nginxの能力考えれば当たり前ですが）。
常に動的な表示が必要だとなるとこう言う方法はとりづらいですが、そうでないならばMODXに限らずWordPress等でも適当なキャッシュサーバを利用するのが王道ではないかと思います。
以上ご参考になれば幸いです。
コンテンツの内容にもよると思いますが、MODX側のキャッシュ機構を利用したり、cacheliteなんかを使って独自にスニペットの出力をキャッシュしたりと、MODX単体の努力だけで解決するには相当なパワーのサーバが必要になってくるんじゃないでしょうか。
とりあえずMODXインストール直後のページ表示でキャッシュONの状態でベンチマークしてみれば、そこが限界点と言えると思います（後は色々仕組みを入れていけば落ちていく事になりますので）。
私の管理しているサイトでは複数台構成で、フロントにnginx、バックエンドにMODXの構成にして、低価格VPSでも1000PV/s以上は稼げるサイトが幾つかあります(nginxの能力考えれば当たり前ですが）。
常に動的な表示が必要だとなるとこう言う方法はとりづらいですが、そうでないならばMODXに限らずWordPress等でも適当なキャッシュサーバを利用するのが王道ではないかと思います。
以上ご参考になれば幸いです。
Re: MODXの性能改善点について
shobu様
お世話になります。
コメントいただきましてありがとうございます。
>コンテンツの内容にもよると思いますが、MODX側のキャッシュ機構を利用したり、cacheliteなんかを使って独自にスニペットの出力をキャッシュしたりと、
>MODX単体の努力だけで解決するには相当なパワーのサーバが必要になってくるんじゃないでしょうか。
→はい、相当なパワーが必要そうです。
多くの方々から貴重な情報頂戴しまして、MODX Revolutionの解析部分はコストが高いようです。
ですので、キャッシュは有効と考えており、既にSuperCacheというパッケージをお試しで入れておりますが、その他も前向きに検討したいと存じます。
>とりあえずMODXインストール直後のページ表示でキャッシュONの状態でベンチマークしてみれば、そこが限界点と言えると思います
>（後は色々仕組みを入れていけば落ちていく事になりますので）。
→貴重な情報ありがとうございます。
性能評価時の参考にさせていただきます。
>私の管理しているサイトでは複数台構成で、フロントにnginx、バックエンドにMODXの構成にして、低価格VPSでも1000PV/s以上は
>稼げるサイトが幾つかあります(nginxの能力考えれば当たり前ですが）。
>常に動的な表示が必要だとなるとこう言う方法はとりづらいですが、そうでないならばMODXに限らずWordPress等でも適当な
>キャッシュサーバを利用するのが王道ではないかと思います。
→1000PV/s以上は性能的にすごいですね。
仰るとおりかと存じますが、動的な表示が必要なため、引き続き検討させていただきます。
以上、よろしくお願いいたします。
お世話になります。
コメントいただきましてありがとうございます。
>コンテンツの内容にもよると思いますが、MODX側のキャッシュ機構を利用したり、cacheliteなんかを使って独自にスニペットの出力をキャッシュしたりと、
>MODX単体の努力だけで解決するには相当なパワーのサーバが必要になってくるんじゃないでしょうか。
→はい、相当なパワーが必要そうです。
多くの方々から貴重な情報頂戴しまして、MODX Revolutionの解析部分はコストが高いようです。
ですので、キャッシュは有効と考えており、既にSuperCacheというパッケージをお試しで入れておりますが、その他も前向きに検討したいと存じます。
>とりあえずMODXインストール直後のページ表示でキャッシュONの状態でベンチマークしてみれば、そこが限界点と言えると思います
>（後は色々仕組みを入れていけば落ちていく事になりますので）。
→貴重な情報ありがとうございます。
性能評価時の参考にさせていただきます。
>私の管理しているサイトでは複数台構成で、フロントにnginx、バックエンドにMODXの構成にして、低価格VPSでも1000PV/s以上は
>稼げるサイトが幾つかあります(nginxの能力考えれば当たり前ですが）。
>常に動的な表示が必要だとなるとこう言う方法はとりづらいですが、そうでないならばMODXに限らずWordPress等でも適当な
>キャッシュサーバを利用するのが王道ではないかと思います。
→1000PV/s以上は性能的にすごいですね。
仰るとおりかと存じますが、動的な表示が必要なため、引き続き検討させていただきます。
以上、よろしくお願いいたします。
Re: MODXの性能改善点について
ymt さん
EC2のm1.largeで60PV/secというのは、ほぼプレーンな状態での値だと思いますので、単体だとこの辺が限界でしょうね。
あとは、どうしても毎回ページ生成が必要だと言うことならば、私が関与しているメンバーログインのあるサイトですと
・nginxなどのロードバランサの後ろに複数台のMODXを並べて並列性能を稼ぐ。
セッション情報を session sticky またはセッション情報をmemcached等に保持させて、複数台間で共有。mysqlは1台に集約するかクラスタ化。
・完全な静的ページと動的ページでnginxのキャッシュ設定を分け、少しでも生成にかかる負荷を減らす。
・nginxの場合、キャッシュキーにセッションキーその他を含めるなどして、各ユーザログイン毎に別のキャッシュを保持させる。
これで処理の重いページを何度も通る可能性がある場合、いくらかでも負荷を下げることができる（微々たるものですが）。
・nginxのupstreamはey-balancerを利用して1台にCPU数以上の接続をしないようにする（jobの輻輳を避けたいので）。
というようなことはしていますが、メンバーログイン後、色々処理を含めた個別ページのスピードを上げるのは中々難しいですね。
バックエンドにさくらVPS 2G 4台ぐらいまでが最高で、現状のサイトにjmeterなどで試したことがない（一時的に止めてしまうからｗ）ので単体性能からの推測ですが、これでやっと50pv/sぐらいかなぁという感じです。
100万PV/月越えのサイトでも日中で1～2pv/s 程度なので、普通のサイトならば十分すぎると思いますけどね…。
後は運用コストをどれくらい費やせるかで、上を見ようと思えば出来るけど…という感じだと思います。
ご参考になれば幸いです。
EC2のm1.largeで60PV/secというのは、ほぼプレーンな状態での値だと思いますので、単体だとこの辺が限界でしょうね。
あとは、どうしても毎回ページ生成が必要だと言うことならば、私が関与しているメンバーログインのあるサイトですと
・nginxなどのロードバランサの後ろに複数台のMODXを並べて並列性能を稼ぐ。
セッション情報を session sticky またはセッション情報をmemcached等に保持させて、複数台間で共有。mysqlは1台に集約するかクラスタ化。
・完全な静的ページと動的ページでnginxのキャッシュ設定を分け、少しでも生成にかかる負荷を減らす。
・nginxの場合、キャッシュキーにセッションキーその他を含めるなどして、各ユーザログイン毎に別のキャッシュを保持させる。
これで処理の重いページを何度も通る可能性がある場合、いくらかでも負荷を下げることができる（微々たるものですが）。
・nginxのupstreamはey-balancerを利用して1台にCPU数以上の接続をしないようにする（jobの輻輳を避けたいので）。
というようなことはしていますが、メンバーログイン後、色々処理を含めた個別ページのスピードを上げるのは中々難しいですね。
バックエンドにさくらVPS 2G 4台ぐらいまでが最高で、現状のサイトにjmeterなどで試したことがない（一時的に止めてしまうからｗ）ので単体性能からの推測ですが、これでやっと50pv/sぐらいかなぁという感じです。
100万PV/月越えのサイトでも日中で1～2pv/s 程度なので、普通のサイトならば十分すぎると思いますけどね…。
後は運用コストをどれくらい費やせるかで、上を見ようと思えば出来るけど…という感じだと思います。
ご参考になれば幸いです。
Re: MODXの性能改善点について
shobu様
お世話になります。
ご連絡が滞っておりまして、申し訳ございません。
ご返信いただいた内容を参考にさせていただき、nginxの導入等も含めて検討した結果、
MODX動作時のコストが高いため、MODXはコンテンツ管理のみで利用し、
通常処理はMODXから出力したHTMLをapacheで静的コンテンツとして処理させ、
動的部分はPHPとAjaxを用いて処理させ、MODXが動作しないようAP側で対処することとしました。
検証した結果、性能も改善されておりましたため、こちらで対処いたします。
貴重なご意見をいただきましてありがとうございました。
以上、よろしくお願いいたします。
お世話になります。
ご連絡が滞っておりまして、申し訳ございません。
ご返信いただいた内容を参考にさせていただき、nginxの導入等も含めて検討した結果、
MODX動作時のコストが高いため、MODXはコンテンツ管理のみで利用し、
通常処理はMODXから出力したHTMLをapacheで静的コンテンツとして処理させ、
動的部分はPHPとAjaxを用いて処理させ、MODXが動作しないようAP側で対処することとしました。
検証した結果、性能も改善されておりましたため、こちらで対処いたします。
貴重なご意見をいただきましてありがとうございました。
以上、よろしくお願いいたします。
Re: MODXの性能改善点について
http://modx.com/blog/2013/03/28/help-re ... r-release/
数日以内にリリースされる予定の2.2.7ではキャッシュまわりが改善され、大幅なパフォーマンスアップが期待できるようです。
上記の記事によると、10万ページ近くあるサイトの場合、130MB近く消費するメモリを24MB程度までに抑えることができるとのことです。
cache_alias_mapというconfigが追加され、これをオフにすることで、URLの処理に関してはキャッシュを使わなくなる仕組みです。
数日以内にリリースされる予定の2.2.7ではキャッシュまわりが改善され、大幅なパフォーマンスアップが期待できるようです。
上記の記事によると、10万ページ近くあるサイトの場合、130MB近く消費するメモリを24MB程度までに抑えることができるとのことです。
cache_alias_mapというconfigが追加され、これをオフにすることで、URLの処理に関してはキャッシュを使わなくなる仕組みです。