загрузка большого файла из Jetty (ambari webhdfs) идет медленно - PullRequest
0 голосов
/ 21 апреля 2020

У меня есть файл около 5G, загрузка с hdfs с использованием клиента python со скоростью 12M / s, покупка моей сети может достигать 500M / s, и файл меньшего размера работает нормально. Затем я воспроизвел эту проблему с помощью curl.

Вот журнал отладки curl:

curl -v -X GET http://x.x.x.x/file

> GET /webhdfs/v1/user/sohuvideo/online/srcFile/188/718/188718791/dat1_188718791_2020_4_11_17_4_172647e6e60.mp4?op=OPEN&user.name=sohuvideo&namenoderpcaddress=sotocyon&offset=0 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: x.x.x.com:50075
> Accept: */*
> 
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Expires: Tue, 21 Apr 2020 03:01:26 GMT
< Date: Tue, 21 Apr 2020 03:01:26 GMT
< Pragma: no-cache
< Expires: Tue, 21 Apr 2020 03:01:26 GMT
< Date: Tue, 21 Apr 2020 03:01:26 GMT
< Pragma: no-cache
< Content-Type: application/octet-stream
< Access-Control-Allow-Methods: GET
< Access-Control-Allow-Origin: *
< Transfer-Encoding: chunked
< Server: Jetty(6.1.26)
< 
{ [data not shown]
100  119M    0  119M    0     0  13.0M      0 --:--:--  0:00:09 --:--:-- 12.1M^C

После некоторого копания я обнаружил, что прикрепить header Соединение: закрыть к запросу, это может закончиться гораздо быстрее.

curl -v -H "Соединение: закрыть" -X GET http://x.x.x.x/file

> GET /webhdfs/v1/user/sohuvideo/online/srcFile/188/718/188718791/dat1_188718791_2020_4_11_17_4_172647e6e60.mp4?op=OPEN&user.name=sohuvideo&namenoderpcaddress=sotocyon&offset=0 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: x.x.x.com:50075
> Accept: */*
> Connection: close
> 
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Expires: Tue, 21 Apr 2020 03:00:13 GMT
< Date: Tue, 21 Apr 2020 03:00:13 GMT
< Pragma: no-cache
< Expires: Tue, 21 Apr 2020 03:00:13 GMT
< Date: Tue, 21 Apr 2020 03:00:13 GMT
< Pragma: no-cache
< Content-Type: application/octet-stream
< Access-Control-Allow-Methods: GET
< Access-Control-Allow-Origin: *
< Connection: close
< Server: Jetty(6.1.26)
< 
{ [data not shown]
100 4517M    0 4517M    0     0   138M      0 --:--:--  0:00:32 --:--:--  153M
* Closing connection 0

Я думаю, что это, вероятно, вызвано Transfer-Encoding: chunked с сервера, когда файл большой, сервер выбрал это, потому что, когда сервер передает файл, размер файла еще не определен, кусочный поток может дать много накладных расходов. Если задано Connection: закрыть , то сервер не будет использовать Transfer-Encoding: chunked , чтобы указать конец пара, вместо этого просто закройте соединение.

Есть ли способ? исправить это со стороны сервера?

...