The good news about Open Text's ECM suite, or at least about the Content Server based solutions, is that most often it really can scale up in volume to very large numbers. While I am not personally aware of any single deployment that has reached one billion records, I am confident that it can be done. It won't be cheap, nor painless, but it can be done.

The bad news is that each of the five or more distinct components of a solution all scale in various and different ways. The five I speak of are:

1. Web Server (livelink.exe, llservlet, llisapi.dll, )
2. Livelink Server (llserver.exe)
3. Livelink Admin Services (indexing, search, notifications, elink, administration)
4. Relational Database Management Server [RDBMS] (Oracle, MS-SQL)
5. Storage services (EFS, Archive Server)

Each of the above have different strategies for scaling and different parameters that are of importance to scaling. 

Web Server

Where once the web server was a minor, almost inconsequential piece of the puzzle that at worst caused some configuration confusion and at best provided a great deal of deployment options. Until (and unless) Enterprise Library Services got involved or (for the few brave that use) Java modules (do you remember "my home"?), the web server cost per transaction was almost too small to accurately measure and was certainly insignificant. That remains true today if the main computing engine is Liveink Enterprise Server or Content Server as it has recently been re-branded (I'll just refer to it as LES for now).

Scaling is dependent on the chosen architecture -- do you want a 1:1 match of web server to LES servers or do you want a 1:many ratio? Do you want to dedicate a web server or utilize existing web farms? Do you have a need/requirement for multiple network tiers? If the answer is "1:1, Keep It Simple Stupid" then you can mostly ignore the web server, just watching out for RAM use due to too many processes.

Now, if you are looking at solutions that are based on Enterprise Library Services then the web server is a major component that all but requires dedicated servers / resources. Where the footprint of livelink.exe (llservlet, llisapi.dll) is relatively small, the web or more correctly J2EE Application Server is a heavyweight, resource-guzzling process. The unfortunate part is that there is very little information about scaling this process out at this stage. As a web service engine it is supposed to provide great client-side scaling possibilities but at the server end there is, I'm afraid, much yet to learn.

It will depend, of course, but my money is on RAM being the tight resource with the J2EE Application Server (which is Tomcat or SAP's Netweaver) ... Java is not known for it's small memory footprint!. In any case, the scaling is simple, install a single server of Tomcat and provide it with the parameters it needs to use 90% of available RAM and/or 80% of available CPU (sustained).