2nd content server very slow - what to do?

What does your dfc.properties for DA look like?

Julien.Fontaine

Please post your dfc.properties of your app server.

Which CS version you use ?

I use CS 6.7.0020.0225 Win64.SQLServer.

The dfc.properties of the second Content-Server (C:\Documentum\config\):

dfc.data.dir=C\:/Documentum

dfc.search.ecis.enable=false

dfc.search.ecis.host=

dfc.search.ecis.port=

dfc.tokenstorage.dir=C\:/Documentum/apptoken

dfc.tokenstorage.enable=false

dfc.docbroker.search_order=sequential

dfc.docbroker.host[0]=contentsrv02

dfc.docbroker.port[0]=1489

dfc.docbroker.timeout[0]=10

dfc.docbroker.host[1]=contentsrv01

dfc.docbroker.port[1]=1489

dfc.docbroker.timeout[1]=10

dfc.security.keystore.file=...the path...

dfc.globalregirstry ....the global registry settings (repository, username, password)...

dfc.codepage=ISO_8859-1

dfc.session.max_count=1000

dfc.session.max_collection_count=30

dfc.bocs.check.keep_number = 3

dfc.bocs.avail.refresh_interval = 1800

dfc.session.connect_timeout=10

I highlighted the settings I was experimenting with lately. In my original configuration they weren't set. However I didnt notice any real difference.

Since we're on that topic: Which dfc.properties do I need to change besides the one of the CS? The one of the web application? The ones of xPlore, ADTS, and so on as well?

Julien.Fontaine

For App SErver configuration, you have to change your dfc.proeprties of your web app (da).

"The problem I just noticed is that shutting down the first content server makes the whole system terribly slow."

- Are you shutting down the physical server or just content server service? If the latter, you need to also shutdown docbroker in order for failover to perform as designed.

bacham2

That's not correct Johnny. The docbroker should reflect the fact that the Content Server has been shut down and the failover should occur as designed.

I believe the docbase projection (that its no longer running) is not instantenous. It depends on docbroker refresh interval. I often find it easier to shut down docbroker as well (why keep it up).

If the docbroker is down, the client app (web app) should immediately redirect to the other docbroker.

Do you have dfc.docbroker.auto_request_forward=true in your application server's dfc.properties?

The dfc.docbroker.auto_request_forward key controls failover. By default, a connection request is handled by the first connection broker listed in the file. However, if that connection broker does not respond within 15 seconds or less or does not know about the requested repository, failover occurs since another connection broker is defined and auto_request_forward is TRUE. The request is forwarded to the next connection broker in the file.

Rijo,

What happens if the auto_request_forward stays as false?

Failover occurs only if another connection broker is defined AND auto_request_forward is set to true. BTW, it is set to TRUE by Default.

I should rather say "Do you have dfc.docbroker.auto_request_forward=false in your application server's dfc.properties? If yes, change it to TRUE or remove it", to avoid confusion.

Alright, sorry for the late response. Here we go:

* I shut down the whole machine (for simplicity reasons)

* I didnt set auto_request_forward, so I guess it's the default (true). The failover itself does work - it's just slow

Regarding the relevant settings in the dfc.properties:

I just spoke to a collegue and I guess the BOCS-stuff is not relevant for us. So I'll remove it.

What about dfc.docbroker.timeout[x] and dfc.session.connect_timeout? What are recommended settings for an environment that is set up in 1 LAN (no distant servers)? What is the effect of docbroker.timeout[]=0 (the default)? The dfcfull.properties says that in this case DFC will take the timeout of TCP/IP - how many seconds is that?

I also did some more tests while having CS#1 shut down: At first it's really slow. If I keep clicking/navigating it gets faster up to the "normal" speed. So the failover itself should work.

So lets focus on the speed of the first request. Which setting determines the time DFC waits until it considers it a timeout? dfc.docbroker.timeout? dfc.session.connect_timeout? Both?

Basically I need to change:

* The time DFC waits until it considers the request 'timed out'

* The time DFC waits until it tries again to contact the timed out server

And: Once a timeout has been recognized, does this affect only the current user' session (so that another user has to wait again x seconds until his session recognizes the timeout) or does it affect the whole server (so that only 1 user has to wait for the timeout and the others can benefit from that "experience" and automatically only use the second content server)?

Do you have information on that? That'd be great!

Thanks for your great help so far! I really appreciate it!

Best regards,

Mbacct,

I hope you followed the CS instsallation guide and ran the cfsConfigurationProgram.exe to setup the HA environment? Can you post your server.ini & dfc.properties from both Content Servers and also post the dfc.peoperties from the application server?

From dfcfull.properties -

The amount of time in seconds to wait for response from each connection broker. If set to 0 then DFC will not impose a time limit of its own and will rely upon the standard TCP/IP timeout. For Example, dfc.docbroker.timeout[0] = 1 will set the timeout 1 second for docbroker at index 0 and all other docbrokers will use default timeout.

# prototype value: 0

# min value: 0, max value: 60

dfc.docbroker.timeout = 0

https://community.emc.com/message/595525#595525

Rijo,

thanks for your responses!

@response #1: Yes, I guess. I installed the second content server by choosing "Configure Content-File Server for use with an existing repository". Then I added in all dfc.properties the second docbroker manually, as well as the [DOCBROKER_PROJECTION_TARGET_1] in both server.ini's. I guess that's sufficient?

Do the proximity values matter? I chose "9001" for the local server and "9010" for the other server (that's what the setup entered automatically in the server.ini of the second content server.

I added the files you asked for below.

@response #2: Yes, I've read that, too. But honestly I have no idea how the standard TCP/IP timeout works...is it not time-based?

------------------------------------------

dfc.properties of content-server #1

(C:\documentum\config)

dfc.data.dir=C\:/Documentum

dfc.search.ecis.enable=false

dfc.search.ecis.host=

dfc.search.ecis.port=

dfc.tokenstorage.dir=C\:/Documentum/apptoken

dfc.tokenstorage.enable=false

dfc.docbroker.search_order=sequential

dfc.docbroker.host[0]=CONTENTSRV01

dfc.docbroker.port[0]=1489

dfc.docbroker.host[1]=CONTENTSRV02

dfc.docbroker.port[1]=1489

dfc.security.keystore.file=C\:/Documentum/config/dfc.keystore

dfc.session.secure_connect_default=try_native_first

dfc.globalregistry.repository=MYDOCBASE

dfc.globalregistry.username=dm_myuser

dfc.globalregistry.password=--mypasswd--

dfc.codepage=ISO_8859-1

dfc.session.max_count=1000

dfc.session.max_collection_count=30

dfc.session.connect_timeout=10

dfc.properties of content-server #2

dfc.data.dir=C\:/Documentum

dfc.search.ecis.enable=false

dfc.search.ecis.host=

dfc.search.ecis.port=

dfc.tokenstorage.dir=C\:/Documentum/apptoken

dfc.tokenstorage.enable=false

dfc.docbroker.search_order=sequential

dfc.docbroker.host[0]=CONTENTSRV02

dfc.docbroker.port[0]=1489

dfc.docbroker.host[1]=CONTENTSRV01

dfc.docbroker.port[1]=1489

dfc.security.keystore.file=C\:/Documentum/config/dfc.keystore

dfc.globalregistry.repository=MYDOCBASE

dfc.globalregistry.username=dm_myuser

dfc.globalregistry.password=--mypasswd--

dfc.codepage=ISO_8859-1

dfc.session.max_count=1000

dfc.session.max_collection_count=30

dfc.session.connect_timeout=10

dfc.properties of web application

(C:\tomcat\webapps\application-name\WEB-INF\classes)

dfc.docbroker.search_order=sequential

dfc.docbroker.host[0]=CONTENTSRV01

dfc.docbroker.port[0]=1489

dfc.docbroker.host[1]=CONTENTSRV02

dfc.docbroker.port[1]=1489

dfc.globalregistry.repository=MYDOCBASE

dfc.globalregistry.username=dm_myuser

dfc.globalregistry.password=--mypasswd--

dfc.session.connect_timeout=10

server.ini of content-server #1

[SERVER_STARTUP]

docbase_id = 123456

docbase_name = MYDOCBASE

server_config_name = MYDOCBASE

database_name = DM_MYDOCBASE_docbase

database_conn = MY_ODBC

database_owner = MYDOCBASE

database_password_file = C:\dbpasswd.txt

service = dm_MYDOCBASE

user_auth_target = CONTENTSRV01

install_owner = myinstallowner

history_cutoff=5

# A boolean flag specifying whether user entries and groups list are synchronized from db.

upd_last_chg_time_from_db = F

# Interval, in second, for checking session user's status.

check_user_interval = 0

# This controls the number of concurrent users that can

# be connected to the server at any given time.

concurrent_sessions = 100

# This controls the dmbasic method server.

method_server_enabled = T

method_server_threads = 5

# A boolean flag specifying whether all Index Agent(s) configured for this repository needs to started automatically during server startup or not

start_index_agents = T

use_estimate_search = T

preserve_existing_types = T

enforce_four_digit_year = T

[DOCBROKER_PROJECTION_TARGET]

host = CONTENTSRV01

port = 1489

proximity = 9001

[DOCBROKER_PROJECTION_TARGET_1]

#host =

#port =

#proximity =

host = CONTENTSRV02

port = 1489

proximity = 9010

server.ini of content-server #2

[SERVER_STARTUP]

docbase_id = 123456

docbase_name = MYDOCBASE

server_config_name = bnfavpco_MYDOCBASE_Cont02

database_name = DM_MYDOCBASE_docbase

database_conn = MY_ODBC

database_owner = MYDOCBASE

database_password_file = C:\dbpasswd.txt

service = Dm_MYDOCBASE_Cont02

user_auth_target = CONTENTSRV01

install_owner = myinstallowner

history_cutoff=5

# A boolean flag specifying whether user entries and groups list are synchronized from db.

upd_last_chg_time_from_db = F

# Interval, in second, for checking session user's status.

check_user_interval = 0

# This controls the number of concurrent users that can

# be connected to the server at any given time.

concurrent_sessions = 100

# This controls the dmbasic method server.

method_server_enabled = T

method_server_threads = 5

# A boolean flag specifying whether all Index Agent(s) configured for this repository needs to started automatically during server startup or not

start_index_agents = T

use_estimate_search = T

preserve_existing_types = T

enforce_four_digit_year = T

[DOCBROKER_PROJECTION_TARGET]

host = CONTENTSRV02

port = 1489

proximity=9001

[DOCBROKER_PROJECTION_TARGET_1]

#host =

#port =

#proximity =

host=CONTENTSRV01

port=1489

proximity=9010

bacham2

Yes it matters! You should not use proximity values above 9000 unless you are using Remote Content Servers. If you don't know what that it, then you probably don't use Remote Content Servers. Checkout the following post:

It looks good. The slowness is for existing (before server 1 goes down) connections only or for new sessions as well?