国产+高潮+在线,国产 av 仑乱内谢,www国产亚洲精品久久,51国产偷自视频区视频,成人午夜精品网站在线观看

webman大文件切片上傳,很慢

mine

問題描述

項(xiàng)目中需要上傳視頻,一個視頻150M左右,直傳基本上都是上傳失敗,所以改成了切片上傳,一個切片2M,這樣上傳一個視頻就得發(fā)70多個請求。
業(yè)務(wù)中一般至少要同時上傳3個視頻左右,總共發(fā)送的請求在200多,3個視頻傳完,總耗時基本在4分鐘左右。
隨著請求數(shù)量的加多,單個上傳切片的處理時間變得越來越長,有時候能達(dá)到2~3分鐘才能處理一個切片請求。

  1. 部分請求歷史
    部分請求歷史

  2. 單個切片的請求
    單個切片的請求

  3. 合并第一個文件,116M
    合并第一個文件,116M

  4. 合并第二個文件,116M
    合并第二個文件,116M

  5. 合并第三個文件,152M
    合并第三個文件,152M

服務(wù)器是8核16G,config/server.php中的count配置的是cpu_count() * 2,在上傳文件時,我看了下服務(wù)器的負(fù)載,只有兩個進(jìn)程的cpu占用在2%多一點(diǎn),其他的全是0。

項(xiàng)目已經(jīng)做了nginx代理

upstream webman {
    server 127.0.0.1:8787;
    keepalive 10240;
}

server
{
    listen 80;
    server_name aaa.ccc;
    index index.php index.html index.htm default.php default.htm default.html;
    root /app/webman/public;

    location /api/ {
      add_header Access-Control-Allow-Origin *;
      add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE ,OPTIONS';
      add_header Access-Control-Allow-Headers 'DNT,Keep-Alive,User-Agent,Cache-Control,Content-Type,Authorization,token';

      if ($request_method = 'OPTIONS') {
          return 204;
      }
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_http_version 1.1;
      proxy_set_header Connection "";
      proxy_pass http://webman/;
      client_max_body_size 200M;
    }

   ...
   其他配置省略
}

PHP版本:8.0.22,已經(jīng)開啟opcache
webman版本:1.4.8

為此你搜索到了哪些方案及不適用的原因

  1. 嘗試過增加單個切片的大小,從而減少請求的數(shù)量,但總耗時差不多
  2. 嘗試增加config/server.php中的count的數(shù)量,感覺沒效果

特來請教是配置不對,還是哪里有問題,上傳很慢。
希望各位大佬多提建議,謝謝。

2465 6 1
6個回答

nitron

服務(wù)器帶寬多少?這種重IO的,不是請求越多越好

  • mine 2022-10-21

    公網(wǎng)帶寬是200M的。

  • nitron 2022-10-21

    你這種重IO,就是Block住的進(jìn)程的,開再多count也沒用
    打個比方,不嚴(yán)謹(jǐn),最多同時能處理8個切片,再多就要排隊(duì)處理,因?yàn)檫@是阻塞IO,要等其中一個處理完空處理才能繼續(xù)處理后續(xù)切片,所以越往后的的越久,

  • six 2022-10-21

    webman上傳 下載都不block進(jìn)程,都是非阻塞的

  • mine 2022-10-21

    有啥辦法可以增大同時處理的切片數(shù)嗎?cpu基本上處于閑置狀態(tài)。

  • six 2022-10-21

    如果你本地網(wǎng)絡(luò)上行帶寬有瓶頸,同時處理多少分片都一樣

  • mine 2022-10-21

    我感覺應(yīng)該不是帶寬的問題,從http請求歷史來看,請求從發(fā)送到結(jié)束,等待服務(wù)器處理的時間很長,服務(wù)器真正處理的時間就那幾秒鐘。
    大部分的時間都是在等服務(wù)器處理。

  • six 2022-10-21

    弄個本地環(huán)境,上傳到127.0.0.1:8787 試下

縫合

(我猜的,我不太確定)是不是和你開的webman的任務(wù)數(shù)量有關(guān),如果你開的數(shù)量大于webman設(shè)置worker數(shù)量,多出來的部分應(yīng)該是阻塞的。 或者硬盤速度?

  • mine 2022-10-21

    webman任務(wù)數(shù)量是可以配置的嗎?在哪配置?

  • 縫合 2022-10-24

    看你寫了 count 更改無效,我也不確定了,馬克一下,等你解決方案 ??

six

可能是哪里限制網(wǎng)速,比如你是電信100M帶寬,那么上行帶寬實(shí)際只有1.25MB/s,上傳三個150MB的文件,確實(shí)需要4分鐘時間。

  • mine 2022-10-21

    應(yīng)該不會,這是服務(wù)器,云服務(wù)商應(yīng)該不會限速。

  • liziyu 2022-10-21

    有可能,通常上下行不對稱的,這個普遍存在。我們通常說的“100M”是指下行帶寬。

  • six 2022-10-24

    我說的不是云服務(wù)商限速,我說是你家庭或者辦公室網(wǎng)絡(luò)服務(wù)商。比如你在家里上傳,你家庭寬帶是100Mbit,上行帶寬會被運(yùn)營商限制成1.25MB。上傳150M的文件,最快也要需要2分鐘。
    你試下直接scp或者ftp文件上傳到服務(wù)器看要多久

  • six 2022-10-24

    還有,瀏覽器也有并發(fā)限制,70個請求會排隊(duì)分批處理,并不是真的并發(fā)一起發(fā)起請求。

Gin

這種切片的任務(wù)不是一般都異步隊(duì)列后臺處理么? 你這么在前臺等不是個事. 我們的切片java做的 效率也不高

  • mine 2022-10-22

    這個文件上傳是表單的一部分,最耗時的就是文件上傳,做異步隊(duì)列反而麻煩了。

hongs

本地搭建服務(wù)器 測試一下。
這樣可以排除網(wǎng)絡(luò)問題。

  • mine 2022-10-31

    不是網(wǎng)絡(luò)的問題,就是分片時,請求太多,服務(wù)器要排隊(duì)處理。

hongs

正常上傳150M的東西也不算很大 應(yīng)該不會傳不成功。

  • 暫無評論
年代過于久遠(yuǎn),無法發(fā)表回答
??