1，背景介紹
公司最近最近統一了存儲環境，由ftp文件存儲全量轉換爲ceph存儲。有業務組表示以前往ftp文件批量上傳30萬個文件1.3GB只需要16分鐘左右。切換爲ceph存儲需要1個多小時，也就是現在現有的速度只有369kb/s。詢問能如何改進。
公司內部網絡和存儲環境進行了壓力測試。
ceph 存儲系統調研讀寫性能測試的報告如下
我們是採用s3的接口進行文件上傳的，也就是對於上面的cephrgw的接口。大概在20MB/s的速度。
2,首先我使用java程序進行驗證。
發現他發給我的數據集確實以很慢的速度進行上傳。和普通的文件上傳具有10倍的差距左右。在調整aws-java-s3的sdk的線程池的大小後。效果也是不明顯的。我採用jconsole觀察線程的使用情況
3，使用AWS CLI進行快速驗證
AWS CLI採用python編寫，具有較爲完備的日誌。
安裝指南:https://docs.amazonaws.cn/cli/latest/userguide/install-windows.html
調整併發數量和配置日誌：https://amazonaws-china.com/cn/blogs/china/amazon-s3-depth-of-practice-series-s3-cli-depth-parsing-and-performance-testing/
批量生成不同大小的文件我採用了Bandizip（7zip只支持1MB以上的分卷大小）:http://www.bandisoft.com/bandizip/
併發請求數量和分片大小我設置爲:
s3 =
max_concurrent_requests = 50
multipart_threshold = 10MB
multipart_chunksize = 6MB
上傳命令：
aws s3 cp C:\app\qolfile\ s3://cu-ibas/oss/public --endpoint-url http://oss.ts-pfecs.epay --recursive
命令參數說明如下：
cp: 代表拷貝文件
C:\app\qolfile:本地的目錄
s3://cu-ibas/oss/public：遠端s3的地址，包含bucket名稱和路徑
--endpoint-url http://oss.ts-pfecs.epay：指定遠程端點地址
--recursive ：表示遞歸上傳文件夾裏面的文件
上傳並將日誌存儲在文件中：
aws s3 cp C:\app\qolfile\ s3://cu-ibas/oss/public --endpoint-url http://oss.ts-pfecs.epay --recursive --debug >upload.txt 2>&1
upload.txt的文件部分內容摘要
2019-07-17 15:34:50,100 - ThreadPoolExecutor-1_2 - s3transfer.tasks - DEBUG - Executing task UploadSubmissionTask(transfer_id=2, {'transfer_future': <s3transfer.futures.transferfuture object="" at="" 0x0000026005c559e8="">}) with kwargs {'client': <botocore.client.s3 object="" at="" 0x0000026005b972b0="">, 'config': <s3transfer.manager.transferconfig object="" at="" 0x0000026005bf8e48="">, 'osutil': <s3transfer.utils.osutils object="" at="" 0x0000026005bf8eb8="">, 'request_executor': <s3transfer.futures.boundedexecutor object="" at="" 0x0000026005c43080="">, 'transfer_future': <s3transfer.futures.transferfuture object="" at="" 0x0000026005c559e8="">}
2019-07-17 15:34:50,101 - ThreadPoolExecutor-1_3 - s3transfer.tasks - DEBUG - UploadSubmissionTask(transfer_id=3, {'transfer_future': <s3transfer.futures.transferfuture object="" at="" 0x0000026005c6b128="">}) about to wait for the following futures []
2019-07-17 15:34:50,101 - ThreadPoolExecutor-1_3 - s3transfer.tasks - DEBUG - UploadSubmissionTask(transfer_id=3, {'transfer_future':
ThreadPoolExecutor帶有49，50等信息就代表併發請求數生效了。然後我做了不同文件大小的測試速度情況：
| 分卷文件大小 | 觀察的上傳速度 |
|---|---|
| 1MB | 1.5MB/s |
| 500KB | 800KB/s |
| 10KB | 390KB/s |
| 1KB | 100KB/s |
這也就是說明了每個文件的大小對於文件上傳速度是有影響的。如果每個文件的大小都大於1MB以上。在設置恰當的s3上傳的帶寬能夠跑滿。如果每個文件都小於1KB的情況下。上傳速度會很慢的。
4，總結
先給出這個小文件數據集的情況下，沒有辦法提高上傳速度。應用層可以採用邊生成文件，邊上傳文件的模式來加快批量處理的速度。也就是採用生產者消費者模式。隊列可以採用內存隊列，可以採用redis的queue放置消費任務。