New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Large File Handling (eg 2.5 MB file) Slower When InMemory is True #65
Comments
Buffer is null for me. Is that normal? |
If |
I'm not sure that this is an issue anymore with never node. From the blog:
We are using buffers internally in Please reopen if you feel that this is still an issue. |
I'm noticing multer is often very slower using I'm uploading/processing binary files < 10mb
Procfile
From the Heroku logs:
My route is somthing like this:
Is there any way to search for the root of the problem? |
When inMemory is true and file.buffer is larger than 64 Kb, there is an "issue" that I don't think is fixable right now b/c it's the way Node.js currently allocates memory for large buffers. (see StackOverflow and this blog)
In multer/master, I have mocha tests (see test/inmemory.js) that can be used to test this issue. When running, the multi-file upload test take an average of 1 second. Compare this to the write-to-disk multi-file upload taking 100 ms. In local tests, I changed-up my inMemory Buffer code to a writable stream and piped the filestream directly to it but still would get 1 second performance. I don't think my test hardware is to blame (i7-4810MQ w/ 32 Gig RAM on SSDs).
I also ran the tests against the latest node in development 0.11.14 but there's a bug preventing mocha from completing. Need to keep an eye on this b/c TJ wrote "[there's been] significant performance work done in core features (Buffers, TLS, streams)." reference
Hopefully I'm wrong with this issue and someone knowing more about how core streams/Buffers work can suggest ways to improve inMemory performance for large buffers.
The text was updated successfully, but these errors were encountered: