This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

M-Files as a storage for frequent big documents

Hi there,

I was approached today with a requirement to save big technical reports containing picture snippets and summaries. These reports are usually between 250-500MB each and they are in PDF format.
Another point is that these reports could easily be produce 1-10 times per month.
So if I calculate a middle case 5 documents of 300 MB per month I coming to 60 documents with size 17 GB.
I have did some load test with 200-250MB files over REST based API and it was not particularly fast (obviously due to size of a document). I am currently not aware about complexity of metadata for that specific document type. This can of course influence uploading speed as well.
I am not aware on any document size limit in M-Files but wondering if M-Files is a proper solution for such a use case.
I am also worried because Vault will grow to be quite big and this could influence other document types used in a system (planned 50-100 document types).

What are your experiences with big frequent documents? I would appreciate your experiences.

Dejan
Parents
  • Thanks Karl! I highly appreciate a level of details.
    I have done some testing in Azure VMs as well and the performance decreases as we switched to HDD disks (need to save money). SSD is definitely a way to go, I would even prefer it for storage but as mentioned we would have NetApp shared drives which should be fairly fast.
    I noticed as well that the preview mode for fairly small documents sometimes take more time. But I have to admit that we use converting into pdf on preview as windows preview does not look nice for word documents. Also I have noticed that documents with higher amount of metadata placeholders take more time to preview as pdf. Unfortunately not all placeholders get filled out which is kind of odd. Users need to checkout document to get all placeholders filled out. Metadata behind contains value but it does not get filled out during preview. Kind of strange. I wrote once about this but no one could explain me how the preview works and why it does not pick and apply all metadata into converted pdf.
    Sorry short detour about preview as it is a big topic for users.
    Are temp files for M-Files Server separately configured? I know about setting up the storage (file data location, secondary file data location).
    It is great to hear that even under such a big load users did not experience complete blackout.

    Thanks again Karl.

    Dejan
Reply
  • Thanks Karl! I highly appreciate a level of details.
    I have done some testing in Azure VMs as well and the performance decreases as we switched to HDD disks (need to save money). SSD is definitely a way to go, I would even prefer it for storage but as mentioned we would have NetApp shared drives which should be fairly fast.
    I noticed as well that the preview mode for fairly small documents sometimes take more time. But I have to admit that we use converting into pdf on preview as windows preview does not look nice for word documents. Also I have noticed that documents with higher amount of metadata placeholders take more time to preview as pdf. Unfortunately not all placeholders get filled out which is kind of odd. Users need to checkout document to get all placeholders filled out. Metadata behind contains value but it does not get filled out during preview. Kind of strange. I wrote once about this but no one could explain me how the preview works and why it does not pick and apply all metadata into converted pdf.
    Sorry short detour about preview as it is a big topic for users.
    Are temp files for M-Files Server separately configured? I know about setting up the storage (file data location, secondary file data location).
    It is great to hear that even under such a big load users did not experience complete blackout.

    Thanks again Karl.

    Dejan
Children
No Data