2017-04-05 124 views
3

我能夠通過BlueImp Jquery Uploader插件成功上傳大文件(測試最多8GB)。使用Jquery BlueImp上傳器上傳大文件後延遲

我的PHP設置:

upload_max_filesize 8192M 
post_max_size 8192M 
max_execution_time 200 
max_input_time 200 
memory_limit 8192M 

我遇到的問題是,當大文件(2GB或更大)完成上傳,進度條掛在100%,需要相當長的時間來「完成」 。 我不確定發生了什麼後期處理,除了將文件塊拼接在一起。

我試着調整UploadHandler.php文件中的塊大小,並且它在增加(例如從10mb到500mb大塊)時似乎稍有改進,但延遲仍然存在。當完全禁用分塊上傳(0)時,似乎沒有任何改進,我也不確定這樣做的潛在影響。

對於一個2GB的文件,延遲大約是20秒,但是在一個4GB的文件上,大約2分鐘。一個7GB的文件大約需要3-4分鐘,有時會超時。這使用戶等待,不知道當進度條在此時已完成100%時發生了什麼。

有沒有人有任何的洞察力,這可能是什麼,或如何去解決它?我懷疑/ tmp中的文件可能被複制而不是移動,但根據我的說法,在php文件中沒有任何跡象。

在我的服務器上增強CPU和RAM虛擬機可以改善一點,儘管在此過程中運行「top」命令表明CPU和RAM似乎不會被大量耗盡(0-2%,與90實際上傳時爲-100%)。

非常感謝提前。

+0

_The上傳process_瀏覽器發送2gig到Apache,Apache的傳遞2gig到PHP,您的代碼運行做了'move_uploaded_file()以'和移動2演出從一個目錄到另一個。上傳完成後至少會發生最後一部分 – RiggsFolly

+0

感謝您的回覆。上傳過程本身非常快,問題在於上傳完成後。 「移動文件」操作會立即在命令行中執行。那麼上傳後實際發生什麼情況會導致此延遲? – BSUK

回答

0

在對這個問題進行了大量的故障排除和調試之後,我發現了我認爲是的原因以及更好的解決方法。這有點「哈克」(我是一個業餘開發者!),所以我願意提出任何改善這個問題的建議,儘管它似乎對我有用。

從客戶端上傳的文件實際上是上傳到服務器上的此臨時位置: 的/ tmp/systemd-私營隨機數 -httpd.service- 隨機數的/ tmp/sess_ PHP -session-ID

在客戶端上傳完成後,UI進度條會達到100%,並且在服務器正在處理這些文件時保持這種狀態。

服務器端的處理包括將文件從上面的/ tmp位置移動(複製,然後刪除)到相關的blueimp位置。 (假設在blueimp選項中啓用了「user_dirs」,默認目的地是:/ var/www/html/server/php/files/php-session-id /)。

此複製過程可能會花費大量時間,特別是在大於2GB或大約2GB的文件上。一旦服務器處理完成,blueimp會觸發「fileuploaddone」回調,UI將更新爲完成狀態。

我的目標是在此時提供一些交互式UI反饋(而不是像其他解決方法一樣掛在90%)。我的環境能夠上傳非常大的文件(10GB +),所以我不認爲不接受任何用戶對文件處理可能需要幾分鐘的反饋(用戶認爲該網站崩潰並關閉瀏覽器等) )。

我的解決方法:

我遇到的是,當文件上傳已經完成了在客戶端和服務器的處理開始似乎沒有成爲一個點的blueimp回調的第一個問題。所以我通過創建一個函數(在main.js中)在data.loaded後匹配數據顯示我的自定義「processing div」來解決此問題。總:

$('#fileupload').bind('fileuploadprogressall', function (e, data) { console.log(data); 
if (data.loaded == data.total) { 
setTimeout(function(){ 
$("#processwarn").fadeTo(300, 1); 
},3000); 
}}) 

我定製的div位於下方的進度條信息是進行刷新(用ajax.load)每隔幾秒鐘,並計算在當前會話中上傳的所有文件的總文件大小另一個PHP頁面文件夾(目錄總規模似乎並沒有提供準確的結果):

// Calculate size of files being processed 
$filePath = "/var/www/html/server/php/files/*php-session-id*/"; 

$total = 0; 
$d = new RecursiveIteratorIterator(
    new RecursiveDirectoryIterator($filePath), 
    RecursiveIteratorIterator::SELF_FIRST 
); 

foreach($d as $file){ 
    $total += $file->getSize(); 
} 

// Convert to readable format 
if ($total >= 1073741824) 
{ 
    $total = number_format($total/1073741824, 2) . ' GB'; 
} 
elseif ($total >= 1048576) 
{ 
    $total = number_format($total/1048576, 2) . ' MB'; 
} 
elseif ($total >= 1024) 
{ 
    $total = number_format($total/1024, 2) . ' KB'; 
} 
elseif ($total > 1) 
{ 
    $total = $total . ' bytes'; 
} 
elseif ($total == 1) 
{ 
    $total = $total . ' byte'; 
} 
else 
{ 
    $total = '0 bytes'; 
} 

// Display spinner gif and size of file currently being processed 
echo "<img src=\"img/spinner.gif\" height=\"20px\" width=\"20px\">&nbsp;&nbsp;Please wait, processing files: &nbsp;&nbsp;$total"; 

結果看起來是這樣的:

processing div

編輯:(後一些更多的工作) - 隨着引導進度條補充,而不是:

bootstrap progress bars

附加點從測試中發現:

隨着分塊啓用(例如設置爲1GB(maxChunkSize :1000000000)),問題幾乎消失,因爲「複製」處理髮生在分塊點(本例中每1GB),處理時間顯着減少到用戶。 當最後的處理髮生時,服務器只需「rechunk」/複製剩餘的最後1GB。
由於此,我也經歷了更快的總體上傳時間。事後看來,這對許多人來說可能是更簡單/更有效的解決方案。

0

我不太瞭解它,我在谷歌搜索,我發現了一些,我認爲它可以幫助你。

通常情況下,當服務器或客戶端發生異常時,會觸發「onError」事件。在上述情況下,服務器本身沒有超時之前不會拋出異常。

一種可能性是監視上傳狀態,並設置JavaScript超時或計數器上傳事件,以便在達到時間限制後取消上傳。

所有上傳狀態和錯誤代碼顯示在這裏 - http://help.infragistics.com/NetAdvantage/jQuery/2013.1/CLR4.0?page=igUpload_Using_Client_Side_Events.html

您可以在上傳事件「時間filestatus」的說法監控這些。

鏈接,這將有助於你

  1. Link1
  2. Link2
  3. Link3
0

什麼,這可能是

jQuery FileUpload註冊請求進度事件。這是瀏覽器向服務器發送數據時的事件,而不是來自服務器的確認事件。瀏覽器發送和服務器確認接收之間有延遲。有關這兩個事件,請參閱Can onprogress functionality be added to jQuery.ajax() by using xhrFields?。然而,我無法爲我解決這個問題並使用瞭解決方法,所以我不能完全確認這個假設。

如何去故障排除它:

使用瀏覽器的調試工具和代碼在這裏設置一個斷點,以獲取可用的變量的理解:一旦確定 https://github.com/blueimp/jQuery-File-Upload/blob/master/js/jquery.fileupload.js#L372

什麼你想看,最好的情況是用console.log打印信息,並檢查你的瀏覽器的控制檯輸出。

變通

如果你只看到感興趣的所有下載是否完成,並顯示給用戶的東西仍在繼續,你可能想看看停止/ DONE事件,或還有fileupload('active'),請看這裏:Finish of Multiple file upload

相關問題