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