As you may have noticed, there is no publicly available Sizing Spreadsheet for the newly released D6 yet. It is my understanding that they are still collecting data and refining it so that they have a high enough level of confidence to back it. However, I was able to get a draft copy recently and I wanted to share some observations.
And no, I cannot send you a copy. If you need one, contact your EMC Account Representative.
Observations
When reading these, keep in mind that I didn’t do a full analysis. I just moved my sizing data from the latest 5.3 spreadsheet to the D6 spreadsheet. Also note that this is a DRAFT. The publicly released version may give different results if they make refinements.
- No change to the Full Text sizing. No surprise there as the engine is the same.
- The Content Server requires almost 3 times the amount of RAM. This is due to the increased overhead of WebLogic versus Tomcat. It isn’t an unreasonable amount. It just means that you actually need to look at that field now.
- Only two User Interfaces were listed, Webtop and TaskSpace on the data collection. I’m assuming that is because if you are using something like Web Publisher, then your Web Application overhead will be the same as if you use Webtop. Obviously Web Publisher users are more likely to be heavy users, so that will change, but there are places for that as always.
- The database usage seemed to require almost 60% less RAM, regardless of choosing Oracle or SQL Server. In fact, it seems like a large chunk, but I don’t have any metrics to back that feeling up.
- There doesn’t seem to be a difference between JVM versions. I think that this is because they only support one version for this release so it doesn’t matter. I expect this will change over time.
Things I’d Like to See
There are a few things I’d like to see in the Spreadsheet. These comments are not specific to the D6 version.
- SQL Server 2000 and 2005 as options. Right now only SQL Server is an option, and I believe that it is still using SQL Server 2000 performance data as it is not dissimilar from older spreadsheets. Check the EMC White Paper, or read my post on SQL Server 2005 for some hints on the differences.
- A better understanding of the usage of the RAM. There is a certain amount of overhead with the application. Then you add the variable components on top of that. Say, for instance, your Content Server. What is the basic “turn-it-on” cost, the user cost, and the Indexer cost?
- It would be nice if there was one spreadsheet that let you pick the version that you were using of Documentum. I know this makes it much more complicated, but it allows me to keep track of only one.
- In addition to Webtop and TaskSpace, how about a column for DFS? This may be a metric collection issue at this point. However, it is a data point that I know I need.
Word of Pie 
Good feedback, Laurence.
Since DFS doesn’t exist prior to D6, your comment for a “DFS column” is D6-specific. That being said, I’d like to know if you have more more specific metadata requirements. For example, DFS can enable a deployment topology to change depending on factors like proximity to repositories (CS), proximity to content (including distributed content via ACS/BOCS), proximity to application middle-tier (services), needs of individual services (compute, memory, storage), etc.
With respect to JVM in D6, it’s true that D6 requires Java 5. That being said, there is more than one JVM provider and there are differences among implementations, performance-wise and depending on use cases/context.
Cheers,
-Craig
LikeLike
Craig, thanks for the response. Ok, so one comment was D6 specific. I’ve updated. As for metadata to collect in regards to that, until I have more experience, I’ll defer to you to tell us what is required. I mean, assuming DFS is co-located, and you are servicing X users on Content Apps (SharePoint) and supporting X users on Integrated Apps (Siebel), what is the overhead required for DFS? This would in addition to what is already there for other apps.
You make a good point about JVMs. However, the spreadsheet just offers a JVM version, not provider. I expect this would only impact the Application Server anyway as, typically, the Content Server and Method Server use the packaged JVMs and are thus set by the Documentum version.
LikeLike
I have a memory-related observation regarding Digital Asset Manager in D6. We have recently upgradeed to D6 and we have found an issue which seem to be related to Java on 32-bit Windows.
We reguarly get PermGen Space errors in DAM (which crashes the whole application) which we think is due to a lot of classes being loaded in the Permanent generation space of the JVM. One way of provoking that is to run reports which renders a use of the Java-based Crystal reports engine. Since Windows can only have a max heap size of 1,5 Gb or so it also means that the PermGen spaces seem to be too small and we have not yet been able to increase that size.
So I wonder if a practical recommendation would be to run DAM on an 64-bit operating system with a JVM that supports a bigger heap size for Java. Would be interesting to hear your comments on this…
LikeLike
Haven’t used DAM in D6. I would suggest running multiple instances of your Web App Software on your server and have one devoted to DAM.
For a server, 64-bit may be worth it. UNIX or Linux is also a nice option for a Web App server.
Oh, and let EMC know if you already haven’t.
LikeLike
Even though I think WebTop has got the biggest improvement, the DAM is a really nice application I think. Well, the thing is that having multiple instances running on the same server won’t help at all. First, because we get these crashes when we run only DAM on one dedicated Windows 2003 Server. We actually started out having both DA and DAM on the same machine and that did not work at all (you could only use on of them at the time).
Since I am not the biggest Windows-fan around I meant *nix when talking about 64-bit 🙂 Actually what we did today was to deploy our DAM to another 64-bit Linux machine with 4 Gb RAM. We allocated 3 Gb for the Java heap and then also found the parameters to increase the perm gen size as well. Now we have not had any crashes so far. However, we think that while running Tomcat on Windows 32-bit the parameters for perm gen size does not work…
Yes, we have escalated that as a ticket to EMC Support…
Next up for us is to switch from a single 32-bit SQL Server 2005 on one machine to a cluster (3 machines) of 64-bit SQL Server 2005. Will be interesting to see if there are any performance gains since the whitepaper suggest so…
LikeLike
does anyone know where the final (or draft) version of the d6 sizing guide(s) are located at EMC Powerlink?
LikeLike
I never found it. I’ve never seen a copy “publicly” available. If I had, I’d gladly share it to save people from looking.
-Pie
LikeLike
Hi,
I’m currently evaluating if Documentum in an SOA context.
We thought originally to use Taskspace for front end. I’ve seen Taskspace and at first glance think the product uses DFC for built in functionalities, only on custom ones (such as Form) can I use DFS or a bespoke web service.
Does anyone knows if that is a correct assumption and point me to the direction of an EMC product (or a product that work with Documentum) where services are used behind the the scene? The idea is that I want to minimize front end development (forms or others) and maximize the reuse of web services.
For example we use an old DMS and the and migration is too costly but I know I can map the old DMS to Documentum 6.5 metadata structure. The datasource service I envisage, in this case, would search for document/metadata in the old or D6.5 respository but present it to the front as D6.5 data (so that the client will be able to migrate independently from the data) reusing D6.5 WSDL.
I hope that make sense.
Thank you for your time.
Regards
Yoram
LikeLike
Most of the new, as of 6.5, interfaces are based upon DFS. Central of these is CenterStage. However, it doesn’t have an inbox built at this time, though it is coming in the near future. That is probably your best option if DFS is your central driver.
LikeLike