Archive

Archive for the ‘Distributed Setup’ Category

March 5th, 2009
Comments

In my last few posts, I described how to install a Content Server with distributed filestores. In this blog post, I’ll discuss a few DQL queries to track your files in a distributed setup.

The first set of DQL queries will help you get information regarding storage of content, include its filestore and path:

This query returns the actual file system path to object’s content file. Use this query in conjunction with the second query to find out exactly where your content files are stored on the content server.

To find file system path of an object’s content file:

select file_system_path from dm_location where object_name in (select root from dm_filestore where name in(select a_storage_type from dm_document where r_object_id = ‘object_id’))

To find file store a file is saved on:

Now that you have the file system path, use the following query to identify the file store your file is stored on:

select a_storage_type from dm_sysobject where r_object_id = ‘object_id’

With above two queries, you should be able to zero down on the location of the file.

To find the default file store of a type:

To find out the default filestore for a type (e.g. my_document), use the following query:

select name from dm_store where r_object_id in(select default_storage from dmi_type_info where r_type_id in(select r_object_id from dm_type where name = ‘my_document’))

You can also find the default location for a type via DA. Just log on to DA and go to “Types” in the navigation tree on left. Browse or Search your desired type and check default storage.

To find out disk space used by a particular file store:

select sum(content_size) from dmr_content where storage_id in (select r_object_id from dm_store where name =  ‘file store name’)

Again, this can also be checked via DA (DA->Storage->filestore)

And finally, to find out the root directory of the filestore of particular type i.e. my_document, use the following DQL

select file_system_path from dm_location where object_name in(select root from dm_filestore where r_object_id in(select default_storage from dmi_type_info where r_type_id in(select r_object_id from dm_type where name = ‘my_document’)))

In my next post, I’ll discuss tips and tricks to identify and resolve issues in a distributed setup.

[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Digg]  [Post to Reddit]  [Post to StumbleUpon] 

admin Content File Server, Distributed Setup, Documentum, Documentum 6.5, Documentum distributed setup, Remote Content File Server, single repository distributed storage , , , , ,

Distributed Setup in Documentum: The Verdict

January 15th, 2009
Comments
In my last few posts, we discussed installation and configuration of a distributed docbase. It might have seemed a bit complicated to the untrained eye, but it is a really simple process - you setup your primary site first, identify and define network locations, create filestores and then finally associate these store with network locations. The primary reason we setup a docbase with distributed filestores is to improve performance when accessing documents from remote locations and branch offices. To ensure that this setup actually works, I finally set out to test my configuration. And the results were indeed quite astounding.
Before I discuss the result, I would like to point out a few things. The installation was done one two sites - the primary site being where I work (with full content server) and a branch office located some 500 KMs down south, connected by a 1 Mbps link. The test machines on both the sites were exactly similar. The test process was fairly simple - I did two set of measurements for each central and distributed model. One from local head office to access local documents and one from remote site. The measurement was a simple one - for storing documents, I measured how long it takes to get back to main webtop screen AFTER I press OK on document properties popup dialog that comes after dropping a file in webtop. For retrieving documents, it was simple. Double click on a file and measure how long does it take to open. I repeated the tests atleast 5 times to average out values and get a better estimate.
Local (Normal) denotes time for accessing a local document under a normal central setup while Remote (Normal) denotes time for accessing a document from regional office under the same central setup. Local (Distributed) setup denotes the timing for accessing a document locally (head office where content server is installed) and Remote (Distributed) denotes time for accessing a document from the regional office where only a file store is installed. And here are the results

Results for storing a document:

File Size Local (Normal) Remote (Normal) Local (Distributed) Remote (Distributed)
50 1.6 Sec 2.5 Sec. 1.5 1.5
50-100 Kb 1.3 Sec 2.5 Sec. 1.3 1.3
100-300 Kb 1.7 Sec 3.7 Sec. 1.7 1.7
300-500 Kb 1.9 Sec 6 Sec. 1.9 1.9
.5 - 1 MB 2.2 Sec 12 Sec. 2.2 2.1
1-2 MB 2.3 Sec 20 Sec. 2.3 2.3
2-4 MB 2.9 Sec +30 Sec. 2.9 2.9
>4 MB 2.9 Sec +50 Sec. 2.9 2.9


Results for retrieving a document:

File Size Local (Normal) Remote (Normal) Local (Distributed) Remote (Distributed)
50 1.7 Sec 4.5 Sec. 1.7 1.9
50-100 Kb 1.6 Sec 4.5 Sec. 1.6 1.9
100-300 Kb 1.6 Sec 5.5 Sec. 1.6 2
300-500 Kb 2 Sec 6.8 Sec. 2 1.9
.5 - 1 MB 1.5 Sec 11 Sec. 1.5 2.4
1-2 MB 1.6 Sec 27 Sec. 1.6 2.1
2-4 MB 2 Sec +35 Sec. 2 2.4
>4 MB 3 Sec +55 Sec. 2 4.7
Verdict? I guess you are smart enough to figure out. However, there are a few things that you must keep in mind before adopting an enterprise wide distributed model. First, you can NOT revert a distributed store back to a central model, without sacrificing your Christmas vacations - Official documentation says it is impossible. And second, this model is suitable only where you have different regions accessing not only same documents, but also same applications and it makes sense to actually have a single repository. For example, if I want to setup up a distributed storage for all our offices in South Africa, I’d rather setup a distributed file store at each regional office than a new docbase at each regional office (Federation). I would consider a federation only if I consider overseas offices - cause logically they represent different units altogether (region/locale/document types/compliance issues etc).

[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Digg]  [Post to Reddit]  [Post to StumbleUpon] 

cucumberboy Distributed Setup, Documentum, ROI, Remote Content File Server, performance improvement, results, single repository distributed storage , , , , , , , , ,