Ticket #102 (closed task: duplicate)
Plumi doesn't handle big files well
| Reported by: | anonymous | Owned by: | andycat |
|---|---|---|---|
| Priority: | major | Milestone: | 3.1 |
| Component: | ATEngageVideo | Severity: | |
| Keywords: | Cc: | ||
| Who will test this: |
Description
Hi!
I'm tryng to download 50 megs file from plumi, and it takes ages, a lot of memory.
I think rc2 was better in this issue from final, but I don't understand why... I'm also using Cache-Fu and setted zope cache to 15.000.
Attachments
Change History
comment:2 Changed 6 years ago by anonymous
Uhm, I mean the ExternalStorage?, not BlobFile?.
comment:3 Changed 6 years ago by anonymous
Hi
yes, this is a known issue with large file support inside Plone.
You should upgraded to Plone 2.5.4-2 , see http://plone.org/products/plone/releases/2.5.4
which you will notice has ::
Made Plone use 1/10th of the memory on file uploads. Details in http://dev.plone.org/plone/ticket/7027 (also fixed in Plone 3.0.x) [zegor]
Also, in plumi 0.2 we will have a facility where you can use a download server, ie plumi will re-write the urls so that the download links go via a different URL, where you can serve the video files from a apache webserver, or something else, not plone.
comment:4 Changed 6 years ago by andycat
- Summary changed from Plumi don't handle well big files to Plumi doesn't handle big files well
- Milestone set to 0.3
comment:5 Changed 6 years ago by anonymous
I've applied the patch in 2.5.4, and restarted zope, but it doesn't change.
The problem is NOT in the upload, but in download.
I'm serving flv files via apache, and I created fake 1 byte lenght file to upload in the content type (engage.py).
comment:6 Changed 6 years ago by andycat
Without more infomation on what "doesnt change" , I cant help. You need to give information about whats the problem, obviously. Also, if you post information can you make sure you format it properly in this tracker, so that its disgestable (see the vmstat info above)
I may be wrong, but the fix in 2.5.4-2 applies to the situation of uploading or downloading, or anytime that the content type is being edited.
Also, I wasnt talking about serving FLV, which are handled differently using included HTML from indytube- I was talking about downloading the raw media files that are uploaded by the user.

more info:
wmstat -n 2 shows bi and bo around 1500/3000 and over.
yurj@beethoven:~$ vmstat -n 2 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
maybe a problem with BlobFile??