2009-05-03 44 views
2

我必須構建一個類似於「分支/商店定位器」的Web應用程序。用戶輸入他的地址,網絡應用程序將在地圖上繪製附近的商店。以5 GB /天的傳輸量設計Web應用程序的注意事項?

的要求之一是:

「Web應用程序必須支持100個併發用戶和高達5GB /天的傳輸量。」

大部分傳輸的數據將是文本和GUI圖像。

所以我的問題是:

  1. 這被認爲是一個高流量的應用程序?
  2. 我可以尋找可比較流量的Web應用程序/站點嗎?
  3. 我是否需要實現像memcached,模板緩存,加載服務器平衡等......?

我曾經在高流量的應用程序工作過,但我從來沒有建築師。因此,儘管我知道一些(並非全部)管理高流量場景的策略,但我並不熟悉它們的實際實施。

有人可以給我建議,反饋或建議的研究?我忽略了什麼?

**另外,我正在用Smarty構建LAMP。

回答

1

這僅僅是每秒60kb(假設運行時間超過24小時),但在繁忙時間您可能會發生突發事件,因此您需要能夠處理該事件。即使對於基於Apache的較老的服務器,同時使用100個用戶也是如此。

我不確定memcached是否真的會幫助你,但它的值得添加,因爲你的PHP cahcing是APC,我至少會設計它能夠負載均衡 - 請檢查ultramonkey關於如何透明地實現這一點的一些很好的文檔,您需要確保任何進入的用戶會話都不會以每個主機的方式存儲其會話數據;您需要考慮用戶在一次調用中擊中了鉛平衡服務器A,然後在另一次擊中服務器B時會發生什麼情況。 (即將用戶標識和數據存儲在數據庫中,而不是存儲在文件系統中)。

1

在100Mbps的鏈接,您可以傳送多達

100 * 60 * 60 * 24/1024/8 = 1054 GB per day 

5GB /日表示,大約有0.5%,所以我不認爲你必須關心在這種秤的流量,因爲有這麼在這之前很多事情可能會成爲你的瓶頸(JavaScript,數據庫訪問等)。此外,一旦你知道你有足夠的可用帶寬,在編寫(和基準測試)你的應用程序之前,你不應該關心這些事情,因爲這可能導致過早的優化。

我發現Django書中的scaling部分作爲該領域的一般知識很有趣。

+1

JavaScript作爲服務器端瓶頸? – Calvin 2009-05-03 14:11:53

相關問題