D2 performance , Content Server - Database different locations

Has anyone had issues with D2 performance when the Content Server and Database are in different locations. The D2 app server and Content Server are in one location whereas the Database is in a different location. The network latency between the content server and database is about 75ms.

Find more posts tagged with

Comments

jsapaj

a 75ms latency is way too much for a primary CS-DB connectivity. are you working on a distributed Docbase schema? If yes, be sure your server Architecture is correct and D2 WS are as close to the CS as possible.

Typical LAN latency is less than 1 ms on Gigabit networks (the recommended one for a CS-DB connection).

prasan_13

yeah, its a single repository- we have the database , primary content server and D2 in California and then a remote content server , D2 in Boston - it uses the DB in California. Connection between remote content server in Boston and DB in California is causing us these issues

Do you know where i can find this recommendation of the latency requirements for Content Server - DB connection?

Thanks.

jsapaj

In that case you should be projecting the remote Content Server with a proximity value of 9xxx (starting with a 9) and the primary CS staritng with a zero (0xxx): In that case remote CS will only be used to content transfer and primary CS (near the DB) for data.

If response time is still too high you should consider creating a repository on Boston and replicate (relevant) data from California.

prasan_13

We did think about that . But we have users in California too so we cant use the option of projection targets in D2 in California since then users in California would have slowness issues with content download.

We did think about network locations and maybe use that to get content locally. But i think D2 requires us to use BOCS for that. Do you know if we can use the local Boston ACS server for content downloads without using BOCS?

We are basically trying to figure out if people in Boston can use the California D2 ( which has CS and DB local and is fast)

but still use the local Boston ACS server for content download.

Any ideas would be greatly appreciated.Thanks

jsapaj

"We did think about that . But we have users in California too so we cant use the option of projection targets in D2 in California since then users in California would have slowness issues with content download."

No, this is not how this is addressed:

1. California users would still be using it's local CS for everything (PT=0001 to it's local Docbroker). California CS should project itself to Boston Connection Broker with something like 0100). Boston CS should project to it's local CB with a value of 9001 and to California CB with a value of 9100).

2. You need to create a "Distributed Store" Object and include on this store relevant California and Boston Filestores (related to content that will be accessed by local and remote users). Your location objects pointed by the Filestores must be configured to be accessed in a UNC or NFS address. For example, instead to point to "D:\Documentum\Filestore_02" it should be something like "\\servername\d\Documentum\Filestore_02".

3. You must now configure each server config object (SCO) and configure it's "far store". I.E. For California SCO you need to put in there Boston's file store. For Boston SCO you need to configure California's filestore that would have the effect that California Users will save its documents on California CS and Boston Users will save it's content on Boston CS. While still be able to access remote (a.k.a. distributed) content.

4. Take a look at your dfc.properties file on Boston site (On CS and D2 machines) and try to tune the following parameters (default values shown) those parameters will help to mitigate the latency problem with the Database:

# This controls BOTH the client to server and server to Database batching of

# query data. It can be used to affect the performance based on the performance

# of the network links. It is a hint in the sense that there is no guarantee

# that the value will be honored; for example if the number is too large it will

# be rounded down.

# For client to server traffic it controls the number of rows transported each

# time a new batch of rows is needed in while processing a query collection. For

# server to Database traffic this affects the number of rows returned each time

# a database table is accessed.

# The default value is usually adequate. Sometimes a larger value can improve

# performance in a high latency environment.

# min value: 1, max value: 1000

dfc.batch_hint_size = 50 (increase this number to make your client less "chatty" and transfer more data per request)

# default insert batch size

# min value: 1, max value: 1000

dfc.batchmanager.max_batch_size = 20 (same as above but for improve write)

# When set to T this causes content tunnelling to use data compression. This is

# recommended when network latency is high. Thus for phone connections

# compression is recommended. For standard, local area, network connections

# compression is not recommended.

dfc.content.use_compression = false (enable this if you have low bandwidth only)

# This controls BOTH the client to server and server to Database batching of

# query data for the search services only. If set this property will overrides

# the dfc.batch_hint_size property value for all queries generated by search

# services. It can be used to affect the performance based on the performance of

# the network links. It is a hint in the sense that there is no guarantee that

# the value will be honored; for example if the number is too large it will be

# rounded down.

# For client to server traffic it controls the number of rows transported each

# time a new batch of rows is needed in while processing a query collection. For

# server to Database traffic this affects the number of rows returned each time

# a database table is accessed.

# The default value is usually adequate. Sometimes a larger value can improve

# performance in a high latency environment.

# min value: 0, max value: 1000

dfc.search.batch_hint_size = 0 (increasing this can improve response time in high latency env)

5. Evaluate if your remote users will be needing access to local (California) content frequently. If yes you should configure a Content Replication Job (not an object replication job)

prasan_13

Thanks for all your input. But we were able to use D2-BOCS on the ACS server that lets us download content locally while still using the remote D2 server. So now our performance is much better. Thanks again.