Performance problems when archiving to Centera

Thanks Graham,

Here are the answers:

Q: I do not understand why you are opening existing clips and replacing the blobs if the document already exists, or even how you are determining that the document already exists.

Main reason to open an existing clip is to use the same EBR and static retention start times (note that we use EBR and static retention classes not the explicit periods). The original Clip id is kept in the database and it is available to the application.

Q: As your files are very small, I would also be concerned that you will run into object count issues (even with making use of embedded blobs).

Main reason for this model was the use of retention features (EBR, legal holds) which needs to be managed per individual document (clip). Is there a better way to handle this requerements?

Q: Are you testing with a local cluster?

Yes

Q: How many nodes on the cluster have the Access role?

2 nodes

Q: Do you have plenty of free network capacity?

Yes

Q: Do you share reuse the pool connection and share it amongst your threads? You must not open and close the pool connection for each transaction as this is guaranteed to give very poor performance.

Yes, there is only one (shared) pool connection which stays open all the time.

Based on the above answers, do the performance numbers I am getting reasonable?

Thanks,

andrej

There are many factors that affect Centera performance. Small files certainly do not perform as well as large ones, but you should still be able to achieve decent throughput if you correctly make use of aprallel ingest.I do not understand why you are opening existing clips and replacing the blobs if the document already exists, or even how you are determining that the document already exists. As your files are very small, I would also be concerned that you will run into object count issues (even with making use of embedded blobs).

Are you testing with a local cluster?

How many nodes on the cluster have the Access role?

Do you have plenty of free network capacity?

Do you share reuse the pool connection and share it amongst your threads? You must not open and close the pool connection for each transaction as this is guaranteed to give very poor performance.

Hi Graham,

The clip is 're-written" only if the original doument changes but the revised document must retain the same retention parameters.

In any case the expectation is that there will not be many updates and the initial migration will be creating new clips only. The lower performance of "updates" is not a real concern.

The object count was a concern in the initial design and that was the reason we use 100K embedding limit.

Given the above, do you think that the performance is "reasonable"?
Can you give the "optimal" performance under above conditions.
I am basically looking for some performance results that I can compare against.
If the best/optimal performance for the given clip storage strategy and file sizes is 10 times better than what I am getting I would like to know.

Thanks,

andrej

When you open the existing clip and "repleace" the blobs, in order to persist these changes you must write the clip again. This will result in a new content address and new documents but the same original metadata. Why are you wanting to retain the metadata and retention clock for completely unrelated documents???? I still do not understand why you are storing the documents again if they already exist (or was that a typo in your original post?).

2 Access Nodes should allow roughly 40 threads for ingest and for optimum performance your application should be continuosly "feeding" these ingest threads concurrently. What operating system / hardware configuration are you running?

If your retention use case mandates that you must have this clip format then there is really no other straightforward way to solve the problem. For such small files, we would recommend some form of containerization to store as many of these objects within the same clip - but they would require to have identical retention requirements so it is sometimes not feasible.

Given the overall clip size, you are likely to run out of object count (and lead to capacity being under utilized) so you should try and think if there is a way to change your design so that the average clip size (with your embedded blobs) is an absolute minimum of 100KB.

Please note that in our application model, there is one clip created per two files.

Is the number you are quoting (175 user files per second) achievable in the mode when new clip is created for every two files?

In our model that would mean that we should expect the speeds of about 80 documents per second. This is way above the current observed performance (using 10 or even 20 threads).

Thanks,

andrej

Hi Graham,

OK - so it means that I should expect much higher performance than what I currently have (175 files per second according to the post from TButler in this discussion thread). Correct?

The OS used is Windows 2003 Server.

Thanks,

andrej

Andre - as you are storing your files as embedded blobs, you can effectively regard the clip itself as a single user file. With embedded blobs the data is actually encoded as an attribute and only gets transmitted "over the wire" when the clip is written.

Tim is our Performance Team expert so the answer is yes!

You may not get that high, but you should certainly be able to get at least 2 or 3 files per thread per second (so around 100 or so for the 40 threads of your 2 Access Node system).