背景信息

越來越多的用戶構建數據湖，并借助OSS來存儲數據。OSS可提供99.9999999999%（12個9）的數據持久性，99.995%的數據可用性。多種存儲類型供選擇，全面優化存儲成本。

從OSS上傳和下載數據時，您的應用程序可以輕松實現每秒數千個事務的請求性能。您的應用程序可以實現存儲空間（Bucket）中每個分區（OSS按對象名的字母序排列對象，并按照數據量和請求QPS來拆分分區）每秒至少3500個PUT、COPY、POST或DELETE請求和5500個GET或HEAD請求，而存儲空間中的前綴數量是沒有限制的，因此您可以通過并行讀取來提高讀取或寫入性能。也就是說，如果您的請求的文件前綴設計合理，在某個OSS Bucket中創建了10個前綴來并行上傳，則可以將數據寫入性能擴展到每秒35000個PUT請求。

阿里云OSS-HDFS服務（JindoFS服務）是JindoFS存儲系統在阿里云上的服務化部署形態，與阿里云OSS深度融合，開箱即用，無須在EMR集群中部署維護JindoFS，免運維。OSS-HDFS服務詳情請參見OSS-HDFS服務概述。

管理HTTP速度緩慢響應的最佳實踐

將OSS/OSS-HDFS和ECS實例配置在同一地域

OSS存儲空間名稱是全局唯一的，您在創建存儲空間時必須指定地域，且創建以后不能更改名稱和地域。為了優化性能，建議您盡可能從同一阿里云地域中的ECS實例訪問OSS存儲空間，從而降低網絡延遲和數據傳輸成本。詳情請參見ECS實例通過OSS內網地址訪問OSS資源。

通過水平擴展和并發或并行請求實現高吞吐量

OSS是一個超大的分布式系統。為了幫助您利用其規模，建議您將并行請求水平擴展到OSS服務終端節點，這種擴展方式有助于通過網絡將負載分布在多個路徑上。

OSS-HDFS使用了上述最佳實踐，通過元數據服務支持，以文件塊的方式將文件水平擴展到多個OSS服務終端上，以獲取最佳的讀寫性能。

對于高吞吐量傳輸，您可以根據您的ECS規格和應用程序，調整特定參數，在多個線程或多個實例中控制上傳和下載數據的并發或并行度來優化吞吐量。

• 測量性能指標

  根據CPU、網絡吞吐量的要求來評估不同的ECS實例規格。有關實例規格的更多信息，請參見實例概述。此外，建議您在測量性能時使用HTTP分析工具查看DNS查詢時間、時延和數據傳輸速度。

  當您要調整并發的請求數時，性能測量非常重要。建議從單個請求開始，測量當前的網絡帶寬以及其他資源的使用情況，從而識別瓶頸資源（即使用率最高的資源），以及可能的并發請求數。例如，如果一次處理一個請求導致CPU使用率為10%，則表明最多可以支持10個并發請求。

• 調整并發與并行的參數

  您可以通過修改fs.oss.download.thread.concurrency和fs.oss.upload.thread.concurrency調整單個進程內上傳和下載的并發數。

  如果您在運行MapReduce或Spark任務，還有以下選擇：

  • 對于提交MapReduce任務，可以通過Hadoop參數mapreduce.job.maps和mapreduce.job.reduces控制并行的執行程序數量。

  • 對于提交Spark執行程序，可以通過選項--num-executors或者Spark參數spark.executor.instance控制并行的執行程序數量。

對時延敏感的應用程序進行超時重試

OSS針對管控類API，如GetService（ListBuckets）、PutBucket、GetBucketLifecycle等進行QPS限制。如果應用程序產生高請求速率，可能會收到HTTP 503減速響應。如果發生這類錯誤，建議您延遲幾秒后進行重試。

您可以通過調整fs.oss.retry.count控制訪問OSS或OSS-HDFS的重試次數，fs.oss.retry.interval.millisecond控制訪問OSS或OSS-HDFS的重試間隔（間隔會隨重試次數的增加而倍增）。也可以根據網絡情況來調整fs.oss.timeout.millisecond超時時間，進行合理的超時重試。

對頻繁訪問的內容使用緩存加速

如果您的應用程序需要支持同一地區大量訪問同一靜態文件的場景，可以使用JindoData緩存服務進行加速。JindoData緩存服務將文件以塊的形式分散存儲在分布式緩存服務中，從而避免重復從OSS或OSS-HDFS反復拉取數據，有效減少訪問時延，增加計算資源的利用率。詳情請參見阿里云OSS/OSS-HDFS服務透明緩存加速。

使用最新版本JindoSDK