php - 高負荷サイトでPHPを使用するための戦術

Question

あなたがこれに答える前に、私は高いサーバー負荷を達成するのに十分な人気のあるものを開発したことがありません。PHPといくつかの最適化手法を知っているとはいえ、私を（ため息をつく）惑星に着陸したばかりのエイリアンとして扱ってください。

私はPHPでツールを開発しており、それが正しく機能すれば、かなりの数のユーザーを獲得できます。しかし、私はプログラムを完全に開発することができますが、大量のトラフィックを処理できるものを作成することに関しては、ほとんど無知です。それで、ここにいくつかの質問があります（この質問もリソーススレッドに自由に変えてください）。

データベース

現時点では、PHP5でMySQLi機能を使用する予定です。ただし、ユーザーとコンテンツに関連してデータベースをどのように設定する必要がありますか？実際に複数のデータベースが必要ですか？現時点では、すべてが1つのデータベースにまとめられています。ただし、ユーザーデータをあるデータベースに、実際のコンテンツを別のデータベースに、最後にコアサイトコンテンツ（テンプレートマスターなど）を別のデータベースに拡散することを検討しています。この背後にある私の理由は、異なるデータベースにクエリを送信すると、1つのデータベース= 3つのロードソースとして、それらのデータベースの負荷が軽減されるということです。また、それらがすべて同じサーバー上にある場合でも、これは効果的でしょうか？

キャッシング

ページの作成と変数の交換に使用されるテンプレートシステムがあります。マスターテンプレートはデータベースに保存され、テンプレートが呼び出されるたびに、キャッシュされたコピー（htmlドキュメント）が呼び出されます。現在、これらのテンプレートには、静的変数と動的変数の2種類の変数があります。静的変数は通常、ページ名やサイト名など、頻繁に変更されないものです。動的変数は、ページが読み込まれるたびに変化するものです。

これに関する私の質問：

別の記事にコメントがあるとしましょう。これはより良い解決策です：ページがロードされるたびに（DB呼び出しから）単純なコメントテンプレートを保存してコメントをレンダリングするか、コメントが追加/編集/削除されるたびにコメントページのキャッシュされたコピーをhtmlページとして保存しますページが再キャッシュされます。

ついに

PHPで高負荷サイトを実行するためのヒント/ポインタはありますか？FacebookやYahoo!など、使用できる言語だと確信しています。優先順位を付けてください。しかし、注意すべき経験はありますか？

score 93 · Accepted Answer

2つのサイトは同じではありません。問題点がどこにあるかを確認するには、jmeterやbenchmarkなどのツールを入手する必要があります。推測と改善に多くの時間を費やすことができますが、変更を測定して比較するまで、実際の結果は表示されません。

たとえば、長年にわたり、MySQLクエリキャッシュはすべてのパフォーマンス問題の解決策でした。サイトが遅い場合、MySQLの専門家はクエリキャッシュをオンにすることを提案しました。書き込み負荷が高い場合、キャッシュは実際には機能しなくなっていることがわかります。テストせずにオンにした場合、あなたは決して知りません。

また、スケーリングが完了していないことを忘れないでください。10req / sを処理するサイトは、1000req/sをサポートするために変更が必要になります。また、運が良ければ10,000req / sをサポートする必要がある場合は、アーキテクチャも完全に異なって見える可能性があります。

データベース

MySQLiを使用しないでください-PDOは「最新の」オブジェクト指向データベースアクセス層です。使用する最も重要な機能は、クエリのプレースホルダーです。サーバー側の準備やその他の最適化も使用できるほど賢いです。
この時点でデータベースを分割したくない場合があります。1つのデータベースが機能していないことがわかった場合は、アプリに応じて、スケールアップするためのいくつかの手法があります。書き込みよりも読み取りが多い場合は、通常、追加のサーバーへの複製が適切に機能します。シャーディングは、データを多くのマシンに分割する手法です。

キャッシング

データベースにキャッシュしたくない場合があります。通常、データベースはボトルネックであるため、データベースにIOを追加することは通常悪いことです。APCやZendのような同様のことを実現するPHPキャッシュがいくつかあります。
キャッシュをオンまたはオフにしてシステムを測定します。私はあなたのキャッシュがページをまっすぐに提供するよりも重いに違いない。
dbからコメントと記事データを構築するのに長い時間がかかる場合は、memcacheをシステムに統合してください。クエリ結果をキャッシュして、memcachedインスタンスに保存できます。memcacheからデータを取得する方が、データベースからデータをアセンブルするよりも高速である必要があることを覚えておくことが重要です。
記事が動的でない場合、または生成後に単純な動的変更がある場合は、htmlまたはphpをディスクに書き出すことを検討してください。ディスク上で記事を探すindex.phpページがあれば、それがクライアントにストリーミングされます。そうでない場合は、記事を生成してディスクに書き込み、クライアントに送信します。ディスクからファイルを削除すると、ページが再書き込みされます。コメントが記事に追加された場合は、キャッシュされたコピーを削除します-それは再生成されます。

score 65 · Accepted Answer

私は、1,500 万人を超えるユーザーがいるサイトの主任開発者です。早い段階で計画を立て、慎重にスケーリングしたため、スケーリングの問題はほとんどありませんでした。ここでは、私の経験から提案できる戦略をいくつか紹介します。

スキーマ まず、スキーマを非正規化します。これは、複数のリレーショナルテーブルを使用するのではなく、1 つの大きなテーブルを使用することを選択する必要があることを意味します。一般に、複数の準備と照合を行うとディスク I/O が消費されるため、結合は貴重な DB リソースの浪費になります。できる限り避けてください。

ここでのトレードオフは、冗長データを格納/プルすることですが、データとケージ内の帯域幅は非常に安価 (より大きなディスク) であるのに対し、複数の準備 I/O は桁違いに高価 (より多くのサーバー) であるため、これは許容されます。 .

INDEXING クエリが少なくとも 1 つのインデックスを使用していることを確認してください。ただし、頻繁に作成または更新すると、インデックスにコストがかかることに注意してください。これを回避するための実験的なトリックがいくつかあります。

インデックスが作成された列と並行して実行される、インデックスが作成されていない追加の列を追加してみることができます。次に、インデックスが作成された列の上にインデックスが作成されていない列をバッチで書き込むオフラインプロセスを実行できます。このようにして、いつ mySQL がインデックスを再計算する必要があるかをより適切に制御できます。

ペストのような計算クエリは避けてください。クエリを計算する必要がある場合は、書き込み時に 1 回実行してみてください。

キャッシュ Memcached を強くお勧めします。PHP スタック (Facebook) の最大手によって証明されており、非常に柔軟です。これを行うには 2 つの方法があります。1 つは DB レイヤーでのキャッシュ、もう 1 つはビジネスロジックレイヤーでのキャッシュです。

DB レイヤーオプションでは、DB から取得したクエリの結果をキャッシュする必要があります。md5() を使用して SQL クエリをハッシュし、それをデータベースに移動する前にルックアップキーとして使用できます。これの利点は、実装が非常に簡単であることです。マイナス面 (実装によって異なります) は、キャッシュの有効期限に関してすべてのキャッシュを同じように扱うため、柔軟性が失われることです。

私が働いているショップでは、ビジネスレイヤーキャッシングを使用しています。これは、システム内の各具体的なクラスが独自のキャッシングスキーマとキャッシュタイムアウトを制御することを意味します。これは非常にうまく機能していますが、DB から取得したアイテムはキャッシュから取得したアイテムと同じではない可能性があるため、キャッシュと DB を一緒に更新する必要があることに注意してください。

データシャーディング レプリケーションはこれまでのところしかありません。予想よりも早く、書き込みがボトルネックになります。これを補うために、できるだけ早くデータシャーディングをサポートするようにしてください。そうしないと、後で自分を撃ちたくなります。

実装は非常に簡単です。基本的に、キー権限をデータストレージから分離する必要があります。グローバル DB を使用して、主キーとクラスター ID の間のマッピングを保存します。このマッピングを照会してクラスターを取得してから、クラスターを照会してデータを取得します。このルックアップ操作を完全にキャッシュして、操作を無視できるようにすることができます。

これの欠点は、複数のシャードからのデータをまとめるのが難しい場合があることです。ただし、それを回避する方法を設計することもできます。

オフライン処理 ユーザーがバックエンドを待つ必要がない場合は、ユーザーを待たせないでください。ジョブキューを作成し、オフラインにできる処理を移動して、ユーザーの要求とは別に実行します。

score 43 · Accepted Answer

私は、PHPとMySQLによって数百万/ヒット/月の支援を受けるいくつかのサイトに取り組んできました。ここにいくつかの基本があります：

キャッシュ、キャッシュ、キャッシュ。キャッシングは、Webサーバーとデータベースの負荷を軽減するための最も簡単で効果的な方法の1つです。ページコンテンツ、クエリ、コストのかかる計算、I/Oバウンドのすべてをキャッシュします。Memcacheは非常にシンプルで効果的です。
限界に達したら、複数のサーバーを使用します。複数のWebサーバーと複数のデータベースサーバー（レプリケーションあり）を使用できます。
Webサーバーへのリクエストの全体的な数を減らします。これには、expiresヘッダーを使用してJS、CSS、および画像をキャッシュする必要があります。静的コンテンツをCDNに移動することもできます。これにより、ユーザーエクスペリエンスが高速化されます。
測定とベンチマーク。本番マシンでNagiosを実行し、dev/qaサーバーで負荷テストを行います。あなたはそれを防ぐことができるようにあなたのサーバーがいつ発火するかを知る必要があります。

スケーラブルなWebサイトの構築を読むことをお勧めします。これは、Flickrのエンジニアの1人によって書かれたものであり、優れたリファレンスです。

スケーラビリティについての私のブログ投稿もチェックしてください。複数の言語とプラットフォームでのスケーリングに関するプレゼンテーションへのリンクがたくさんあります： http ：//www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

score 40 · Accepted Answer

Re: PDO / MySQLi / MySQLND

@ゲイリー

目的が異なるため、「MySQLi を使用しないでください」とは言えません。PDO はほとんど抽象化レイヤーのようなもので (実際にはそうではありません)、複数のデータベース製品を簡単に使用できるように設計されていますが、MySQLi は MySQL 接続に固有です。あなたのステートメントは、進行がmysql -> mysqli -> PDOであり、そうではないことを暗示しているため、PDOをMySQLiと比較するコンテキストで最新のアクセスレイヤーであると言うのは間違っています。

MySQLi と PDO の選択は簡単です。複数のデータベース製品をサポートする必要がある場合は、PDO を使用します。MySQL のみを使用している場合は、PDO と MySQLi のどちらかを選択できます。

では、なぜ PDO ではなく MySQLi を選択するのでしょうか? 下記参照...

@ロス

最新の MySQL コア言語レベルライブラリである MySQLnd については正しいですが、MySQLi の代わりにはなりません。MySQLi (PDO と同様) は、PHP コードを介して MySQL と対話する方法のままです。どちらも PHP コードの背後にある C クライアントとして libmysql を使用します。問題は、libmysql がコア PHP エンジンの外部にあり、それが mysqlnd の出番です。つまり、効率を最大化するためにコア PHP 内部を利用するネイティブドライバーであり、特にメモリ使用量が懸念されます。

MySQLnd は MySQL 自身によって開発されており、最近、今年後半にリリースされる予定の RC テスト中の PHP 5.3 ブランチに上陸しました。その後、MySQLi で MySQLnd を使用できますが、PDO では使用できません。これにより、MySQLiは多くの領域 (すべてではない) でパフォーマンスが向上し、PDO の機能のような抽象化が必要ない場合、MySQL との対話に最適な選択肢になります。

とはいえ、MySQLndは PHP 5.3で PDO 用に利用できるようになったため、ND から PDO へのパフォーマンス強化の利点を得ることができます。 MySQLi ができるように ND の機能強化。

2006 年のものですが、いくつかの有用なベンチマークをここで見つけることができます。また、このオプションのようなことにも注意する必要があります。

MySQLi と PDO のどちらを使用するかを決定する際には、考慮する必要がある多くの考慮事項があります。現実には、途方もなく高い要求数に到達するまでは問題になりません。その場合、物事を抽象化して MySQL ドライバーを提供する拡張機能よりも、MySQL 用に特別に設計された拡張機能を使用する方が理にかなっています。 .

それぞれ一長一短があるので、どちらが良いという単純な問題ではありません。私が提供したリンクを読んで、自分で決定し、それをテストして調べる必要があります。私は過去のプロジェクトで PDO を使用しており、これは優れた拡張機能ですが、純粋なパフォーマンスを得るために私が選択したのは、新しい MySQLND オプションがコンパイルされた MySQLi です (PHP 5.3 がリリースされたとき)。

score 23 · Accepted Answer

全般的

実際の負荷を確認する前に、最適化を試みないでください。あなたは正しいと思うかもしれませんが、そうでない場合、あなたはあなたの時間を無駄にしてしまいます。
jmeter 、xdebug 、または別のツールを使用して、サイトのベンチマークを行います。
負荷が問題になり始めた場合は、オブジェクトまたはデータのキャッシュが関係している可能性が高いため、通常はキャッシュオプション（memcached、MySQLキャッシュオプション）を確認してください。

コード

ボトルネックがどこにあるか、コードにあるのかデータベースにあるのかがわかるように、コードのプロファイルを作成します

データベース

他のデータベースへの移植性が重要でない場合はMYSQLiを使用し、そうでない場合はPDOを使用します
ベンチマークでデータベースに問題があることが明らかになった場合は、キャッシュを開始する前にクエリを確認してください。EXPLAINを使用して、クエリの速度が低下している場所を確認します。
クエリが最適化され、データベースが何らかの方法でキャッシュされた後、複数のデータベースを使用することができます。データ、クエリ、および読み取り/書き込み動作の種類に応じて、複数のサーバーに複製するか、シャーディング（複数のデータベース/サーバーにデータを分割する）のいずれかが適切な場合があります。

キャッシング

コード、オブジェクト、およびデータのキャッシュについては、多くの記述が行われています。APC、Zend Optimizer、memcached、QuickCache、JPCacheに関する記事を検索してください。本当に必要になる前にこれをいくつか実行してください。そうすれば、最適化されていない状態から始めることについて心配する必要がなくなります。
APCとZendOptimizerはオペコードキャッシュであり、コードの再解析と再コンパイルを回避することでPHPコードを高速化します。一般的にインストールは簡単で、早めに行う価値があります。
Memcachedは汎用キャッシュであり、クエリ、PHP関数またはオブジェクト、またはページ全体をキャッシュするために使用できます。コードは、それを使用するために特別に作成する必要があります。これは、キャッシュされたオブジェクトの作成、更新、および削除を処理する中心点がない場合、複雑なプロセスになる可能性があります。
QuickCacheとJPCacheはファイルキャッシュですが、それ以外はMemcachedに似ています。基本的な概念は単純ですが、コードも必要であり、作成、更新、削除の中心点があるため簡単です。

その他

高負荷用の代替Webサーバーを検討してください。lighthttpやnginxのようなサーバーは、Apacheのパワーと柔軟性を犠牲にすることができれば（または、それらを必要としない場合、多くの場合、必要としない場合）、Apacheよりもはるかに少ないメモリで大量のトラフィックを処理できます。
最近のハードウェアは驚くほど安いので、「モンスターサーバーを購入しよう」よりも、コードの大きなブロックを最適化するための労力を費やすことを忘れないでください。
この質問に「MySQL」タグと「scaling」タグを追加することを検討してください

score 9 · Accepted Answer

APCは絶対に必要です。それは素晴らしいキャッシングシステムを作るだけでなく、自動キャッシュされたPHPファイルからの利益は天の恵みです。複数データベースのアイデアに関しては、同じサーバー上に異なるデータベースを配置することで多くのメリットが得られるとは思いません。クエリ時間中の速度が少し向上する可能性がありますが、同期していることを確認しながら3つすべてのコードをデプロイして維持するのにかかる労力は、それだけの価値があるとは思えません。

また、 Xdebugを実行して、プログラムのボトルネックを見つけることを強くお勧めします。それは私にとって最適化を簡単にしました。

score 9 · Accepted Answer

まず、クヌースが言ったように、「時期尚早の最適化はすべての悪の根源です」。これらの問題に今すぐ対処する必要がない場合は、対処しないでください。最初に正しく機能するものを提供することに集中してください。そうは言っても、最適化が待ちきれない場合。

データベースクエリのプロファイリングを試して、何が遅いのか、何がたくさん起こるのかを理解し、そこから最適化戦略を考え出します。

Memcachedは、すべてのタイプのコンテンツを効率的にキャッシュするために多くの高負荷サイトが使用するものであり、それに対応するPHPオブジェクトインターフェイスは非常に優れているため、Memcachedを調査します。

データベースをサーバー間で分割し、ある種の負荷分散技術を使用する（たとえば、必要なデータを使用して1から＃の冗長データベースのランダムな数を生成し、その数を使用して接続するデータベースサーバーを決定する）ことも、増加するための優れた方法です。効率。

これらはすべて、過去にかなり高負荷のサイトでかなりうまく機能しました。これがあなたが始めるのに役立つことを願っています:-)

score 6 · Accepted Answer

私は月に700万から800万のページビューを持つウェブサイトを運営しています。それほど多くはありませんが、サーバーが負荷を感じるのに十分です。私たちが選んだソリューションは単純でした。データベースレベルのMemcacheです。このソリューションは、データベースの負荷が主な問題である場合にうまく機能します。

Memcacheを使用して、オブジェクト全体と最も頻繁に使用されたデータベースの結果をキャッシュすることから始めました。それは機能しましたが、バグも発生しました（もっと注意していれば、それらのいくつかを回避できたかもしれません）。

そこで、アプローチを変更しました。データベースラッパーを構築し（古いデータベースとまったく同じメソッドを使用しているため、簡単に切り替えることができます）、それをサブクラス化してmemcachedデータベースアクセスメソッドを提供しました。

今、あなたがしなければならないのは、クエリがキャッシュされた（そしておそらく古い）結果を使用できるかどうかを決定することです。ユーザーが実行するクエリのほとんどは、Memcacheから直接フェッチされるようになりました。例外は更新と挿入です。これらはメインのWebサイトでは、ロギングが原因でのみ発生します。このかなり単純な方法で、サーバーの負荷が約80％削減されました。

score 6 · Accepted Answer

Xdebug（tj9991を推奨）のようなものでアプリをプロファイリングすることは間違いなく必須です。盲目的に物事を最適化することを回避することはあまり意味がありません。Xdebugは、コードの実際のボトルネックを見つけるのに役立ちます。これにより、最適化時間を賢く費やして、実際に速度低下を引き起こしているコードのチャンクを修正できます。

Apacheを使用している場合、テストに役立つもう1つのユーティリティはSiegeです。サーバーとアプリケーションが実際にそのペースを通過することにより、高負荷にどのように反応するかを予測するのに役立ちます。

PHP用のあらゆる種類のオペコードキャッシュ（APCや他の多くのキャッシュの1つなど）も大いに役立ちます。

score 6 · Accepted Answer

価値があるのは、memcachedのような拡張機能/ヘルパーパッケージがなくても、PHPのキャッシュはDIRTSIMPLEです。

必要なのは、を使用して出力バッファを作成することだけですob_start()。

グローバルキャッシュ関数を作成します。を呼び出しob_start、関数をコールバックとして渡します。関数で、ページのキャッシュされたバージョンを探します。存在する場合は、それを提供して終了します。

存在しない場合、スクリプトは処理を続行します。一致するob_end（）に到達すると、指定した関数が呼び出されます。その時点で、出力バッファの内容を取得し、それらをファイルにドロップして、ファイルを保存し、終了するだけです。

有効期限/ガベージコレクションを追加します。

ob_start()そして、多くの人はあなたが入れ子/ob_end()電話をかけることができることに気づいていません。したがって、たとえば、広告を解析したり、構文の強調表示を行ったりするためにすでに出力バッファを使用している場合は、別のob_start/ob_end呼び出しをネストすることができます。

score 5 · Accepted Answer

PHP のキャッシング拡張機能についてアドバイスをいただきありがとうございます。どちらか一方を使用する理由を説明していただけますか? IRC を通じて memcached について素晴らしいことを聞いたことがありますが、APC については聞いたことがありません。それらについてどう思いますか? 複数のキャッシングシステムを使用することはかなり逆効果だと思います。

実際、多くの人が APC と memcached を一緒に使用しています...

score 4 · Accepted Answer

私が間違っていたようです。MySQLi はまだ開発中です。しかし記事によると、PDO_MySQL は現在 MySQL チームによってコントリビュートされています。記事から：

MySQL の改良された拡張機能 - mysqli - が主力製品です。文字セット、プリペアドステートメント、ストアドプロシージャなど、MySQL サーバーのすべての機能をサポートしています。ドライバーはハイブリッド API を提供します。好みに応じて、手続き型またはオブジェクト指向のプログラミングスタイルを使用できます。mysqli には PHP 5 以降が付属しています。PHP 4 のサポート終了は 2008 年 8 月 8 日です。

PHP データオブジェクト (PDO) は、データベースアクセスの抽象化レイヤーです。PDO を使用すると、さまざまなデータベースに対して同じ API 呼び出しを使用できます。PDO は、SQL の抽象化をまったく提供しません。PDO_MYSQL は、PDO 用の MySQL ドライバーです。PDO_MYSQL は PHP 5 に付属しています。PHP 5.3 以降、MySQL 開発者は積極的に PDO_MYSQL に貢献しています。統合 API の PDO の利点は、MySQL 固有の機能 (複数のステートメントなど) が統合 API では完全にサポートされないという代償を伴います。

これまでに公開された最初の PHP 用 MySQL ドライバーである ext/mysql の使用をやめてください。2004 年に PHP 5 で MySQL の改良された拡張機能 (mysqli) が導入されて以来、最も古いドライバーを使用する理由はありません。ext/mysql は、文字セット、プリペアドステートメント、およびストアドプロシージャをサポートしていません。これは、MySQL 4.0 の機能セットに限定されています。MySQL 4.0 の延長サポートは 2008 年 12 月 31 日に終了することに注意してください。そのような古いソフトウェアの機能セットに自分自身を制限しないでください! mysqli にアップグレードします。Converting_to_MySQLi も参照してください。私たちの観点からは、mysql はメンテナンスのみのモードです。

私には、この記事は MySQLi に偏っているように見えます。私はPDOに偏っていると思います。私はMySQLiよりもPDOが好きです。それは私には簡単です。API は、私がプログラミングした他の言語に非常に近いものです。オブジェクト指向データベースインターフェイスは、より適切に機能するようです。

PDO では利用できなかった特定の MySQL 機能に出くわしたことはありません。もしやったら驚くだろう。

score 3 · Accepted Answer

PDOも非常に遅く、そのAPIはかなり複雑です。移植性が問題にならないのであれば、正気の人は誰もそれを使うべきではありません。そしてそれに直面しましょう、すべてのウェブアプリの99％ではそうではありません。MySQLやPostrgreSQL、またはそれが使用しているものに固執するだけです。

PHPの質問と何を考慮に入れるかについて。時期尚早の最適化はすべての悪の根源だと思います。;）最初にアプリケーションを完成させ、プログラミングに関してはクリーンに保ち、少しのドキュメントを作成し、単体テストを作成します。上記のすべてを使用すると、時が来たときにコードのリファクタリングに問題はありません。しかし、最初にあなたはそれをやり遂げて、人々がそれにどのように反応するかを見るためにそれを押し出したいのです。

score 2 · Accepted Answer

私の最初のアドバイスは、この問題について考え、サイトを設計するときにそれを念頭に置くことですが、やりすぎないでください。新しいサイトの成功を予測することはしばしば困難であり、私はあなたの時間を早く立ち上げて後でそれを最適化することに費やすほうがよいでしょう。

一般的に、Simpleは高速です。テンプレートはあなたを遅くします。データベースはあなたを遅くします。複雑なライブラリはあなたを遅くします。テンプレートを互いに重ねてデータベースから取得し、複雑なライブラリで解析します->時間遅延は互いに倍増します。

基本的なサイトを立ち上げて実行したら、どこで努力するかを示すためにテストを行います。どこをターゲットにするかを見つけるのは難しいです。多くの場合、処理を高速化するには、コードの複雑さを解明する必要があります。これにより、コードが大きくなり、保守が難しくなるため、必要な場合にのみ実行する必要があります。

私の経験では、データベース接続の確立は比較的費用がかかりました。あなたがそれをうまくやることができるならば、サイトへのフロントページのような最もトラフィックの多いページで一般の訪問者のためにデータベースに接続しないでください。複数のデータベース接続を作成することは、ほとんどメリットのない狂気です。

score 2 · Accepted Answer

すでに多くの適切な回答が寄せられていますが、XCacheと呼ばれる別のオペコードキャッシュを紹介したいと思います。それは軽い寄稿者によって作成されます。

また、将来、データベースサーバーの負荷分散が必要になる可能性がある場合、MySQL Proxyはこれを実現するのに非常に役立ちます。

これらのツールはどちらも既存のアプリケーションに非常に簡単にプラグインできるため、この最適化は必要なときにそれほど手間をかけずに実行できます。

score 2 · Accepted Answer

確かに pdo は優れていますが、現在は修正されているように見えますが、mysql および mysqli に対するパフォーマンスについてはいくつかの論争がありました。

移植性を想定するなら pdo を使うべきですが、そうでない場合は mysqli を使うべきです。OO インターフェイス、準備されたステートメント、および pdo が提供するほとんどのもの (移植性を除く) を備えています。

さらに、パフォーマンスが本当に必要な場合は、PHP 5.3 の (ネイティブの mysql) MysqLndドライバーを準備してください。これは、php とより緊密に統合され、パフォーマンスが向上し、メモリ使用量が改善されます (およびパフォーマンスチューニングの統計)。

Memcache は、クラスター化されたサーバー (および YouTube のような負荷) を使用している場合に便利ですが、最初にAPCも試してみます。

score 2 · Accepted Answer

最初の質問は、実際にどのくらいの大きさになると予想していますか? また、インフラストラクチャへの投資をどの程度計画していますか。ここで質問する必要があると感じているので、限られた予算で小規模に開始することを期待していると思います。

サイトが利用できない場合、パフォーマンスは無関係です。可用性のためには、水平方向のスケーリングが必要です。賢明に回避できる最小値は、apache、php、および mysql を実行する 2 台のサーバーです。一方の DBMS を他方のスレーブとして設定します。マスターですべての書き込みを行い、ローカルデータベースですべての読み取りを行います (それが何であれ) - 何らかの理由で、読み取ったばかりのデータを読み戻す必要がある場合を除きます (マスターを使用)。自動的にスレーブをプロモートし、マスターをフェンシングするための機械が整っていることを確認してください。Web サーバーのアドレスにラウンドロビン DNS を使用して、スレーブノードとの親和性を高めます。

この段階で異なるデータベースノード間でデータを分割することは非常に悪い考えですが、同じサーバー上の異なるデータベース間でデータを分割することを検討することをお勧めします (これにより、facebook を追い越したときにノード間の分割が容易になります)。

サイトのパフォーマンスを測定し、ボトルネックを特定するための監視ツールとデータ分析ツールが整っていることを確認してください。ほとんどのパフォーマンスの問題は、より良い SQL を作成するか、データベーススキーマを修正することで修正できます。

テンプレートキャッシュをデータベースに保持するのはばかげた考えです。データベースは、構造化データの中央の共通リポジトリである必要があります。テンプレートキャッシュを Web サーバーのローカルファイルシステムに保持します。より高速に使用でき、データベースアクセスが遅くなることはありません。

オペコードキャッシュを使用してください。

サイトとそのログを十分に調べて、なぜこんなに遅くなったのかを理解してください。

可能な限り多くのキャッシュをクライアントにプッシュします。

mod_gzip を使用して、可能な限りすべてを圧縮します。

C.

score 1 · Accepted Answer

キャッシュについてのポイントはスポットオンです。これは、効率的なアプリケーションを構築する上で最も複雑でなく、最も重要な部分です。memcachedは優れていますが、アプリケーションが単一のサーバー上にある場合、APCは約5倍高速であることを付け加えたいと思います。

MySQLパフォーマンスブログの「キャッシュパフォーマンスの比較」の投稿には、このテーマに関するいくつかの興味深いベンチマークがあります-http ://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/。

score 1 · Accepted Answer

誰もこれについてすでに言及していないとは信じられません：モジュール化と抽象化。あなたのサイトがたくさんのマシンに成長しなければならないと思うなら、あなたはそれができるようにそれを設計しなければなりません！これは、データベースがローカルホスト上にあると想定しないなどの愚かなことを意味します。また、データベース抽象化レイヤーの作成など、最初は面倒になることも意味します（PDOのように、必要なことだけを実行するため、はるかに軽量です）。

そして、それはフレームワークでの作業のようなものを意味します。コードにレイヤーが必要になるので、後でデータ抽象化レイヤーをリファクタリングしてパフォーマンスを向上させることができます。たとえば、一部のオブジェクトが別のデータベースにあることを教えることで、コードは認識したり気にしたりする必要がありません。

最後に、不要な文字列のコピーなど、メモリを大量に消費する操作に注意してください。PHPのメモリ使用量を抑えることができれば、Webサーバーのパフォーマンスが向上します。これは、負荷分散ソリューションに移行するときに拡張できるものです。

score 1 · Accepted Answer

すぐに MySQL から切り替えるとは思えないので、PDO の抽象化機能は必要ないと思います。これらの記事に感謝します DavidM, 彼らは私を大いに助けてくれました.

score 1 · Accepted Answer

@ゲイリー

MySQLi を使用しないでください -- PDO は「最新の」オブジェクト指向データベースアクセスレイヤーです。使用する最も重要な機能は、クエリのプレースホルダーです。サーバー側の準備やその他の最適化も使用できるほどスマートです。

私は現在 PDO について調べていますが、あなたの言う通りのようです。しかし、MySQL が PHP 用の MySQLd 拡張機能を開発していることは知っています。

@ライアン、エリック、tj9991

PHP のキャッシング拡張機能についてアドバイスをいただきありがとうございます。どちらか一方を使用する理由を説明していただけますか? IRC を通じて memcached について素晴らしいことを聞いたことがありますが、APC については聞いたことがありません。それらについてどう思いますか? 複数のキャッシングシステムを使用することはかなり逆効果だと思います。

私は間違いなくいくつかのプロファイリングテスターを整理します-それらについてのあなたの推薦に感謝します.

score 1 · Accepted Answer

ASP.NET の出力キャッシュと同様に、Apache Web サーバーの出力キャッシュである mod_cache を調べます。

はい、まだ実験段階ですが、いつかは完成するでしょう。

score 1 · Accepted Answer

大量のデータを扱っていて、キャッシュがうまくいかない場合は、Sphinx を調べてください。SphinxSearch を使用することで、優れたテキスト検索だけでなく、より大きなテーブルを扱う場合の MySQL のデータ検索の代替としても素晴らしい結果が得られました。SphinxSE (MySQL プラグイン) を使用すると、キャッシングによるパフォーマンスの向上を数回上回り、アプリケーションの実装は面倒です。

php - 高負荷サイトでPHPを使用するための戦術

データベース

キャッシング

ついに

23 に答える 23

データベース

キャッシング

Related

Reference