Delay after uploading large files with JQuery BlueImp uploader

After a lot of troubleshooting and debugging this issue, I've found what I believe is the cause and the best solution / solution. Its a bit "hacky" (Im amateur dev!), So I'm open to any suggestions for improving this, although it seems to work for me.

The files downloaded from the client are actually downloaded to this temporary location on the server: / tmp / systemd -private-random-number-httpd.service-random-number / tmp / sess_php-session-ID

After the client-side download is complete, the UI progress bar reaches 100% and remains that way while the server processes the files.

Server-side processing involves moving (copying and then deleting) a file from the above / tmp location to the appropriate blueimp location. (Assuming the "user_dirs" parameter is enabled / true in the blueimp options, the default is / var / www / html / server / php / files / php-session-id /).

This copying process can take a significant amount of time, especially for files larger than 2 GB or so. When the server finishes processing, blueimp fires the "fileuploaddone" callback, and the UI is refreshed to complete.

My goal was to provide an interactive UI at this point (instead of hanging 90% like the other workaround). My environment is capable of very large downloads (10gb +), so I didn't find it acceptable not to provide user feedback that there could be several minutes of file processing (assuming the site crashed and closed the browser, etc.).

My workaround:

The first problem I ran into was that there didn't seem to be a blueimp callback for the moment when the file upload finished on the client side and server processing starts. So I worked around it by creating a function (in main.js) to render my custom "div handler" after data.loaded matches data.total:

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

      

        
        
        
      

    

My custom div that is below the progress bar information is another php page refreshed every few seconds (using ajax.load) and calculates the total file size of all files in the current load folder of the session (total directory size doesn't seem to give exact results):

// 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";

      

        
        
        
      

    

The result looks something like this:

Edit: (after some additional work) - added a loading progress bar instead:

Additional point noted during testing:

With blocking enabled (for example, for 1gb (maxChunkSize: 1000000000)), the problem almost disappears, as the processing time decreases dramatically for the user, since the "copy" processing occurs at the chunking point (every 1gb in this example). When final processing takes place, the server only has to "overwrite" / copy the last remaining 1gb.
Because of this, I also experienced faster overall load times. In hindsight, this might be an easier / more efficient solution for many.