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
  • The temp-files mentioned to be on SSD are those generated by the Windows server itself, it is not directly related to M-Files. It is something that the sub-contractor responsible for the server has configured. I do not know exactly how and why, but I can see 2 SSD based volumes on the server, one is named Temporary Storage, and one SQLVMLOG.

    Regarding the issue with previews not having updated all properties: First of all the document needs to be updated prior to generating the PDF. If you use PDF for preview of Word documents you really need to ensure that those word documents have been updated before they get saved to M-Files. There is a function in M-Files that can update properties inside the word document, but I doubt very much that it will work if you use PDF for preview. You should discuss this in detail with M-Files if you want to depend on this.
    Recently I had a case where we had turned on Embedded Metadate Update for Word and Excel documents as described in www.m-files.com/.../enabling_metadata_field_updates_in_web_and_mobile.html This should only affect users in Classic Web and Mobile access. However, it turned out to block update of metadata on certain documents in Desktop access - apparently because the automatic metadata update collided with other automated functions. We were not able to change metadata from Desktop on those documents before we turned off this feature.

    One thing that perhaps is worth considering if you need quick access to those large files in a place with poor bandwidth (don't know if that is the case) would be to have an on premise server that can provide access over Gbit LAN connections. I am lucky to live an place where the minimum WAN speed is 200 Mbps, but that is certainly not the case everywhere. With lower bandwidth comes slower access to large files. You could implement a hybrid setup.
Reply
  • The temp-files mentioned to be on SSD are those generated by the Windows server itself, it is not directly related to M-Files. It is something that the sub-contractor responsible for the server has configured. I do not know exactly how and why, but I can see 2 SSD based volumes on the server, one is named Temporary Storage, and one SQLVMLOG.

    Regarding the issue with previews not having updated all properties: First of all the document needs to be updated prior to generating the PDF. If you use PDF for preview of Word documents you really need to ensure that those word documents have been updated before they get saved to M-Files. There is a function in M-Files that can update properties inside the word document, but I doubt very much that it will work if you use PDF for preview. You should discuss this in detail with M-Files if you want to depend on this.
    Recently I had a case where we had turned on Embedded Metadate Update for Word and Excel documents as described in www.m-files.com/.../enabling_metadata_field_updates_in_web_and_mobile.html This should only affect users in Classic Web and Mobile access. However, it turned out to block update of metadata on certain documents in Desktop access - apparently because the automatic metadata update collided with other automated functions. We were not able to change metadata from Desktop on those documents before we turned off this feature.

    One thing that perhaps is worth considering if you need quick access to those large files in a place with poor bandwidth (don't know if that is the case) would be to have an on premise server that can provide access over Gbit LAN connections. I am lucky to live an place where the minimum WAN speed is 200 Mbps, but that is certainly not the case everywhere. With lower bandwidth comes slower access to large files. You could implement a hybrid setup.
Children
No Data