M-Files as a storage for frequent big documents

Hi Karl,

Thanks for the summary and insights. That is very encouraging.

I am wondering if you could share the server setup (RAM, Disk size, disk throughput as I read it is very important for fast storing) as I could imagine the setup would be the key. I know about general setup that M-Files recommended which is I suppose good guidance. I would be very curious about type of disks and disk throughput as documents would be saved on a disk. In our case, we would have shared drive provided from NetApp which could grow so we would prepare ourselves for increase scenario.

Are the amount of those 500 big zips constantly growing or is more or less fixed? 100 documents per day incoming is quite a solid number for standard documents so this seems to be quite a solid throughput. Also wonder which search engine the client is using DtSearch or IDOL. I suppose indexing services are setup on separate server so that index can be re-built fast as new documents arrive.

Obviously users would not preview zip files. Do you have any experience with previewing of big 300MB files in a preview mode? I did some testing and it freezes a client for some time with VM having 16GB (but I have to admit many other things are running in parallel, it is our testing VM). As in our case, we plan to upload PDFs, the usage of preview mode would be an realistic usage.
I do agree with you about complexity: we have currently 2 effective document types with quite a complex workflows. M-Files is amazing because offers so flexibility but of course with that flexibility comes complexity as well. We now try to reduce number of auto-calculate properties and also trying to re-use as much metadata we can. Not an easy task, when you have real scenarios already running over existing solutions. We would need to exponentially grow (+50 document types and than even more) so maintenance costs and maintenance best practices are worrying/points of interest for me as well.

Nevertheless what you have summarized sounds encouraging and have a lot of potential.

Thanks again for you insights.

Dejan

Hi Karl,

Thanks for the summary and insights. That is very encouraging.

I am wondering if you could share the server setup (RAM, Disk size, disk throughput as I read it is very important for fast storing) as I could imagine the setup would be the key. I know about general setup that M-Files recommended which is I suppose good guidance. I would be very curious about type of disks and disk throughput as documents would be saved on a disk. In our case, we would have shared drive provided from NetApp which could grow so we would prepare ourselves for increase scenario.

Are the amount of those 500 big zips constantly growing or is more or less fixed? 100 documents per day incoming is quite a solid number for standard documents so this seems to be quite a solid throughput. Also wonder which search engine the client is using DtSearch or IDOL. I suppose indexing services are setup on separate server so that index can be re-built fast as new documents arrive.

Obviously users would not preview zip files. Do you have any experience with previewing of big 300MB files in a preview mode? I did some testing and it freezes a client for some time with VM having 16GB (but I have to admit many other things are running in parallel, it is our testing VM). As in our case, we plan to upload PDFs, the usage of preview mode would be an realistic usage.
I do agree with you about complexity: we have currently 2 effective document types with quite a complex workflows. M-Files is amazing because offers so flexibility but of course with that flexibility comes complexity as well. We now try to reduce number of auto-calculate properties and also trying to re-use as much metadata we can. Not an easy task, when you have real scenarios already running over existing solutions. We would need to exponentially grow (+50 document types and than even more) so maintenance costs and maintenance best practices are worrying/points of interest for me as well.

Nevertheless what you have summarized sounds encouraging and have a lot of potential.

Thanks again for you insights.

Dejan