That was not the default setting though ! I think it was 6
The default is 3 but leaving it alone at 7 is good. We had a few customers that had poor database performance change it but it did not seem to help much.
Here are some notes from January 2011:
The Appserver does not create more than about 10 connections, all other connections are created by the Frontend Server, i.e. the frontend users. Therefore the number of MaxConnections depends on how many users concurrently work with TM ART. A value of 50 for MaxConnections basically should suffice - it also depends on the capacity of the Oracle Server how many concurrent connections can be processed without significant performance breakdown.
1. With regards to threads, there are 10 CONNECTIONS to the database from the application server that are utilized by the running threads. There will be 1 thread per project for writing results and additional threads for other tasks such as DataDelete for example. The results data are collected from the execution servers and stored in cache until they can be written.
The number of connections is not configurable as too many opened concurrent connections can actually cause performance breakdown.
2. Out of the 10 threads a maximum of 3 connections are used concurrently for writing results, so 3 ProjectResultWriterThreads may be active at any time. The additional connections are used by threads responsible for Rule handling, OldData deletion, Schedule/Blackout handling, Monitor deployment on demand.
It should be possible to influence the distribution by adding a line to the SvAppServerHomeConf.xml directly before the </Config> tag on the last line. Add the following attribute:
Restart the AppServer's service.
We don't expect a big impact as the write times are high for the 3 threads already running, but its possible it may bring some relief and worth a try. Adjust the value with caution as setting it too high will degrade performance further. On one customer's system the value was increased to 5 and performance seemed to improve.
3. The increase in connections may help with both results and TrueLogs written to the database.
== End of notes from January 2011 ===
Thanks Dan, Sachin,
I've noticed the response time on our front end servers is sometimes slow when pulling a lot of data. Was wondering if this had any impact. Doesn't sound like it does.
I'm going to leave the setting alone.
Yes, the TM ART GUI response times are something that I've been fighting with for a long time. Support suggested some index rebuilding etc., but I haven't seen any noticeable effect from that. The only thing that really helps in my case is just restarting the application server service (not the server itself, just the service). After that the GUI tends to load data a lot faster for a while. I usually tend to do that right before some monthly reporting for example.
It's good to know someone else is having the same issues. We regularly rebuild the database. Restarting the application server service isn't an option in our environment. Also tried multiple front end servers but it appears that the database is the issue. tmart writes a lot of data