爲了客戶及其受衆的利益，提高我們技術的性能是Verizon Media (現爲Edgio)的一項持續行動。 例如，在過去兩年中，我們的性能和內核工程師幾乎消除了所有數據包丟棄(移除98%以上)，將邊緣伺服器上的性能執行狀況檢查提高了50%，並將伺服器容量提高了40%。
我們還將上述內容與網路自動化和有機網路擴展相結合(目前超過250 Tbps)，以改善用戶體驗。 在我們爲數百萬個遊戲機提供軟體更新，爲重大體育賽事提供實時影片流，以及當多CDN負載平衡器將負載轉移到我們的網路時，我們的性能在支援快速變化，有時不可預測的網路浪湧方面發揮了重要作用。
大規模維護質量涉及 優化Edgio Media Platform技術堆棧的每個部分的性能 ：從CPU和NIC的較低層到操作系統和應用程式。 最終，我們的目標始終是相同的：卓越的績效。 爲了實現這一目標，我們執行數據驅動型分析，依靠可衡量的性能變化來驗證我們的決策。
CPU高速暫存優化
我們在全球執行20,000臺伺服器，主要是Broadwell和Haswell晶片組，通常具有32至40個內核。 僅在過去三年中，我們就增加了12,000臺伺服器。 但是，大多數伺服器並未針對開箱即用的工作負載進行優化。 簡單地添加更多伺服器並不能提高操作效率，也會帶來更多挑戰。 有效的擴展需要對現有組件進行仔細優化。 如果能夠優化一臺伺服器，使其能夠處理比預設配置更多的兩到三倍(或更多)請求，就會大大影響網路的整體性能。
從早期snoop切換到home snoop
現代CPU採用snoop協議來保證本地CPU高速暫存與記憶體保持一致。 這樣，高速暫存可以偵聽對任何CPU上的變量的修改，並相應地更新這些變量的版本。 毫不奇怪，所使用的特定技術會顯著影響記憶體性能。
預設情況下，我們的硬體供應商使用名爲Early Snoop的協議。 解決高速暫存一致性的延遲較低，因爲所有內核都可以同時發出高速暫存一致性請求並發送廣播。 我們發現，在高峯負載情況下，我們的系統會同時生成大量的磁碟和NIC活動。 這些活動會導致高snoop廣播，導致通信瓶頸。 這會導致IO設備速度緩慢，最終導致處理完全停止。
通過切換到Home Snoop模式(一種合併snoop請求的方法)，我們發現廣播通信量顯著減少。 在同時執行大量磁碟和網路IO操作期間，處理器的快速通道互連(QPI)已不再缺乏；此外，我們在早期Snoop中看到的數據包丟棄顯著減少。
更改snoop協議只取決於更改BIOS設定。 但是，在不中斷客戶的情況下重新啓動20,000臺伺服器需要自動化。 我們可以通過基於StackStorm的IT自動化平臺(小龍蝦)在生產中實現這種大規模部署更改。
意外故障轉移事件
在測試切換到Home Snoop時，發生了故障轉移：我們最大的媒體客戶之一( 部署了多CDN)遇到了另一家供應商的問題，並將其大部分流量轉移到我們的CDN。 這提供了一個機會來測試大規模的Home Snoop改進,這是非常有影響力的。
上圖顯示了更改的效果。 該組仍在使用早期Snoop，下降幅度增加了13.75倍(每臺伺服器每天有55K個數據包丟棄)，而切換到Home Snoop的組只增加了4.23倍(每臺機器每天有27K數據包丟棄)。 Home Snoop在故障轉移事件期間立即證明其價值。
網路接口優化和驅動程式調整
另一組重要的性能調整涉及網路接口和驅動程式。 在這裏，我們着重於減少通常與突發流量一起發生的數據包丟棄。 在大型事件中，入站流量太大，以至於NIC無法跟上，而且我們發現數據包比預期的更快丟失。 在深入瞭解原因時，我們發現網卡上的幾個參數需要調整，包括隊列數，隊列大小和中斷調度。 爲了針對我們的特定工作負載和硬體配置優化這些規範，我們集中精力調整接收端擴展(RSS)，方法是延長入站隊列的時間，減少其總數量，並平衡NUMA節點之間的中斷。
上圖顯示了我們在北美執行的一個測試,其中每個流行分爲一個控制組(即未調諧)和一個測試組(即調諧)。 在這裏，我們展示了一週內每天的滴數。 經過調整後，我們的測試組比控制組減少了大約95%的數據包丟棄率，從而可以處理更多的請求。 這也意味着在浪湧期間手動管理網路執行狀況所需的操作更少，使我們的工程師可以專注於其他領域。
CPU調度調整
雖然NIC和驅動程式級別調整集中在提高我們可以提供的總容量上，但CPU調度調整集中在提高我們交付內容的一致性上。
如果沒有這些調整，入站和出站消息就必須爭奪資源。 當我們開始調查根本原因時，我們發現資源爭用是由內核如何調度這些消息的處理引起的。 這意味着在峯值流量期間，負載不會移走，直到有問題的CPU達到飽和。 爲了解決此問題，我們將Web伺服器進程的CPU關聯性設定爲排除專用於處理傳入網路流量的CPU。
上圖顯示了3月21日至22日在整個CDN中啓用CPU調度調整的影響。 我們根據性能執行狀況檢查指標的第95百分位數和中位值來評估影響，該指標是一個顯示伺服器相對響應時間的綜合指標。 正如預期的那樣，低流量的山谷沒有顯著減少；但是，峯值顯示出大幅減少了傳入和傳出流量之間的爭用。 這意味着離羣值和中間值都有重大改進，尤其是在峯值負載期間。 現在，我們可以更好地處理流量激增的問題，並消除與高異常行爲相關的問題，例如影片流中的重新緩衝區或伺服器對所有用戶的整體響應。
內核性能更新
優化我們的技術堆棧的上層與優化下層元素同樣重要。 在最近升級操作系統的過程中，我們還升級了Linux內核，以利用Linux內核社羣的上游工程工作。 新內核比部署的前一版本有大約四年的開發,包括改進記憶體管理系統,減少阻塞頁面分配,並改善負載分佈和使用epoll API和套接字分區時的性能。
在上圖中，您可以看到從11月底到1月初的升級過程的影響，這是第99百分位數性能狀況檢查的下降。 基礎內核改進使我們所有的Web伺服器請求處理器的負載分佈更加均勻。 這導致這些異常值大幅下降，使我們所有客戶的請求更加可靠。
性能調整具有顯著的影響
在過去兩年中，性能和內核工程所部署的影響深遠的系統調整幾乎消除了所有數據包丟棄(刪除了98%以上)，並將我們在邊緣伺服器上的性能執行狀況檢查減半。 我們的伺服器容量增加了10–40%(具體數量因客戶情況和事件而異)，使我們能夠更快地交付更多流量。 異常行爲已顯著改善，從而獲得更一致的體驗，我們看到媒體的良好改善，尤其是在高峯負載期間。 總之， 對整個技術堆棧的性能優化 使我們能夠更好地處理任何意外流量峯值(無論是來自高度預期的遊戲控制檯更新還是流行的流媒體影片直播活動)，併爲所有用戶提供更一致的性能。
