我應該用什麼webserver/mod/technique來提供內存中的所有內容？

Question

我有很多lookuptables，我將從中生成我的web響應。

我認爲IIS與Asp.net使我能夠在內存中保持靜態查詢表，我可以用它來快速提供我的響應。

是否也有非.net解決方案可以做到這一點？

我看過fastcgi，但我認爲這啓動了X進程，任何人都可以處理Y請求。但是這個過程被定義爲相互隔離。我可以配置fastcgi只使用一個進程，但這是否有可擴展性的影響？

任何使用PHP或任何其他解釋語言的東西都不會飛，因爲它也是cgi或fastcgi綁定的權利？

我知道memcache可能是一個選項，雖然這將需要另一個（本地）套接字連接，我寧願避免，因爲內存中的所有內容都會更快。

該解決方案可以在WIndows或Unix下工作......這並不重要。唯一重要的是會有很多請求（現在每秒100 /秒，一年增長到500 /秒），我想減少處理它所需的網絡服務器數量。

當前的解決方案是使用PHP和memcache（偶爾命中SQL服務器後端）完成的。雖然速度很快（無論如何，PHP），但當50/sec通過時，Apache會遇到實際問題。

由於我沒有看到足夠的反應來作出明智的選擇，所以我在這個問題上給了一個獎勵。

目前我正在考慮Asp.net或fastcgi與C（++）。

Answer 1

這聽起來像你應該使用像Redis這樣的內存中鍵值數據存儲，如果你打算將來有多臺Web服務器，那麼你肯定會使用集中式內存存儲。 Redis在這種情況下尤其理想，因爲它支持高級數據結構，如列表，集合和有序集合。它的速度也非常快，它可以在入門級Linux機器中獲得110000 SETs /秒，81000 GETs /秒。 Check the benchmarks。如果沿着這條路線走，我有一個c# redis client可以簡化訪問。

爲了使用共享內存，您需要一個在相同進程中始終運行的應用程序服務器。在這些情況下，您可以使用靜態類或共享的「應用程序」緩存。最受歡迎的'應用程序服務器'是任何Java servlet容器（例如Tomcat）或ASP.NET。

現在移動到訪問內存而不是磁盤會產生顯着的性能節省，如果這個性能對你來說很重要，那麼我認爲你不想考慮使用解釋型語言。處理請求時總會有開銷，網絡IO，解析協議，設置工作線程等。決定使用一個進程外（在同一主機上）的共享內存存儲與內存相比是微不足道的比較完成請求所需的總時間。

Answer 2

首先，讓我再想想你在你的直接的問題：

- 對於你瞄準的表現，我要說的是苛刻的共享內存訪問查找 - 表是矯枉過正。例如，memcache開發人員對預期的性能表示：「在高速網絡（或本地訪問）的快速機器上，memcached可以輕鬆處理每秒200,000個以上的請求。「

- 您目前可能會受到cpu-time的限制，因爲您正在動態生成每個頁面，如果可能的話：cache，cache，cache！緩存您的首頁並每分鐘或每五分鐘重建一次。登錄的用戶，緩存他們可能會在他們的會話中再次訪問的用戶特定的頁面，例如：每秒50個請求對於動態頁面來說不算太差，反向代理（例如清漆）可以爲靜態頁面服務thousands a其次一個姿色平平的服務器上我最好的暗示將考慮使用varnish或squid設立一個反向代理

- 如果你仍然需要動態地生成大量的頁面，使用php accelerator以避免編譯php代碼每次腳本運行時根據w ikipedia，這是一個2到10倍的表現增加。

- mod_php是運行php的最快方式。

- 除了使用fastcgi之外，你可以編寫一個apache模塊，並將你的數據與webserver本身共享memoryspace。這可能非常快。但是，我從來沒有聽說過有人這樣做來提高性能，而且這是一個非常不靈活的解決方案。

- 如果你走向更多的靜態內容或走fastcgi方式：lighthttpd比apache更快。

- 仍然不夠快？ in-kernel webservers如TUX可以非常快。

其次：你不是第一個遇到這個挑戰的人，幸運的是一些大魚很友善地與我們分享他們的「技巧」。我想這超出了你的問題的範圍，但看到這些人如何解決他們的問題真的很令人鼓舞，我決定分享我所知道的材料。

看看facebook架構上的this演示文稿和this關於'構建可伸縮的web服務'的演示文稿，其中包含關於flickr設計的一些註釋。

此外，Facebook列出了他們已經開發和貢獻的impressive toolset，此外，他們在他們的architecture上分享筆記。他們的一些性能提升技巧：
- memcache的一些性能改進自定義設置，例如memcache-over-udp。
- hiphop是一個php-to-optimized-C++編譯器。 Facebook工程師宣稱cpu使用率降低50％。
- 以「更快語言」實現計算密集型服務，並使用thrift將所有內容連接在一起。