PHPでは、スケーラビリティを考慮してどのようにコーディングしますか？
これは一般的な質問かもしれませんが、今後数か月間でなくても、遭遇するすべてのユーザーにとって正確に何がスケーリングされるのでしょうか？私はいくつかの調査を行いましたが、行われることのほとんどはサーバー側で、キャッシュやその他の類似のものを使用しています。正しい方向の任意のポイントが参考になります。
「今後数か月でなくても」時期尚早な最適化のようなにおいがします。それをしないでください：
それはそれだけの価値はありません。多くの人々は、プロジェクトを実現するとき、彼らのプロジェクトが2番目のFacebookになると信じています。それから彼らはそれをリリースし、そして毎月10人の訪問者が彼らができる最善であることに気づきます。さらなるスケーラビリティのための最適化に費やす費用と時間を節約し、プロジェクト自体についてより多くの時間を費やすことが役立つでしょう。
それはボトルネックとプロファイリングのようなものです。ボトルネックがどこにあるかを完全に理解しているという印象を常に持っています。ほとんどの場合、プロファイリングのときに自分が間違っていたことがわかります。最初にアプリケーションを実行します。使い方をご覧ください。それをプロファイルします。 BIデータを収集します。パフォーマンスメトリックを収集します。それを分析します。分析が正しいかどうかを確認します。分析に基づいて将来について予測し、実際に最適化する必要があるものをスケーラビリティーのために最適化します。
たとえば、スケーラブルなWebアプリケーションは、複数のサーバーでホストできる必要があります。私の顧客のために私が最後に行ったプロジェクトは、スケーラブルであるように意図されていました。選択肢がありました。Webアプリを複数のサーバーで動作させるために1.5か月以上費やすか、または顧客が高品質のサーバー（1台のマシンのみ）を購入し、Webアプリがこのマシンのみでホストされているかのどちらかです。直接コスト（サーバーの価格対作業期間1.5か月の価格）と長期的な節約（1台の高品質サーバーの電力消費量と数台の低電力消費量）の両方を考慮して、高価なサーバーを購入する方がはるかに安価でした-エンドサーバー）。これで、アプリは数か月間実行され、メトリックによると、1日のスケーラビリティに問題がある場合、最初にデータベースに、次にネットワークインフラストラクチャ（スイッチ、ルーターなど）に関係します。 ）。
現在、アプリケーションはいくつかの点で多かれ少なかれスケーラブルです。
データベース：私の個人的な経験によると、ほとんどのスケーラビリティ関連の問題はデータベースに起因しています。うまくいけば、すべての業界グレードのデータベースエンジンに対してデータベースをスケーラブルにする方法はたくさんあります。それ以前でも、データベース構造を改善するや最適化する方法はたくさんあります。クエリ。 キャッシュも役立ちます。
ネットワーク：一部の構成では帯域幅が実際の問題になる可能性があり、場合によっては、余裕のない出費をせずにそれについて何もできないことがあります。このレベルでブロックされないようにするには、Webサイトのビジュアルデザインを最適化する少ない画像またはより良い圧縮画像を使用して最適化しますページのレイアウト、HTTPリクエストの削減（CSSスプライトを使用）、送信されるHTMLコードの量の削減（[〜＃〜] ajax [〜＃〜]を使用 ）などHTTP圧縮は必須です。 ブラウザキャッシングも、しかし、多くのクライアントが空のキャッシュを持っていることをメトリックが示すかもしれません。
CPUとメモリの使用状況：インフラストラクチャ（ハードウェア）レベルとアプリケーション（ソフトウェア）レベルの両方で、複数のサーバーでホストされるようにアプリケーションを移植することも困難な場合があります。これを回避するには、広範なcachingを使用してアプリケーションのプロファイルを作成し、bottlenecksを徐々に削除します。
スケーラビリティは言語にとらわれないため、PHP固有のことはありません。重要な要素は、サブシステムを分離し、言語にとらわれないプロトコルを介して通信することです（たとえば、 your PHPコード、PHPのserializeではなくJSONを使用します。両方のコンポーネントが現在両方ともPHPで実装されている場合でも同様です。これにより、コンポーネントを他のコンポーネントに置き換えることができます。おそらく他の技術で開発された代替案。
highscalability.com ブログで、 PHPを使用して実装されたスケーラブルなアーキテクチャ の多くの例を見つけることができます
現在、スケーラビリティについて心配することは価値がないでしょう。プロジェクトが離陸し、ハードウェアを追加して拡張できないところから目標に達した場合、より徹底的な対策のために十分な資金が投入されます。そうでない場合、今行っている努力は時間とリソースの浪費です。
そうは言っても、アプリケーションを維持するためにできることとすべきことはいくつかありますmaintainable。これらのガイドラインに従えば、ゲームの後半でスケーラビリティを考慮に入れることがはるかに簡単になります。理想的なソリューションでは、プログラムロジックに最小限の変更を加えるだけで、プレゼンテーションコードにまったく変更を加えることなく、データストレージコード全体を交換できます。