2014年7月更新

對於在Salesforce平台上實現應用程序的架構師或開發人員來說，在分析應用程序性能時，網路性能測試變得越來越重要。本指南涵蓋了幫助您識別風險並找到網路相關挑戰的解決方案的最佳實踐。

介紹

分析應用程序性能和運行性能測試是關鍵的「實驗室」活動，以驗證您的Apex和SOQL代碼是為可擴展性而優化的，Visualforce頁面設計是遵循最佳實踐的。但是，為了確保您的應用程序已經為現實世界做好準備，您還需要考慮到用戶將從具有不同級別網路連接的不同地理位置訪問它。作為架構師，您的任務是成功地啟動一個應用程序，即使使用這種網路變體，該應用程序也能運行良好。您肯定不希望在產品上線後聽到終端用戶說「為什麼我的頁面載入時間這麼長，而我的同事可以在一秒鐘內載入它?」繼續閱讀，學習最佳實踐，幫助您識別風險，並作為架構師找到解決網路相關挑戰的方法。

評估Salesforce用戶的網路性能

如果有人問「為什麼我的頁面載入時間這麼長，而我的同事可以在一秒鐘內載入它?」「用戶的設置可能不同，呈現內容的時間和大小也不一樣。」為了確保你在將蘋果和蘋果進行比較，並將重點放在網路上，你必須有一個理想的受控設置:

在兩個或多個不同的位置至少有兩個幾乎相同的終端(PCs)。在地理上更接近Salesforce數據中心(即:，以及其他遠程站點(例如。)。

使用相同的瀏覽器和用戶(或用戶集)訪問目標(例如，Visualforce頁面)，以排除儘可能多的變數。

使用相同的工具來度量時間(以下部分將對此進行解釋)。

在類似的時間範圍內運行測試，以評估與網路帶寬相關的問題，並多次排除緩存影響。

如果您無法訪問遠程位置來運行測試，那麼可以使用Charles或Shunra之類的工具以及netem和ipfw之類的實用工具來人為地添加延遲和帶寬限制，以模擬不同的網路環境。

一旦有了受控的測試設置，您就可以收集基準統計數據並使用它們來迭代地評估性能調優工作。不管你如何設置你的測試，或者你選擇使用什麼工具來運行它們，我們最終追求的是兩件事:

減少負載。

減少網路延遲。

為了簡單起見，我們將在下面幾節中逐一討論。但是，請記住，這兩者都要看，而不僅僅是一個。

減少負載

減少有效載荷的目標是減少網路時間。由於您正在測試和比較內容大小一致的相同頁面，因此在伺服器端和在客戶端呈現的時間應該非常相似。下載資源所花費的時間差異越大，與請求的總持續時間相比，它所佔的比例越大，通過檢查頁面設計和減少負載，您可能會得到更多的網路性能改進。

您不需要使用花哨的應用程序性能監視(APM)工具來評估負載。您可以使用免費的瀏覽器工具來收集關鍵指標。Chrome、Firefox和Internet Explorer都有類似的工具，它們可以為您提供從頁面請求發送到Salesforce到用戶感知到頁面被「載入」到整個呈現過程完成的時間的圖形表示。您還可以使用Fiddler或Charles等工具進行高級分析。

當這樣做時，不要太過迷於位元組大小，工具會顯示每個被下載的資源。交換數據不會按位(或按位元組交換數據)進行。它們以分組的形式通過電線傳送。例如，如果您處理了幾個映像文件以減少這裡和那裡的一些位元組，但是沒有看到性能有多大的提高，很可能是因為您沒有減少每個資源下載的數據包的實際數量。如果你有一個高度圖形化,動態頁面有很多資源,比如圖像、CSS或者JS文件,結合他們或拼接,然後削減他們可能會有更大的效果比減少一小部分的大小和仍然需要十(希望不是數百)資源並行下載。您還可以使用其他通用的web應用程序優化技術來最小化下載負載、減少往返行程和握手等。

更重要的是，確保檢查Visualforce性能最佳實踐，並在Salesforce1平台上構建高效的Visualforce頁面。例如，刪除不必要的Visualforce標記，這會增加頁面視圖狀態的大小。通過仔細選擇用戶所需的欄位和使用諸如分頁之類的技術，限制在頁面上載入和顯示的數據量。如果您有一個多步驟的嚮導應用程序，該應用程序將引導用戶遍歷一個流程，請考慮實現一個解決方案，使頁面之間的轉換成為無狀態。如果您有一個允許用戶使用大量欄位更新記錄的表單，那麼只發送delta信息，而不發送整個數據集。

減少網路延遲

當您通過優化應用程序來減少目標頁面的有效負載時，您還應該在得出結論之前查看網路層，您無法使最終用戶更接近Salesforce伺服器。

您可以使用諸如Traceroute (Traceroute)或更高級的工具來進行更深入的分析。在salesforce，我們有幾個第三方工具可以持續地監視和收集各種網路相關的度量，我們還可以根據需要部署這些工具，以便從遠程站點解決問題(請聯繫客戶支持以獲得幫助)。這些工具可以讓我們很好地了解RTT、BGP路由以及幫助發現問題區域的包丟失率等細節。下面幾節將解釋如何使用這些度量來確定如何減少網路時間。您最有可能參與您的IT、網路工程或ISP團隊，以獲取統計數據並進行深入分析。

減少延遲

使用Salesforce時，大多數瀏覽器頁面或移動應用程序請求都是突發的事務，每個請求都需要多次往返Salesforce伺服器，以建立連接、發送/接收數據，並確認交換的每個數據包。

從網路的角度來看，你應該注意兩個關鍵方面:

實例不是分布在多個數據中心(除了在地理遠程數據中心待命的災難恢復克隆之外)。換句話說，在任何特定的時刻，用戶事務都是連接到我們的數據中心的。

Salesforce.com採用與運營商無關的體系結構，它通過連接到多個行業領先的網路供應商，這些供應商直接位於每個數據中心邊界的邊緣，擁有高帶寬的骨幹。這提供了冗餘和靈活性，以便為通過Internet連接的用戶提供最佳的網路性能。

雖然由於用戶和Salesforce之間的地理距離而增加的延遲是固定的，但是可能有機會減少特定於用戶網路的「拓撲」延遲。確保你至少涵蓋以下內容:

優化BGP - BGP路由在確定數據包通過internet發送時的延遲方面起著重要作用。在極端的情況下，您的數據包可以通過更長的方式在全球發送到Salesforce，也可以跳過過多的中繼點，每次都增加了延遲。雖然優化BGP有時更像是一門藝術，而非科學，但我們在仔細研究和改變網路路由偏好之後，看到了巨大的收穫。使用網路監視和分析工具，比如千分之一和Appneta提供了發現問題的洞察力。

避免不穩定路徑——最短路徑不一定是最好的路徑。考慮由於網路穩定性問題的影響，如數據包丟失和數據抖動。如果任何一端在給定的時間範圍內都沒有收到預期的包(例如，放棄等待另一端的確認)，那麼它將重新提交最後一個包，然後等待多次，每次都乘以並增加總體延遲。由於RTOs和SRTTs的增加，地理延遲的影響變得更糟。與BGP分析類似，監視工具可以識別具有穩定性問題的路徑。基於調查，您可以與您的網路團隊和isp一起優化路由，以修復或避免已知的具有穩定性問題的路徑。這將導致數據包重新傳輸的減少，這意味著在冗餘的數據包交換上浪費的時間更少。

識別瓶頸——您的網路中可能存在一個正在增加延遲的中間設備。通過使用Wireshark之類的工具，並與您的IT/網路團隊和Salesforce支持緊密合作，包級跟蹤分析可能會發現與次優或在您的辦公室或託管數據中心中配置不當的設備相關的優化機會。您可能還會發現，除了salesforce提供的資源之外，對其他資源的訪問也顯示出性能問題。

避免重定向——每個重定向添加到整個RTT中，並導致許多往返重定向伺服器的往返，以完成SSL握手。評估並避免不必要的重定向。例如，啟用My Domain並將登錄請求指向My Domain URL，而不是常規登錄頁面。如果已經實現了SSO，請確保將SAML斷言發送回My Domain端點。請參閱本指南，了解可以應用於減少由於重定向造成的延遲的其他技術。

利用CDN

如果您有一個構建在Force.com站點上的公共頁面，並且沒有通過SSL提供服務，salesforce提供了一個緩存選項，允許您利用我們合作夥伴的內容交付網路(CDN)。CDN通過從地理位置更靠近用戶的緩存伺服器上提供靜態資源來提高頁面載入時間。這種方法對減少網路延遲也有類似的效果。

帶寬利用率最大化

如果您知道您有一個本地分支辦公室，它的吞吐量有限，許多用戶共享這條線，那麼這可能是需要研究的內容。然而，讓1Gbps企業骨幹離開您的辦公室並不意味著您不必擔心帶寬，因為帶寬利用率受到延遲和TCP窗口大小的限制。對於涉及到的所有各方來說，控制TCP窗口大小配置可能並不容易，但是對於存在問題的客戶機PC來說，這是一個值得研究的調優機會。有關細節，請閱讀下面的內容。要了解更多關於使用salesforce的帶寬需求，請閱讀本文的幫助文章。

集成設計注意事項

如果您將Salesforce之外的服務集成為應用程序設計的一部分，請考慮以下內容:

可以使用mashup (i-frame)技術直接與客戶端進行調用，而不是通過salesforce平台進行多次往返。這種方法對減少網路延遲也有類似的效果。

握手和數據傳輸最小化(通過批處理和壓縮)以減少有效負載也很重要。應該仔細調整超時設置，以平衡延遲，避免佔用連接太長時間。對於API調用，並行化(如果可能的話)可以幫助減輕延遲的一些負面影響。

冪等性也是一個關鍵的設計考慮因素，尤其是在網路連接不佳的情況下。您應該假設在完成之前任何事務都可能失敗，並且所有來自遠程伺服器/服務的請求都應該工作，並且只工作一次，以允許多個重試，而不會帶來數據完整性問題。

總結

確保您的頁面載入時間目標不僅在您的開發實驗室設置中得到滿足，而且對於具有額外延遲或次優網路連接的遠程用戶也是如此。研究web頁面優化技術以及消除網路瓶頸以減少網路時間。這將確保您不會聽到終端用戶「為什麼我的頁面載入時間這麼長?」

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！