Wordpressをリファクタリングしてメモリパフォーマンスを向上させる
Wordpressのメモリ消費量を詳しく調べました。私のサイトでは、各ページに20MBのRAMが割り当てられているようです。これは、すべてのプラグインを実行するための快適な環境を準備するためです。
最適化するためのスポットは1つもなく、ほとんどのメモリを消費する1人の悪者もいません。消費はすべて多くの多くのphpモジュールに分散しています。
Wordpressがメモリ内の環境を一度だけ初期化してから、ヒットするたびに何度も再利用できるようにするにはどうすればよいですか。ユーザーが1回クリックするたびにslow PHP 20 MBを消費したくありません。大量のメモリを搭載したサーバーでも、すべての作業を完了するのに数秒かかります。基本的には、再利用可能な読み取り専用のメモリが必要です。
また...なぜ20MB？誰もがこれについての洞察を提供できますか？
編集：これは私の開発マシンで実行されているWordpress上でのWinCacheGrindの出力です（共有ホスティングよりもはるかに高速です）。ご覧のとおり、メインページのHTMLを生成するためには、1秒の時間がかかります。共有ホスティングでそれを遅くし、あなたはトラブルのレシピを持っています。私はほとんどの時間がかかる方法を選びました。これをどのように最適化しますか。
編集：これは/からのクエリ統計です - この素晴らしいfunctions.phpプロファイリングツール 。
ロード：12クエリ - 532ms - 19.1MB - 43キャッシュヒット/ 53 クエリ：15クエリ - 563ms - 19.0MB - 72キャッシュヒット/ 86 表示：21クエリ - 705ms - 19.2MB - 234キャッシュヒット/ 257
編集：あなたはあなたをおかしくするために保証された何かを見たいですか？これらの行をindex.phpの最後に挿入してください。
echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";
現在の投稿の本文がメモリに格納されている回数を数えるようにしました。私は20のインスタンスを数えました。それからPHPが参照カウントを持っていることに気づいたので、コピーの量はたった3つに減りました。私はさらに調べています。
これが、WordPressがメモリの問題をターゲットにしたリファクタリングを必要としている理由です。あなたはもはやそれが何をしているのかの複雑さにそのメモリ消費を責めることはできません。それは単にたくさんのことをします 間違った 。
編集：これを把握しようとした日の後に、これが私の発見です：
1）全メモリの88％がrequire、include、またはinclude_onceタイプの呼び出しから来ています。
2）phpファイルのインクルードは、ほとんどの場合リクエストを処理する最初の部分で行われます（驚くことではありません）。これは、全てのメモリが消費される場所でもあります。
3）リクエストをしている間に実行されているすべての関数をプロットすることは非常に興味深いです。合計12000を超えるコールがあります。見やすくするためにそれらを動かしました（Level軸は基本的にスタックの深さです）：
4）私が考えることができる唯一の方法は、含まれる.phpファイルの量を最小限にすることです。それらが由来するファイルごとに関数を分割すると、多くのファイルがせいぜい1、2回ヒットしていることがわかります。不要なときにスキップする方法が必要です。例えば、私のリモートデータベースバックアッププラグインはロードされて登録され、まったく使われることはありません。これがファイル名で分割された上記のプロットです。
私のブログのメモリ使用量を30％以上削減することにつながるリファクタリングに対して、私は自分の評判すべてに見合う価値のある賞品を提供しています。
編集：私はインストールされているWP 3.1、これは古いバージョンとの比較です。
青はWP 3.1、赤は3.0.4です。 new WPは高速ですが、メモリを多く消費します。
これはインクルードファイルによるリストです。
これで、「All In One SEOパック」によってどれだけのメモリが消費されるかを実感できます。1つの方法は、必要なものを得るためにプラグインの機能のほんの一部だけを使用することです。また、私自身のプラグインはかなり悪いようです。
条件付きロードを試してみたいのですが。 comment.php（私は私のブログへのコメントを許可しません）および他のいくつかのもの。非推奨のコードをすべて削除しました。グローバルテーブルをオンデマンドでロードするためだけにkses.phpを切り捨てました。 l10nを単純化し（ローカライズはしません）、その関数がルックアップなしで文字列をすぐに返すようにしました。私は私が恣意的に設定した30％の基準からはまだ程遠いです。
編集：APCをダウンロードし、デフォルト設定（32MBのオペコードキャッシュ）で有効にしました。これが比較です。
あなたは、コードのロードが大幅に加速され、そしてまたコードがメモリの中でより少ないスペースを取ることを見ることができます（おそらく我々はオリジナルのソースではなく、単にオペコードを扱うからです）。メモリ消費量はまだかなり高いです。
トラブルの価値がない。 WordPressはそれほど多くのメモリを消費しません。それはボンネットの下で多くの機能を実行するため、それは多くのメモリを消費します。
静的キャッシュプラグインを使用して結果（ページ生成）をキャッシュして提供する方がはるかに簡単で効率的です。そのようにしてほとんどの訪問者はWP自体にさえヒットしないでしょう。
WordPress 3.2以降、PHP 5.2が最小要件になります。私たちのベルトの下では、コアの一部が再構築され始め、自動ロードを伴うクラスを使用できるようになると思います。これにより、 実際に が必要な場合を除いて、コードの一部をロードしなくて済みます。たとえば、ページビューに埋め込みやギャラリーがない場合は、大量のメディアコードを読み込まないようにすることができます。
しかしながら、たとえ彼らがその道を進むことを決心したとしても、私はそれがゆっくりとした進化であると予想するでしょう（他の多くの内部的な変化が起こったように）。多くのファイルやコードの場所を入れ替える必要があります。プラグインによっては後方互換性が損なわれる可能性があります。
問題の一部（それが本当にそう呼ばれることができる場合）は、その種の条件付きロードなしでは、コアフレームワークはコンテンツビューを生成するためにどの機能が必要かどうかを事前に知ることができないということです。そのため、たくさんの関数をロードする必要があります 念のために それらは必要です。
Wordpressがメモリ内の環境を一度だけ初期化してから、ヒットするたびに何度も再利用できるようにするにはどうすればよいですか。
これはオペコードキャッシングと呼ばれます。
あなたはおそらくそれほどラム使用量を減らすことができないでしょう。しかし、mod_phpを使っているのであれば、代わりにmod_fcgidに切り替えたいと思うかもしれません。
mod_phpは少し遅くなりますが、画像の提供、静的ファイルの提供、キャッシュの実行など、必要のない場合でもphpをロードします。あなたがたくさんの要求があるなら、これはたくさんのラムです。
fcgidを使用すると、これを大幅に減らすことができます。
また、静的キャッシュ（w3totalキャッシュなど）を使用すると、php をまったく使用しなくてもよくなります / RAM使用量が少なくなり、db接続が少なくなり、非常に有利です。
ハ私は、共有ホスティングアカウントが処理できる以上のデータと使用量を過負荷にするつもりであるので、Webアプリに取り組んでいるので、WPを組み込むのは非常に簡単だったので BackPress からフレームワークとして作業し、特定のユースケースに必要なものだけを作成します。
それで、私のコア環境をPHPの中の何百ものWPファイルから実際に必要な20個だけに減らすことができました。 WordPressで大好きなユーザー管理、フォーマット、そしてcron機能。
問題はそれがたくさんの仕事をしているということです、そして私は私自身の個人的な使用を超えた何かのために私のハックジョブを決して信頼しないでしょう。完全なWP環境を使いたい場合は、そのまま使用してください。それは、何百年もの開発者が数年間かけて微調整してきたためです。ここにいるすべての人が言っているように、コアをハックするよりも優れたホスティングプランを見つけ、キャッシング技術を研究することで、はるかに遠くなるでしょう。
いくつかの基本的な提案：
- キャッシュ用のw3トータルキャッシュプラグイン..
- memcacheをインストールして有効にし、さらにw3 total cache設定から有効にします（opcode cacheも良い選択肢ですが、w3 total cache pluginではうまくいきません）
- テーマファイル内の直接リンクへのクエリを最小限に抑えます。
- 未使用の余分なプラグインをすべて無効にして削除します。
- データベースを最適化します。
私は毎日巨大なトラフィックでよく知られているワードプレスのサイトを運営しています。
はい、WordPressは最初にすべてのものをロードし、それから我々がそれをするように頼むことをします。私たちがファイルを置くことができるRAMに仮想プールを作成できることをどこかに思い出すことができます。私はWordPress全体をメモリ（<10MB）に入れるというアイデアを持っていました。そうすれば多くのI/Oを節約することができ、それだけでスピードを上げることができます。しかし、私はそれを試す機会を得たことはなく、さらにそのようなことを追求することにそれほど熟達していません。しかし、それは試してみる価値があるようです。