sitecache.idx.phpでのエラー  【解決済み】

質問全般・改善要望
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事 by yama »

tagbouz さんが書きました: 折を見て、エクスポートした後、ローカル環境にでもデータをインポートして復元できるかテストを行ってみようと思います。
まずは、データのバックアップは取っておいたほうがいいですね・・・。modxの管理画面からのバックアップで問題ないですか?
それともphpmyadmin経由でエクスポートしておいたほうが無難なんでしょうか?
念のため、最初のうちはmodxの管理画面・phpMyAdmin両方でとっておくと安心だと思います。基本的にMODx管理画面からのバックアップで問題ないはずですが。kazuikeさんのアドバイス見て思ったけど、phpMyAdmin使って圧縮状態のバックアップもとっておくといざという時に役に立つかも。

ローカルに復元する時、あらかじめバックアップデータをテキストエディタで開いて、ドメイン名が設定されている部分を検索して「localhost」に書き換えるなどの作業が必要かも。このへんMODxちょっとすっきりしないとこですねー、、

ファイル排他制御とか、開発側としてはこのトピ見てるだけでいろいろヒントが・・w
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事 by sama55 »

tagbouz さんが書きました:折を見て、エクスポートした後、ローカル環境にでもデータをインポートして復元できるかテストを行ってみようと思います。
まずは、データのバックアップは取っておいたほうがいいですね・・・。modxの管理画面からのバックアップで問題ないですか?
それともphpmyadmin経由でエクスポートしておいたほうが無難なんでしょうか?
たとえ時間は掛かっても、複数の方法でとることをお勧めします。
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事 by tagbouz »

長らく解決に至っていないこのエラーについてですが
進展がありましたのでご連絡いたします。

クライアントサイドで、エラーについてサーバ屋に問い合わせをしたところ、
phpのバージョンが4→5にあがったのが原因ではないかとのことでした。

htaccessでphpのバージョンを4に落としてみてくださいとのレスが来たらしいのですが、
不具合等起こる可能性はありますでしょうか?
(ちなみにバージョンを4に落とすときは「CGI版」の「PHP4」を使用する設定となるらしいです。)

phpのバージョンを変更するだけなのでDB等は絡まないから
万が一の場合でも致命的なエラーは起こらないだろうと考えてますが
なにか注意点などあればご教授ください。

ちなみに変更作業は念のため時間をとって来週行うことにしてもらいました。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事 by yama »

サーバ担当者さんがそう答えたということは、ちょうどphp4からphp5に切り換えたタイミングでそうなったということでしょうか。そうだとすれば、試してみる価値はあると思います。うまくいってから原因が分かることもありますし。

でも普通に考えると、php4しかもCGI版だともっとパフォーマンスが落ちるはずですが。fastcgiモードではないですよね?

※MODxのキャッシュプロセッサーって排他処理を行なってないみたいなので、こういうケースってこわいですね。一行追記するだけですむので、次のバージョンでは対応したいです。
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事 by sama55 »

tagbouzさん、こんばんわ
tagbouz さんが書きました:クライアントサイドで、エラーについてサーバ屋に問い合わせをしたところ、phpのバージョンが4→5にあがったのが原因ではないかとのことでした。
PHP5.2でメモリ管理が大幅に変わったようなので、その可能性はなきにしもあらず。 ただ・・・
tagbouz さんが書きました:htaccessでphpのバージョンを4に落としてみてくださいとのレスが来たらしいのですが、不具合等起こる可能性はありますでしょうか?
(ちなみにバージョンを4に落とすときは「CGI版」の「PHP4」を使用する設定となるらしいです。)
phpのバージョンを変更するだけなのでDB等は絡まないから万が一の場合でも致命的なエラーは起こらないだろうと考えてますがなにか注意点などあればご教授ください。
PHP5に移行した時期や差し戻すPHP4のバージョンにもよりますが、微妙ですね。。。
「CGI版」と書いてるぐらいなので、きっとPHPの実行形式もモジュールモードからCGIモードに変わるのですよね?
(CGIモードからモジュールモードに切り替える場合に比べれば、影響は少ないと思いますが・・・)


http://www.ibm.com/developerworks/jp/op ... index.html
上記の記事を参考に、manager/processors/cache_sync.class.processor.php の処理を改めて眺めてみました。
modx->db->queryで取得したデータの保存領域(多次元配列)を解放してないことが気になりました。
キャッシュインデクスの生成過程でメモリが枯渇し、その後のパース処理に影響を与えてるのではないかという仮説を立ててみました。PHP5のガベージコレクタの介入タイミングが分からないので単なる気休めに終わってしまうかもしれませんが、この仮説に従ってcache_sync.class.processor.phpのクエリー処理の谷間でmysql_free_result()関数を使って意識的にバッファを解放するようにしてみました。
(修正箇所に"// sama"のコメントを入れてあります。ソースをカスタマイズしてる場合はコメントを頼りに反映してください)
再現頻度が特定できない状態では、適用効果は一定期間運用してみるしかありませんがどうでしょうね。
(新たなエラーや警告が表示されるようなら、すぐにソースを復元してください)
言わずもがなですが、DBのバックアップをとってから適用してください。


memory_get_usage()でメモリの消費状態を見た上で適用する方法なので、正直自信ないです。
他に大きくリークしてるところがあれば効果ないでしょうし・・・すみません。
添付ファイル
cache_sync.class.processor.zip
(3.04 KiB) ダウンロード数: 620 回
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事 by tagbouz »

yamaさん
sama55さん
いつもありがとうございます。
yama さんが書きました:でも普通に考えると、php4しかもCGI版だともっとパフォーマンスが落ちるはずですが。fastcgiモードではないですよね?
fastcgiモード等の具体的な詳細は明示されておりませんでした。
fastcgiモードだとなにか不具合発生する可能性ありですか?
正直、僕的にはphp5→php4(CGI版)に変更してみて、エラーが出たり動作に不具合あったら
元に戻せばいいや的に楽観視しているのですが、だめですかね・・・?
(きっとDB直接絡んだりしないしなんて思ってます。)

クリティカルなエラーが発生しないと信じてやってみる価値ありかなと思ってますが
どう思いますでしょうか?

sama55 さんが書きました:PHP5に移行した時期や差し戻すPHP4のバージョンにもよりますが、微妙ですね。。。「CGI版」と書いてるぐらいなので、きっとPHPの実行形式もモジュールモードからCGIモードに変わるのですよね?(CGIモードからモジュールモードに切り替える場合に比べれば、影響は少ないと思いますが・・・)
そうですね。
差し戻すphp4のバージョンも不明なのです。
実行形式もおそらくCGIモードに変わると思います。(パーミッションを701にしてねって言われました。)
僕的に、ちまたではphpをCGIモードで動かすXREAでもmodxが動作するというblog記事もありますので
モード移行自体は大して問題ないだろうなんて思ってます。

ただ、ほんとにコンテンツのデータ量がハンパないことになっている(今見たらドキュメントIDが5100を超えてました・・・)ので、
DBに致命的な影響が出る可能性があるなら、僕の知識レベル的にも、移行作業自体を断念しようと思っています。
(これはクライアントからも言われました。無理やりやらないでくれとw)

結構性格的に出たとこ勝負!みたいなところがあるので、今の気持ち的にはまだイケイケ的な感じなので、
第三者的な見解があると僕も冷静になれます :oops:
sama55 さんが書きました:memory_get_usage()でメモリの消費状態を見た上で適用する方法なので、正直自信ないです。他に大きくリークしてるところがあれば効果ないでしょうし・・・すみません。
こちらダウンロードさせていただきました。ほんとありがとうございます!
DBのバックアップを取るってことはDBに影響が出る可能性があるってことでしょうか?
だとしたらちょっと及び腰になっちゃいますね・・・
まあきっと無きにしも非ずっていうことなのでしょうが・・・
イケイケな僕はやってみたいことこの上ないのですが、もしものことを考えて様子を見てから実行しようと思います。

とりあえず今の気持ちでいくと、DBに問題が出ないなら、
1.PHPのバージョンを変えてみる。
2.cache_sync.class.processor.phpを変えてみる。
といった順序でやってみようと思います。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事 by yama »

んー、、一番無難なのはEvoのcache_sync.class.processor.phpに差し替える方法のような気がしますが。

でも、もともとphp4で動いていて、その時は問題なかったのですよね?それならたぶん大丈夫だと思いますが、理屈ではphpそのものをダウングレードする方法のほうが影響範囲が広いはずです。サーバ担当者さんはMODxについてはそんなに詳しいわけじゃないと思うので「MODxってphp5とは相性悪いんじゃないですか?」みたいな感覚があるのかもですよ。

あと、xreaのphpをCGIモードで動かす方法は、MODx全体をCGIモードで動かすと負荷がものすごいことになるみたいです。
(xreaのCGIモード設定はセッション管理まわりのバグがあった気がするので全体設定では動かない気がしますが)

http://dog.24-7smile.com/diary/archives/1692
http://mikyouya.s115.xrea.com/archives/157.php
PHPをCGIモードで動かす際の負荷について

というわけでfastcgiモードってのがあるのですね。今回ご利用のサーバがそうだとしたら「CGIモードにしてもあまり変わらないですよ」って返事が返ってくると思います。
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事 by sama55 »

tagbouz さんが書きました:差し戻すphp4のバージョンも不明なのです。
実行形式もおそらくCGIモードに変わると思います。(パーミッションを701にしてねって言われました。)
僕的に、ちまたではphpをCGIモードで動かすXREAでもmodxが動作するというblog記事もありますので
モード移行自体は大して問題ないだろうなんて思ってます。
う~~ん、辛いっすね。。。
tagbouz さんが書きました:ただ、ほんとにコンテンツのデータ量がハンパないことになっている(今見たらドキュメントIDが5100を超えてました・・・)ので、
DBに致命的な影響が出る可能性があるなら、僕の知識レベル的にも、移行作業自体を断念しようと思っています。
(これはクライアントからも言われました。無理やりやらないでくれとw)

・・・中略・・・

こちらダウンロードさせていただきました。DBのバックアップを取るってことはDBに影響が出る可能性があるってことでしょうか?
だとしたらちょっと及び腰になっちゃいますね・・・まあきっと無きにしも非ずっていうことなのでしょうが・・・
イケイケな僕はやってみたいことこの上ないのですが、もしものことを考えて様子を見てから実行しようと思います。
キャッシュの再生成におけるDB操作は主にリードですので、DBに致命的な問題が起こることはまず考えられないのですが、100%安全と言えないのがしんどいところです。怖さはありますが、「論理的にここだ」と言えない現状では、転ばぬ先の杖(システムを復元できる保証)を得た上で、考えられる方策を施してみるしかないですね。
tagbouz さんが書きました:とりあえず今の気持ちでいくと、DBに問題が出ないなら、
1.PHPのバージョンを変えてみる。
2.cache_sync.class.processor.phpを変えてみる。
といった順序でやってみようと思います。
http://forum.modx.jp/viewtopic.php?f=7&t=95#p413
クライアントサイドの都合などで現状のサーバで何とか・・・と苦心されてると思いますが、問題が長期化することもクライアントにとっては厳しいと思います。データの多さからシステムの運用や性能面も相当きつくなってると思いますので、上記を裏で試してみて問題が発生しなくなるようであれば、、、
 ・「これだけ軽くなります」
 ・「ここなら運用コストがもっと安く済みます」
 ・「今の問題はシステム絡みだったのでハード的に対処してみました、いかがでしょう」
 ・「ディスクが一杯なので将来的な運用を睨んでここは一つ英断してください」
みたいな高いレベルで相談されることもお勧めしたいです(勿論検討されてると思いますが・・・)。
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事 by tagbouz »

yamaさん
sama55さん
早速の返信ありがとうございます。

今、php4→php5にアップグレードしたタイミングを調査しています。
もしphp5にアップグレードした後に運用を始めているのであれば、
ダウングレードが必ずしも有効とは限らないと思ったためです。

運用後にアップグレードされているのであればphp4に戻しても問題は少なくすむと思いましたので・・・。

お二人のご意見を頂戴し、まずはcache_sync.class.processor.phpを触る方向で考えなおそうと思います。

まずは手間でもlocalのxamppに同一環境を構築して、
エラーの有無、cache_sync.class.processor.phpの改変時の挙動を確認してから行うのが無難ですよね・・・。

yama さんが書きました:あと、xreaのphpをCGIモードで動かす方法は、MODx全体をCGIモードで動かすと負荷がものすごいことになるみたいです。(xreaのCGIモード設定はセッション管理まわりのバグがあった気がするので全体設定では動かない気がしますが)
これは始めてお聞きしました :o
僕のプライベートサイトもxreaなので注意してみたいと思います。
これはfastcgiモードだったらダウングレードしてみ意味ないよってことですね?
fastcgiってぐらいだから、処理が早くなるのかと思っていました・・・
sama55 さんが書きました:viewtopic.php?f=7&t=95#p413クライアントサイドの都合などで現状のサーバで何とか・・・と苦心されてると思いますが、問題が長期化することもクライアントにとっては厳しいと思います。

・・・中略・・・

みたいな高いレベルで相談されることもお勧めしたいです(勿論検討されてると思いますが・・・)。
まさかここまでデータが増えるなんてちょっと予想外でしたので・・・。
上記にも記しましたとおりxamppへの構築などを踏まえて該当サイトの移設に自信が付いたら提案してみようと思います :cry:

また何か進展があり次第ご報告しますね
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事 by tagbouz »

tagbouz さんが書きました:今、php4→php5にアップグレードしたタイミングを調査しています。もしphp5にアップグレードした後に運用を始めているのであれば、ダウングレードが必ずしも有効とは限らないと思ったためです。
サーバ屋のほうから返答が来たのでご報告します。
どうやら、phpのバージョンアップ自体は運用前に行われていたようです :cry:

さらにさらに、CGI版のphp4と言っていたのが、
CGI版のphp5で試してくれといってきました。
サーバ屋 さんが書きました:※「CGI版」の「PHP」については、
「5.2.6」と「4.4.8」をご用意しております。
(ちなみに現状サーバのphpは5.2.6です)

これだったら、CGI版のphpを試してみても問題なさそうな気がするのですが、
懸念点有りそうでしょうか?


<サバ屋から追加要望が来た.htaccess ファイル内の追加記述>

コード: 全て選択

---------------------------------------
AddHandler php5-script .php
---------------------------------------
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事 by yama »

tagbouz さんが書きました:さらにさらに、CGI版のphp4と言っていたのが、
CGI版のphp5で試してくれといってきました。
なぜわざわざCGI版のphp5なんでしょう。当てずっぽうな展開になってきてる気がします。
もともとphp4でちゃんと動いてたのだから、その状態に戻しましょう。ってことなら分かりますが。
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事 by tagbouz »

yama さんが書きました:もともとphp4でちゃんと動いてたのだから、その状態に戻しましょう。ってことなら分かりますが。
確かにそうなんです。
僕もその辺知識不足なので、メモリとか動作とかの関係でCGI版のほうが軽いのかなと安直に思っているのですが、CGI版のほうが関数等に制限が出てくるということもあるらしいので、ちょっと不安ではあります。

今回のケースは、もともとphp5.2.6だったのにCGI版の5.2.6にすることに意味があるのかなと・・・。
当てずっぽうと言えばそうですが、少しでも改善されるなら検討してみようかなと思っている次第です・・・。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事 by yama »

phpを変えるということは影響範囲はキャッシュ制御以外にも及びます。心配するほどのことも起きないかもしれませんが、数千ページもあると検証しきれないのではないでしょうか。担当者さんに理由を聞いてみたほうがいいと思います。
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事 by tagbouz »

取り急ぎ経過報告としてレスいたします。

現在localhostに問題のサイトを復元しました。
復元してみたところ、問題のエラー発生は確認できておりませんが、
重ねてご指摘いただいておりました、cache_sync.class.processor.phpのチェックをしてみました。

sama55さんに処理していただいたcache_sync.class.processor.php、
evoで使っているcache_sync.class.processor.php
双方挙動を確認しました。

軽くドキュメントの保存を数回繰り返してみたところ、どちらもエラーは発生しませんでした。
(多数あるカスタムテンプレート変数もずれ無く保存されているようです。)

phpのモード変更の前にevoのcache_sync.class.processor.phpを利用し
実運用に回して様子をみたいと思います。


~追記~
cache_sync.class.processor.phpって管理画面の保存時に影響するファイルなんですね。
実際にcache_sync.class.processor.phpが無い状態で動かしていたら、
保存しなければサイトの閲覧は通常通りにできたので、びっくりしました :o
cache_sync.class.processor.phpが無い状態でドキュメントの保存を行ったら当然怒られましたが、
データが破損するようなことは起こりませんでした。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事 by sama55 »

yama さんが書きました:phpを変えるということは影響範囲はキャッシュ制御以外にも及びます。心配するほどのことも起きないかもしれませんが、数千ページもあると検証しきれないのではないでしょうか。
そうですね。。。string関連の処理あたりがヤバそうな予感がします。
tagbouz さんが書きました:現在localhostに問題のサイトを復元しましたところ、問題のエラー発生は確認できておりませんが、重ねてご指摘いただいておりました、cache_sync.class.processor.phpのチェックをしてみました。sama55さんに処理していただいたcache_sync.class.processor.php、evoで使っているcache_sync.class.processor.php 双方挙動を確認しました。軽くドキュメントの保存を数回繰り返してみたところ、どちらもエラーは発生しませんでした。(多数あるカスタムテンプレート変数もずれ無く保存されているようです。)
phpのモード変更の前にevoのcache_sync.class.processor.phpを利用し実運用に回して様子をみたいと思います。
ローカル(XAMPP?)ではPHPもMySQLも豊富なリソースを使って動作するので問題が再現しないのかもしれませんね。
phpinfoやphpmyadminで問題のサーバとローカルの動作状況(特にMySQLの負荷)を比較したいところですが、肝心のサーバのphpmyadminで見れないんですよね。。。うーーん、苦しい。 :?
ローカルでの検証を十分に行って問題が一度も発生しなければ、はっきりした原因は分からなくても、サーバの仕様や設定がtagbouzさん(クライアント)のニーズに耐えられない、ある種の証(あかし)になると思います。そうなると、益々ホストのお引越しが有力になってきます。
tagbouz さんが書きました:~追記~
cache_sync.class.processor.phpって管理画面の保存時に影響するファイルなんですね。
実際にcache_sync.class.processor.phpが無い状態で動かしていたら、
保存しなければサイトの閲覧は通常通りにできたので、びっくりしました :o
cache_sync.class.processor.phpが無い状態でドキュメントの保存を行ったら当然怒られましたが、
データが破損するようなことは起こりませんでした。
cache_sync.class.processor.phpは、管理画面でシステムの設定やドキュメントの構成が変化した時に、データベースの内容をsiteCache.idx.phpに引き出す処理です。一般的には、MySQLからデータを引くのは遅いので、主要な情報を予めファイルに引き出しておくことで、いざApacheがページを読みに来たときにデータベースへのアクセスを極力抑えることでページを高速に表示するって寸法。高速表示をうたい文句とするMODxの肝とも言える部分です。他のCMSと比べると今でもかなり速いですが、次期バージョンで更に高速化すると本家の親分が言ってました。

閲覧時はcache_sync.class.processor.phpが作ったassets/cache/siteCache.idx.phpやsitePublishing.idx.phpを見ることはありますが、cache_sync.class.processor.php自体は無関係です。
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー  【解決済み】

投稿記事 by tagbouz »

sama55 さんが書きました:phpinfoやphpmyadminで問題のサーバとローカルの動作状況(特にMySQLの負荷)を比較したいところですが、肝心のサーバのphpmyadminで見れないんですよね。。。うーーん、苦しい。
ローカルでの検証を十分に行って問題が一度も発生しなければ、はっきりした原因は分からなくても、サーバの仕様や設定がtagbouzさん(クライアント)のニーズに耐えられない、ある種の証(あかし)になると思います。そうなると、益々ホストのお引越しが有力になってきます。
確かにそうなんです。
僕もクライアントのphpmyadminを触っていて思ったのですが、SQLは権限的に照会しか出来なそうだし、
インポートもさせてくれなそうなんです。
何かあっても復元する余地がないのでかなり八方塞・・・。

サーバ内のデータも多少軽くしていただけるという話なんですが、
別でデジタルパンフレット的なシステムも同サーバ内に存在しているので、移設自体もなかなか厳しそうです。
(これがクリアになればサーバ移設もいけそうですねぇ)
しかし、今のままでリソースが不足しているだろう事は、僕のlocalのxamppでエラーが発生しないのを見ても明らかではあります。

なので、最終的にこれで行こうと思います。
1.cache_sync.class.processor.phpをevo用に差し替えてみる。
 (クライアントからの要望があれば保証できない前提で、php5.2.6のCGIモードに変更する。)
2.改善されなければサーバの移設(スペックアップ)を検討していただく。


sama55 さんが書きました:高速表示をうたい文句とするMODxの肝とも言える部分です。他のCMSと比べると今でもかなり速いですが、次期バージョンで更に高速化すると本家の親分が言ってました。
すごいですね・・・。
確かにMTやWP・XOOPSと比べても雲泥の差ですよね。
僕が携わっているサイトもXOOPSだったらきっと表示の遅さが問題になったはずです。
sama55 さんが書きました:閲覧時はcache_sync.class.processor.phpが作ったassets/cache/siteCache.idx.phpやsitePublishing.idx.phpを見ることはありますが、cache_sync.class.processor.php自体は無関係です。
なるほど勉強になります :shock:
有益な情報をありがとうございます。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
返信する