Central MDM Performance

[Former Member]

MDM: 7.1 SP6

CE 7.2

Fields in main table (customer): 75

Total records: approx 500,000

MDM JAVA API and Web Services Configurator used

Hi,

Has anyone, using MDM for central master data maintenance, carried out performance tests on their systems? Do you get good performance (lets say 3-5 secs response). Does your system scale when multiple users send concurrent requests to the MDM server to update records? Do you experience a bottleneck due to MDM product design?

Any learnings will be much appreicated...

Thanks and regards,

Shehryar

[Former Member · Accepted solution]

We have been VERY involved in Performance Measuring and Tuning of our SAP MDM implementation.

We use Check Out / Check In on all of our edits, which adds lots of extra overhead. We have about 20 Data Manager users and more in portal during normal business times. And about 1.2 million records in our main table, with a dozen qualified tables.

The changes that SAP has made, particularly in SP06, have had a positive impact, but the Repository locking for every write still causes us lots of challenges. We have tuned our Slicing parameters to wait from 15 - 30 seconds (15000 - 30000 milliseconds in the config) with slices as small as 50, and have gotten some, but limited relief.

We're working on solutions to see if we can eliminate Check Out, but haven't finalized any design changes yet, as we have business requirements that are hard to meet (like compare to original and rollback) that require this functionality, or something like it.

Hope this helps,

Steve

[Former Member · Accepted solution]

Hi Steve,

Excellent, to the point response. Much appreciated. I guess this is what happens when you share the pain

The situation we have is that we brought in SAP for a Technical Feasibility Check. The guy from SAP support was fairly upfront about the limitation in design which causes the locking issue. However, the alternative he suggested doesn't go down the throat very well. His suggestion was to create a staging area in the CE server and use that as an interim repository until data is ready to be moved into MDM repository. This can address the locking issue to a certain level by using JAVA API to lock/unlock records at the CE DB level, thus reducing the load on MDM server. But you get into searching/validation issues as this solution means two different repositories have to be kept in sync, searched and validated against. Moreover, we need a data structure in CE DB essentially replicating MDM schema.

Then there is a bigger question: SAP recommends using DataServices for data quality (de-duplication and cleansing); SAP offers support to use DataServices for matching strategies; SAP recommends using CE for the process management layer, SAP offers PI adapters for MDM data syndication/import; and now we have a proposal to even move the staging area to CE. I don't see where NW MDM adds value then???? In case of CMDM, is the customer spending money for having a data repository that does not scale?

This issue highlights the fact that MDM is not ready to be used as an enterprise level CMDM solution. We need MDM Product Management to be clear here about the benchmarks they have run and against what architecture. None of the published weblogs or webcasts suggest that the CMDM scenario actually requires another staging area outside MDM to be able to scale. [This solution|http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a08cae34-e122-2d10-bebc-9371449b1e9a?quicklink=index&overridelayout=true] looks like an alternative approach but still does not give an benchmarks. Have you tried this approach? Thoughts???

Regards,

Shehryar

[Erdal_Şimşek · Accepted solution]

Hi Shehryar,

what OS system do you use? I have experienced that especially on AIX/Unix systems performance issues occur because of incorrect AIX memory handling parameter settings (e.g. "ulimit"). As an example - although one of my customers had 60GB RAM we got memory and therefore performance issues because ulimit was set to 32MB. In general I would say - this is really important to have all these parameters right!

Pls do also check following notes:

1. 1282668 - Performance settings for AIX

2. 973227 - AIX Virtual Memory Management- Tuning Recommendations,

3. 1012745 - Tips for improving MDM performance,

4. 1240587 - MDM 5.5 and 7.1 Low performance when MDM workflow is used,

Moreover, pls do also keep in mind that e.g. MDM Data Manager is actually an administrative tool, i.e. not really suitable for mass user access! Pls do therefore also check # 1512323 - Number of Data Manager instances affects performance. Instead, for that sort of access - you should use e.g. Portal or CE (--> BPM) etc.

If you don't use Portal or CE - pls setup your environment in a way so that import server is used instead of manual modifications!

Example: instead of having 10 users logged on via rich client doing mass changes - you might want to consider a way where you prepare an upload template file (xml or txt format) that you use to feed import server. IS does the job right away, All you need to do is to check whether the import went through the right way etc.

Pls do also not forget to delete all completed workflows as they have a big impact on the MDS performance! In SP06 it is possible to archive them which should be done periodically (e.g. via clix). If you have many WFs to trigger - this really helps increasing performance.

Another important point are all In-/outbounds directories. Here, you might want to bring in periodic jobs that empty your Archive folders (Repository --> Remote System --> Port --> Archive ).

Moreover, delete all unreferenced tables and fields in your data model. You might also want to deactivate change tracking on all fields (in case it is activated). Pls do also check Sort Index parameters, whether you need Stemmers, etc etc etc.

It looks simple to setup a proper working MDM - however it requires a lot of experience and technical expertise!

Hope this helps!

Best Regards,

Erdal

[KlausDavid]

In SP06 performance was one of the areas development paid special attention to. Improvements were achieved in numerous areas like search, update, Import, CheckIn/CheckOut, syndication. While in earlier SP's slicing was only used for imports of records, this strategy is used now also for other operations in the MDM system. Slicing has to be configured in the system, a couple new parameters for slicing in MDS.INI were introduced with SP06.

If after tweaking the system using these parameters there's still no improvement I recommend to open a problem message and let SAP Support look into the issue.

Regards Klaus

[Former Member]

Hi Klaus,

Thanks for the response.

I have looked at the SAP release notes and recommendations on performance optimization. For my question, please assume that all necessary performance tuning has taken place already.

What I am trying to understand is that whether NW MDM, by design, can't scale under heavy load of concurrent users since the write operation blocks the queue and locks the full repository? Has SAP done any performance benchmarking? I haven't been able to locate results. There is just one SAP note for MDM 5.5 which says that SAP used to do benchmarking in their own labs.

Moreover, the MDM sizing guide is based on Reads rather than Writes. So there is no clear information on the scalability of the system when used as a Central MDM system with CE/BPM on top.

[This document|http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a08cae34-e122-2d10-bebc-9371449b1e9a?quicklink=index&overridelayout=true] suggests a way around the concurrency issue by introducing Master/Slave architecture. However, how robust is that design? Even when the synchronization is taking place between the master and slave, the master is locked for further reads and writes. The concurrency issue doesn't go away if there are significant number of users trying to update master data.....especially if the repository is big....

Can you share any experiences?

Regards,

Shehryar

Edited by: Shehryar Khan on Apr 4, 2011 2:46 PM

[Former Member]

Hello Shehryar

First of all.

I dont undestand what is you mean: connect from rich client or through MDM API?

When your repository work slowly?

Maybe you have problem with your hardware or network configuration. In that case check that:

https://websmp102.sap-ag.de/~sapidb/011000358700001921872008E

When you are working through MDM API - main problem with repository connection time.

One connect creation time 1-3 seconds.

If you are working with multilanguage repository - you should create one connection for each language.

Don't close your connections during the session time.

You can optimize your database server performance.

You can switch on indexes in your repository and optimize it structure.

Regards

Kanstantsin Chernichenka

[Former Member]

Hi Kanstantsin,

Thanks for the response.

As you are aware that the MDM application server works on the basis of a single queue. While read operations can be allocated to multiple CPUs in parallel, a write request actually blocks the queue until the database is updated with new data and in-memory record is updated. No reads can take place during this time.

So the question I have is: if you have several users e.g. 10-20 concurrent users trying to update different records in repository, do you experience performance issues? Have you done any performance testing to identify the breaking point?

Thanks and regards,

Shehryar