我一直希望找出不同的服務器設置在理論上等同於併發頁面請求，並且答案總是似乎浸透在巫術和魔法中。以下設置的最大併發頁面請求的近似值是多少？併發頁面請求比較
阿帕奇+ PHP + MYSQL（1服務器）
阿帕奇+ PHP + MYSQL +緩存（像分佈式緩存或similiar（仍然一個服務器））
阿帕奇+ PHP + MYSQL +緩存+專用數據庫服務器（2個服務器）
阿帕奇+ PHP + MYSQL +緩存+ dedicatedDB +負載平衡（多網絡服務器/單DBSERVER）
的Apache + PHP + MYSQL +緩存+ dedicatedDB +負載平衡（多Web服務器/多DBSERVER）
+分佈式（Amazon雲彈性） - 我知道這個人是「儘可能多的，你可以負擔得起「，但很高興知道什麼時候該採取行動。我非常感謝任何有建設性的批評，我只是想弄清楚什麼時候從一個實現轉移到下一個，因爲他們每個都有自己的實現專長，無論是編程明智的或設置明智的。
在您的問題中，您將討論緩存，這可能是Web架構性能和容量中最重要的因素之一。
Memcache很有用，但實際上，在此之前，您應該確保服務器響應中的HTTP緩存指令正確。這有兩件事。它減少了請求的數量，並加快了服務器響應時間（如果Apache配置正確）。這也可以通過使用像Varnish和CDN這樣的HTTP加速器來改進。
要考慮的另一個因素是您的系統是否是無狀態的。通過無狀態，它通常意味着它不會在服務器上存儲會話並在每個請求中引用它們。一個好的系統架構儘可能地依賴於狀態。狀態越少，系統的水平可擴展性越高。大多數人在面對個性化問題時都會引入狀態 - 即爲不同的用戶提供不同的內容。在這種情況下，您應該首先使用HTML5會話存儲進行調查（即將完整的用戶數據存儲在客戶端的javascript中，顯然通過https存儲），或者數據集較小，安全的JavaScript cookie。這樣，您仍然可以提供緩存資源，然後使用JavaScript在客戶端上進行個性化設置。
最後，您的堆棧包含一個數據庫層，另一個潛在的性能和容量瓶頸。如果您只是從系統中讀取數據，那麼它應該很容易橫向縮放。如果有讀寫操作，通常最好將讀寫數據集分成單獨的數據庫，並且只讀取另一個數據庫。然後您可以使用更多相關的方法進行縮放。
這些設置不會吐出一個答案，然後您可以相互比較。答案會因您所列的因素而異。
即使他們確實吐出了一個答案，那麼它只是幾十個中的一個。是什麼使這成爲最重要的指標？
更糟的是，這些替代方案中的每一個都不是免費的。這些都有工程設計和維護費用。如果不瞭解您的組織，您的應用和您的成本/收入結構，就無法分析。
像AWS這樣的選項不僅涉及開發工作，而且可能會「鎖定」到某個解決方案，因此您還需要了解這一點。
我知道這個回答並不完整，但我指出這個問題涉及到一個大的複雜領域，不能簡化爲一個度量標準。
我懷疑你是從完全錯誤的一端接近這個。不要去尋找技術，然後找出如何使用它們。取而代之的是分析你的應用（測量，測量，測量），找出你遇到的實際問題，然後解決問題和問題。
如果您瞭解問題並瞭解技術選項，那麼您應該有一個答案。
如果你已經做到了這一點，問題是併發頁面請求，然後我提前道歉，但我懷疑不是。
我肯定意識到這樣的事實，即每個這些選擇都不是自由的，這使得決定向上移動變得更加困難，但是我實際上試圖用手指猜測（字面上用我的大拇指估計）最初是基於（而不僅僅是）估計的負載來實現的。這並不容易，因爲該產品仍在開發中，並且沒有測試數據，這就是爲什麼這是我試圖編譯的**許多**指標之一，以幫助我做出決定，而且我找不到一個好的「猜測範圍「回答這個問題，所以我想知道社區是否可以提供幫助。 – Ryan
我絕對感謝你的意見。我想實際上我只是在尋找「apache + mysql + base設置可能50-100個併發頁面請求」，如果我沒有找到答案，我可能會嘗試自己進行基準測試，爲了比較起見（雖然我明白這裏有很多變數，我會盡量減少它們，但是，嘿，我從來沒有見過一個基準，我不能分開，所以我不認爲我的將是任何不同） – Ryan
謝謝，我真的很感激輸入。 – Ryan