2016-12-08 14 views
0

많은 양의 파일을 업로드하려면 FineUploader를 사용하려고합니다. 업로드하기 전에 파일을 조작해야합니다. 즉, 식별 정보를 익명으로 사용해야합니다. another answer에서 Ray Nicholus는 onSubmit 처리기에서 원본 파일을 거부하고 조작 된 파일을 다시 추가 할 것을 제안했습니다. 따라서 내 onSubmit 처리기는 다음과 같이 보입니다.많은 파일을 업로드하고 조작 할 때 메모리 사용량이 높음

onSubmit: function (id, name) 
{ 
    var file = this.getFile(id) 
    if (file.isAnonymized) 
    { 
     return; 
    } 
    var reader = new FileReader() 
    reader.onload = function() 
    { 
     var arrayBuffer = this.result 
     var byteArray = new Uint8Array(arrayBuffer) 
     // Manipulate the byteArray in some way... 
     var blob = new window.Blob([byteArray]) 
     blob.isAnonymized = true 
     // add the anonymized file instead 
     uploader.addFiles({blob: blob, name: name}) 
    } 
    reader.readAsArrayBuffer(file) 
    // cancel the original file 
    return false 
}, 

작은 양의 파일에는 문제가 없습니다. 구체적인 예를 들어, 고객이 파이어 폭스에서 각각 1.5MB ~ 3MB의 파일을 업로드하려고 시도했지만 탭이 결국 손상되기 전에 Firefox의 메모리 사용량이 지붕을 통해 급격히 증가하는 것을 보았습니다. 다른 브라우저 (Chrome, Edge)도 비슷한 동작을 보입니다. 브라우저의 개발자 도구를 사용하여 큰 메모리 할당을 표시하지 않는 것 같습니다. 있는 그대로 파일을 업로드 할 때 아무런 문제가 없지만 이는 옵션이 아닙니다.

+0

어떻게 든 WebWorker에 넣을 수 있습니다. – TryingToImprove

+0

일부 js 파일 라이브러리는 많은 파일을 관리하도록 설계되지 않았습니다. XMLHttpRequest는 거대하고 비동기적인 객체입니다. 일반적으로이 종류의 라이브러리는 for 루프에서 모든 업로드를 시작합니다. for 루프는 1000 개 이상의 파일을 넣을 때 브라우저를 정지시킵니다 (1000 개의 동시 연결을 할당하고 시작하려고하므로). 나는 너에게 너의 자신의 업로드 부분을 쓸 것을 제안한다. – Fefux

+0

내가 말했듯이 단순히 업로드하는 것이 매력처럼 작동하므로 문제가되지 않는다고 확신합니다. 고통을 시작하기 전에 미리 파일을 조작해야합니다. –

답변

0

나는 https://github.com/sgarcialaguna-mms/file-upload-memory/에서 예제를 정리했고, 오류가 fineuploader 라이브러리가 필요한 것보다 오랫동안 유지하고 있기 때문에 오류라고 확신한다.

이 예제에서는 한 번에 하나의 파일을 메모리로로드 한 다음 blob을 업로드 라이브러리로 전달합니다. 또한 실제 서버 (fineuploader 서버 예제 저장소의 Django 예제)를 사용합니다.

Firefox의 경우 1GB 미만의 파일을 드래그하면 업로드하는 동안 파이어 폭스의 메모리 사용이 지속적으로 증가하고 업로드가 완료된 후에도 높게 유지됩니다. 나는 대략 열 ​​수있다 : "메모리 사용 최소화"를 클릭하여 가비지 콜렉션을 트리거하고 "Measure"를 누르면 파일 데이터가 "memory-file-data/large"아래에 표시됩니다. uploader.reset()으로 전화하면 가비지 콜렉션이 다시 트리거되고 Firefox의 메모리 사용량이 급격하게 감소합니다. 다시 측정하면 "메모리 파일 데이터/큰"객체가 더 이상 메모리에 존재하지 않음을 알 수 있습니다. https://github.com/FineUploader/fine-uploader/issues/1540#issuecomment-194201646에 따라 업로드 할 때마다 this._handler.expunge(id) 번으로 전화하면됩니다.

크롬은 오랫동안 계속되는 버그로 인해 약간 다르게 동작합니다. 500MB 이상의 BLOB 데이터가 축적되면 결국 ERR_FILE_NOT_FOUND 오류가 발생하기 시작합니다. chrome : // blob-internals 페이지는 보유하고있는 blob과 참조 횟수를 표시합니다.

어떤 변수/클로저/무엇이이 객체를 유지하는지 쉽게 알 수있는 방법이 있는지 모르겠지만 매우 도움이 될 것입니다.

+0

파일은 메모리를 소비하지 않으며 디스크로 백업됩니다. 이 파일들을 가지고 있으면 메모리를 소비하지 않습니다. 그러나 디스크상의 파일로 백업되지 않는 BLOB를 전달하는 경우에는 다른 이야기입니다. 파인 업 로더가 필요한 것보다 오랫동안이 얼룩을 붙잡을 수있는 영역을 알지 못합니다. 이 경우에 대한 확신을 가지려면 코드를 탐구해야하며 문제가있는 곳을 참조해야합니다. –

+0

대부분의 경우 코드에 문제가 있습니다. 1GB의 메모리 백업 Blob을 Fine Uploader에 전달하는 경우 물론, 1GB의 메모리를 사용하며 blob은 업로드 될 때까지 범위에 있어야합니다. –

+0

좋아요, 남은 한 해 동안 인터넷에 접속하지 않기 때문에 저의 마지막 코멘트. @RayNicholus "대부분의 경우 문제는 코드에 있습니다. 메모리 백업 Blob을 Fine Uploader에 전달하는 경우 당연히 1GB의 메모리를 사용하며 BLOB는 업로드되었습니다. " 그 정도는 명백합니다. 분명히 말했듯이 문제는 업로드 후에 메모리가 해제되지 않는다는 것입니다. "문제는 귀하의 코드에 있습니다." 내 코드가 바로 거기에 있습니다. 간신히 60 줄이야. 내가 만든 실수를 발견 할 수 있다면 기꺼이 들려 줄 것입니다. –