TREX Performance

[Former Member]

Hello,

our TREX Server has 3 Ghz, 2 CPUs and 4 GB ram. We have indexed 145.000 Documents (30.000 in Windows Filesystem, 105.000 in Lotus Notes).

A Query on this index takes about 15-20 seconds.

Is this a normal response time? I expected, that TREX is faster.

The Folder "index" on TREX Server has 2,7 GB, but when i start a search, TREX uses only 500-900 MB of his main memory.

It seems as if trex executes one query after the other, when more than one query is executed.

Is there a possibility to tune this, for example to increase the number of processes to execute queries? I have read much about preprocessor tuning, but how can i tune the server, that executes queries (i think this is indexserver).

I read the documents about trex and km tuning, but i couldn't find an answer there.

Thank you

regards

Sven

[MichaelSambeth · Accepted solution]

Hello Sven,

which Lotus repository manager and which Domino Version are you using? The SAP RM for Lotus R5 or the Conet RM for Lotus R6 and higher?

Regards

Michael

[Former Member · Accepted solution]

Hello Deepak, hello Michael,

i have no TREX Admin tool installed. So i tried search.py. But so i can only search on one index. The biggest index is 30000 Notes-Documents. A Search with search.py takes 1,5 seconds.

The same search on the same index in the portal takes about 10 seconds.

We have 10 indexes. Would it increase performance, if we create only 2 or 3 bigger indexes?

How can i search in all 10 indexes with search.py?

For Lotus Notes Integration, we use the conet repository manager.

regards

Sven

[Former Member · Accepted solution]

Hi Sven

Unless you have a very special setup most users dont need to search all indexes, but perhaps only 2-3 indexes. Think about which indexes are pre-checked when a user enters the advanced search window - this can be changes in the search options set you are using.

Don't display the total number of hits in the search result - instead you should use the option to only display 1-10 >> more.... In this way the search should avoid to check permissions for all the document hits. This can also be changed in the search options set.

Permissionscheck is taking A LOT of time when the portal is rendering search results from external datasources (depeding on what kind of integration is done, of course). I believe this is the reason why your search from search.py is so much faster - I dont belive there is any permissionscheck done searching throug search.py (but I'm not sure, though).

Don't create 2-3 big indexes, use smaller indexes and precheck only a few of them (those searched most frequently). You could most likely improve your performance with more slave servers that handle the search requests. Making the indexing server more powerfull will only make indexing perform better. But if you have both functions on the same machine, you are of course interested in upgrading that in order to achieve better performance.

Kind regards,

Martin

[Former Member · Accepted solution]

Thank you very much.

I always displayed the number of hits. Turning off this property increased the performance.

[Former Member · Accepted solution]

Another important configuration for increasing performance is described in sapnote 748038. Increase the number of indexes.

For every index, trex creates several indexes in different languages. If only 25 indexes are allowed in main memory and the number of indexes (including language indexes) is higher, performance is very poor.

You can see language indexes directly on the trex-server in the folder indexes.

Sven

[Former Member]

Sven,

1) Perform search directly on the TREX box (using Admin tool) and see if it takes the same amount of time.

2) Check Network connectivity between Portal and TREX box.

3) Have u read the document "Requirements and Recommendations for Using TREX" (http://help.sap.com/bp_epv260/EP_EN/documentation/How-to_Guides/10_TREXRec_en.pdf ), it provides information on TREX configurations. I am in a process of configuring my TREX box using this document.

Hope it helps.

Regards,

Deepak