Akamai 與較小的 CDN 用於中小型電子商務流量？（記憶體、延遲、NetStorage）
我工作的中小型線上零售公司使用 Akamai 作為我們的靜態圖像 CDN，但我想知道它是否會傷害而不是幫助，如果它不是最理想的，我們應該做什麼。
我們每月獲得約 300 萬次網頁瀏覽量和 40 萬獨立訪問者。我們有 100k+ 不同的靜態圖像出現在我們的各種網頁中（幾千種產品中的每一種都有幾種不同的圖像，等等）。
問題在於，Akamai 的伺服器從原始伺服器（我們自己託管）請求文件，約佔所有瀏覽器請求的 40%。這意味著（在我看來）很多不必要的等待我們的客戶：所有請求中有 40% 必須在 Akamai 和我們的原產地之間進行往返，然後才能返回給客戶。
伺服器 TTL 不是問題；它們都設置為 365 天。所以看起來要麼
- Akamai 的邊緣伺服器沒有將我們的內容在記憶體中保存足夠長的時間，然後才將其換出以支持流量高於我們的內容，和/或
- 有如此多的 Akamai 邊緣伺服器（他們聲稱全球超過 7 萬台），以至於每台伺服器都無法從我們每月 45 萬的訪問者那裡獲得足夠的流量來建立我們文件的大部分記憶體。
所以我開始想知道我們是否可以通過更少伺服器的 CDN 更好地服務，我的想法是使用更少的 CDN 伺服器，我們的更多圖像會更頻繁地記憶體在每台伺服器上，並且可能會在記憶體中停留更長時間沒有被換掉。另一方面，對於不靠近其中一台伺服器的使用者來說，更少的伺服器可能意味著更多的延遲。
我們正在研究兩個基於 Akamai 的選項，但尚未啟動（目前）：
- 我們還沒有使用他們的 NetStorage 服務，因為有一個技術障礙（如果我們朝這個方向發展，這將是我下一個 SF 問題的主題）並且因為 40% 的時間仍然會有額外的往返邊緣伺服器和來源；它只是在 Akamai 網路內的往返，而不是到我們單獨託管的來源——可能更快，但仍然是往返。
- 我們不為 Akamai 的可選分層分發服務付費。這可能會在很大程度上緩解這個問題，但是（1）它並不便宜，並且（2）同樣，40% 的時間在邊緣伺服器和它的層集線器之間仍然存在往返。
所以我的問題是：
- 你們是否認為將文件記憶體在更少的伺服器上會更好，但會為某些使用者帶來額外的延遲？還是延遲比原始往返更大？
- 如果我們使用 NetStorage，是否有人知道往返於 NetStorage“原點”通常需要多長時間？
- 我錯過了什麼嗎？我還應該在這裡考慮什麼？
將事情建立在事實而不是假設上總是更好。您的假設是，具有較少節點的 CDN 會較少訪問您的來源。為了測試這一點，我會：
- 在多個 CDN 上設置一個帳戶，這些 CDN 執行原始提取但具有“超級 POP”模型。Amazon CloudFront、MaxCDN 和 Voxel 浮現在腦海中。CacheFly 或許也是如此，儘管我認為如果沒有服務參與就無法進行原始獲取。LimeLight 開創了“超級流行”模式，但需要通過銷售歌舞來設置測試。
- 將您的 CDN 流量的一些具有統計意義的部分轉移到那些測試 CDN。這可能就像在 n% 的時間內完成的重寫規則一樣簡單，但是所有 CDN 的“內容組合”需要完全相同。您不能將其限制為靜態資產的子集，因為靜態資產的數量也可能會產生影響。也許在 Akamai 上保留 80% 的流量用於測試，然後為其他 CDN 做 5%。
- 使用您的網路伺服器日誌來衡量您從每個 CDN 看到的原始點擊量與發送到每個 CDN 的流量。
- 使用 pingdom 之類的工具來衡量每個 CDN 上各種靜態資產的全球響應時間。從您的來源解除安裝命中是 CDN 完成其工作的一個指標，但最終使用者延遲也很重要。
掌握了這些事實，您的決定將很容易。對於它的價值，我實際上認為您是對的：Akamai 可能只是為“較小”站點提供了太多節點。
請注意，一些較小的 CDN 會自動對所有內容使用分層模型；他們只是從一開始就是這樣建構的。在這樣的模型中，對特定邊緣節點的請求在記憶體未命中時被路由到“內部”節點。如果“內部”節點也有記憶體未命中，則它會路由到源點。我自己的測試表明 MaxCDN 以這種方式工作（例如，在阿姆斯特丹節點上對文件的第一次請求並不總是導致相應的原始獲取。所以它一定是從 MaxCDN 網路中的其他地方獲取文件）。