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

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

データベース

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

キャッシング

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

これに関する私の質問：

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

最後に

PHPで高負荷のサイトを実行するためのヒント/ポインタはありますか？私はそれが使える実用的な言語だと確信しています-FacebookとYahoo! 優先順位を高くしますが、気を付けるべき経験はありますか？

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

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

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

データベース

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

キャッシング

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

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

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

ここでのトレードオフは、冗長データを格納/プルすることですが、データとケージ内の帯域幅は非常に安価で（ディスクが大きい）、複数の準備I / Oは桁違いに高価（サーバーが多い）ので、これは許容できます。 。

INDEXINGは、 必ずあなたのクエリが少なくとも一つの指標を利用することを確認します。ただし、書き込みや更新を頻繁に行うと、インデックスにコストがかかることに注意してください。これを回避するための実験的なトリックがいくつかあります。

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

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

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

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

私が作業している店では、ビジネスレイヤーキャッシングを使用しています。つまり、システム内の各具象クラスが、独自のキャッシングスキーマとキャッシュタイムアウトを制御しています。これはかなりうまくいきましたが、DBから取得したアイテムはキャッシュからのアイテムと同じではない場合があるため、キャッシュとDBを一緒に更新する必要があることに注意してください。

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

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

これの欠点は、複数のシャードのデータをつなぎ合わせることが難しい場合があることです。しかし、それを回避するように設計することもできます。

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

私は、PHPとMySQLに支えられて数百万/月/ヒットを得るいくつかのサイトで働いてきました。ここにいくつかの基本があります：

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

Build Scalable Websitesを読むことをお勧めします。これはFlickrエンジニアの1人が作成したもので、優れたリファレンスです。

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

Re：PDO / MySQLi / MySQLND

@ ゲイリー

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

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

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

@ross

最新のMySQLコア言語レベルライブラリであるMySQLndは正しいですが、MySQLiの代わりにはなりません。MySQLi（PDOと同様）は、PHPコードを通じてMySQLと対話する方法のままです。これらはどちらも、PHPコードの背後にあるCクライアントとしてlibmysqlを使用します。問題は、libmysqlがコアPHPエンジンの外にあり、mysqlndが入ってくる場所、つまりコアのPHP内部を利用して効率を最大化するネイティブドライバーであり、特にメモリ使用量が関係していることです。

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

そうは言っても、MySQLnd はPHP 5.3 for PDOで利用できるようになり、NDからPDOへのパフォーマンス強化の利点を得ることができますが、PDOは依然として汎用データベースレイヤーであるため、 MySQLiで可能なNDの拡張。

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

MySQLiとPDOのどちらを使用するかを決定する際には、考慮すべき多くの考慮事項があります。実際には、リクエスト数が非常に多くなるまで問題になりません。その場合、抽象化してMySQLドライバーを提供する拡張機能ではなく、MySQL用に特別に設計された拡張機能を使用する方が理にかなっています。 。

それぞれに長所と短所があるため、どちらが最善であるかは単純なことではありません。あなたは私が提供したリンクを読んであなた自身の決定を思い付く必要があり、そしてそれをテストして見つけ出す必要があります。私は過去のプロジェクトでPDOを使用しましたが、それは良い拡張ですが、純粋なパフォーマンスのための私の選択は、新しいMySQLNDオプションがコンパイルされたMySQLiです（PHP 5.3がリリースされたとき）。

一般的な

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

コード

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

データベース

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

キャッシング

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

雑多

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

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

Xdebugを実行してプログラムのボトルネックを見つけることも強くお勧めします。最適化が簡単になりました。

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

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

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

サーバー間でデータベースを分割し、なんらかの負荷分散手法を使用して（たとえば、1から＃までの乱数を生成し、必要なデータを使用して冗長データベースを作成し、その番号を使用して接続先のデータベースサーバーを決定する）ことも、優れた方法です。効率。

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

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

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

PHP用のあらゆる種類のオペコードキャッシュ（APCまたは他の多くのいずれかなど）も同様に役立ちます。

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

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

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

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

価値のあることとして、キャッシングは、memcachedのような拡張機能/ヘルパーパッケージがなくても、PHPでのダートシンプルです。

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

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

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

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

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

PHPのキャッシング拡張に関するアドバイスをありがとう-重ねて使用する理由を説明してくれませんか？IRCを通じてmemcachedについて素晴らしいことを聞いたことがありますが、APCについて聞いたことがありません。それらについてのあなたの意見は何ですか？複数のキャッシュシステムを使用することは、かなり効果が低いと思います。

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

間違ったようです。MySQLiはまだ開発中です。しかし、記事によると、PDO_MySQLは現在MySQLチームによって提供されています。記事から：

MySQLの改良された拡張機能-mysqli-はフラグシップです。これは、Charsets、Prepared Statements、およびストアドプロシージャを含むMySQLサーバーのすべての機能をサポートします。ドライバーはハイブリッドAPIを提供します。好みに応じて、手続き型またはオブジェクト指向のプログラミングスタイルを使用できます。mysqliにはPHP 5以降が付属しています。PHP 4のサポート終了は2008-08-08であることに注意してください。

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

これまでに公開されたPHP用の最初のMySQLドライバーの使用を停止してください：ext / mysql。MySQLの改良された拡張機能-mysqli-がPHP 5で2004年に導入されて以来、最も古いドライバを使用する理由はありません。ext / mysqlは、Charsets、Prepared Statements、およびStored Proceduresをサポートしていません。MySQL 4.0の機能セットに限定されます。MySQL 4.0の延長サポートは2008-12-31に終了することに注意してください。そのような古いソフトウェアの機能セットに制限されないでください！mysqliにアップグレードします。Converting_to_MySQLiも参照してください。私たちの観点から見ると、mysqlは保守専用モードです。

私には、この記事はMySQLiに偏っているようです。私はPDOに偏っていると思います。MySQLiよりもPDOが本当に好きです。それは私には簡単です。APIは、私がプログラミングした他の言語に非常に近くなっています。OOデータベースインターフェイスの方がうまく機能しているようです。

PDOで利用できなかった特定のMySQL機能に出会ったことはありません。私がやったことがあったら、私は驚きます。

PDOも非常に遅く、そのAPIはかなり複雑です。可搬性が問題にならない場合、正気の人はそれを使用すべきではありません。そしてそれに直面しましょう、すべてのウェブアプリの99％ではそうではありません。MySQLやPostrgreSQLなど、作業しているものは何でも使用できます。

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

確かにPDOはいいですが、そこにい れて 、いくつかのそれは今固定思われるが、MySQLとmysqliの対それのパフォーマンスに関する論争。

移植性を想定している場合はpdoを使用する必要がありますが、そうでない場合はmysqliを使用する必要があります。OOインターフェース、準備されたステートメント、およびpdoが提供するほとんどの機能（移植性を除く）があります。

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

クラスター化されたサーバー（およびYouTubeのような負荷）がある場合はMemcacheが適していますが、私も最初にAPCを試します。

すでに多くの良い答えが出されていますが、XCacheと呼ばれる代替のオペコードキャッシュを紹介したいと思います。それは軽い貢献者によって作成されます。

また、将来データベースサーバーのロードバランシングが必要になる可能性がある場合、MySQLプロキシはこれを実現するのに非常に役立ちます。

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

最初の質問は、どれくらいの大きさになると本当に期待していますか？また、インフラストラクチャへの投資をどのくらい計画していますか。ここで質問する必要があると感じているので、限られた予算で少額から始めることを期待していると思います。

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

この段階で異なるデータベースノード間でデータをパーティション分割することは非常に悪い考えです。ただし、同じサーバー上の異なるデータベース間でデータを分割することを検討することをお勧めします（Facebookを追い抜くときにノード間でのパーティション分割を容易にします）。

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

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

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

サイトとそのログを調査するのに十分な時間をかけて、サイトが非常に遅くなる理由を理解してください。

できるだけ多くのキャッシュをクライアントにプッシュします。

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

C.

私の最初のアドバイスは、この問題について考え、サイトを設計するときにそれを覚えておくことですが、やり過ぎることはありません。多くの場合、新しいサイトの成功を予測することは困難であり、私はあなたの時間を早く完成させ、後でそれを最適化することに費やす方が良いでしょう。

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

基本的なサイトを立ち上げて実行したら、テストを行って、どこに努力を費やすべきかを示します。ターゲットとする場所を確認することは困難です。多くの場合、速度を上げるためにコードの複雑さを解明する必要があります。これにより、コードが大きくなり、保守が困難になるため、必要な場合にのみ実行する必要があります。

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

@ ゲイリー

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

私は現在PDOを探していますが、それはあなたが正しいようです-しかし、MySQLがPHP用のMySQLd拡張を開発していることは知っています-私はMySQLまたはMySQLiのどちらかを成功させると思います-それについてどう思いますか？

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

PHPのキャッシング拡張に関するアドバイスをありがとう-重ねて使用する理由を説明してくれませんか？IRCを通じてmemcachedについて素晴らしいことを聞いたことがありますが、APCについて聞いたことがありません。それらについてのあなたの意見は何ですか？複数のキャッシュシステムを使用することは、かなり効果が低いと思います。

私は間違いなくいくつかのプロファイリングテスターを整理します-それらのあなたの提案をありがとうございました。

私は自分がMySQLからすぐに切り替わるとは思っていません。そのため、PDOの抽象化機能は必要ないと思います。それらの記事DavidMをありがとう、彼らは私をたくさん助けてくれました。

見mod_cacheに ASP.NETでの出力キャッシュにsimillar、Apache Webサーバーの出力キャッシュ、。

はい、まだ実験段階ですが、いつかは最終的なものになるでしょう。

モジュール化と抽象化について、誰もこれに言及していません。あなたのサイトは、多くのマシンに成長しているつもりされたと思われる場合は、必要、それができるようにそれを設計し！つまり、データベースがlocalhostにあると想定しないなどの愚かなことです。また、データベースアブストラクションレイヤー（PDOのようなものですが、必要なことだけを実行するのではるかに軽量です）を書くなど、最初は面倒なことにもなります。

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

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

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

キャッシュに関して指摘された点はスポットオンです。これは、効率的なアプリケーションを構築する上で最も複雑でなく最も重要な部分です。memcachedは優れていますが、アプリケーションが単一のサーバー上にある場合、APCは約5倍速くなります。

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