Issues with speed of loading SPL indexes into TREX

[Former Member]

HI Experts,

We are experiencing issues with extremely slow loading times when transferring our SPL indexes into TREX. I checked with someone implementing a GTS project at a different client and they are having much faster response times. Our Basis team has validated that the table indexes seem correct. I have found 4 SAP notes that have useful clues, but the problem is still not resolved. Has anyone else experienced and resolved a similar situation loading into TREX, even from a different system than GTS? Thanks for your input.

-- Greg

[Former Member]

Do I get to award myself points if I answer my own question?

After lengthy invesitgation, our Basis team discovered that the TREX initialization (INI) file contained the identities of servers other than our GTS server. Once they were removed and/or renamed, the issue disappeared.

Also helpful were running statistics on our Oracle databases as well as setting up batch jobs to clear the buffers and archive logs during initial transfers of data into GTS. Things sped up considerably after that.

If someone else finds this useful, perhaps you could drop a few points on me.

[Former Member]

Hi Greg,

Glad you got it working! I'd be curious to know how TREX affected the performance of the application. Would you by any chance have any benchmarking info you could share, perhaps a before/after TREX and the number of BPs you screened (and which scenario)?

Regards,

Randy

[Former Member]

Greg and I had not done any benchmarking of screening performance with and without TREX (we were more interested in screening quality with and without TREX), but I saw your post and did a quick test.

Running a background A1 and B1 screening of 3K partners with TREX was about twice as fast as it was without TREX (in our current client's test system, this was 5 and 11 minutes respectively). This was a bit surprising, so I did a couple iterations, toggling the TREX flag on and off...but the results were consistent.

We have a database of over 1 million partners and are using the SPL premium lists, which results in three times the SPL entries as you get with just the standard MK lists. I would imagine the delta and document screening performance would be similarly improved with TREX, though do not have the time to test those right now. Will be doing more testing in the future.

[Former Member]

.

[Former Member]

Hi Robert,

Thanks much for this info. It is very interesting. I think-- since its introduction as an option for SAP GTS-- there has been a lot of theory over whether TREX would provide a performance improvement for SPL, but little tangible evidence. As the BP/SPL-entity volume grows at every client, any performance improvement is welcome. Trouble is, in these days given cost constraints it's hard to convince management to allow a test install to see if TREX will help. Better to request having evidence in hand, so your post is helpful. Will be looking forward to any future additional insights!

Regards,

Randy

[Former Member]

Also, the main advantage of having TREX is enchanced Fuzzy search logic. This logic is not in standard ABAP based program. TREX enables a enhancement of SPL error-tolerant search and improves the quality of delivered SPL matches. TREX is smart to match Stefen Pixatti against Steven Picatti SPL entity, not with ABAP based program.

Thanks,

Bala Janarhtanan