Is traditional ECM up for high performance 9 March 2009
Posted by lopataru in ECM.Tags: ECM, performance
trackback
Last week I stumbled over the WordPress statistics for February.
Impressive. That got me thinking on how I would be able to implement this kind of backend system with a traditional (read “top Gartner stuff”). And I shivered inside while thinking of IBM CM, Documentum, FileNet… SharePoint (lol!).
I remember once I’ve seen a support issue with one of the above vendors in which the administration tool could not display the size of filestores bigger that 2 GB. And I believe the issue is still there, after 2-3 years. Tragic.
Imagine a customer seeing this (and they do) and saying… “Well.. what kind of Enterprise system is this? If it cannot show correctly storage spaces over 2 GB? How can I trust it with my Terabytes?”
My practice based experience tells me that a large scale performance cannot be normally achieved with Enterprise grade software. You have a better chance with some high skilled professionals (not many, 4-7 should be enough) which can put together some “indie” software.
In my work, I rarely (read “never”) seen a ECM system handle a load similar with the WordPress one. ECM in my area tends to cap normally at about several million items and a few TB of space. While requiring a huge deluge of hardware (I can’t still understand why on earth would I need minimmum 4 GB or RAM for an Index Server? Even in the smallest install)
You out there…. Working on ECM… I would like to know your statistics.
I have one client that has over 26 TB of content and 21 million indexed objects, without using Lightweight Sysobjects or any other High-Volume Server features. We are adding 1.5-2TB/month and about 1.5mil objects in that month. That rate will double this summer.
The Content Server is keeping-up fine. Once we went to a multi-node indexer, search was able to keep up.
-Pie
I have clients with HUNDREDS (300+ million in one repository and 400+ million in another repository) of millions of heavy sysobjects ingesting a half million plus per day with sub-second query respinse time. I believe that these are the largest Documentum production repositoires on the planet. No full text indexing in these repositories…That is an entirely different matter!