Improving performance for SM35

[Former Member]

Hi all,

Are there any ways to improve the performance (time taken to load data) of SM35?

We are aware of executing the session in backgroud, but due to high data volume (~>10,000 records) per file, the time taken is still slow (about 3 hours per file).

[Former Member]

Hi all,

Are there any ways to improve the performance (time taken to load data) of SM35?

We are aware of executing the session in backgroud, but due to high data volume (~>10,000 records) per file, the time taken is still slow (about 3 hours per file).

[HermannGahm]

Hi,

> Are there any ways to improve the performance (time taken to load data) of SM35?

Trace the execution regarding inefficient coding.

If the execution is efficient parallelization and local update are further options.

Kind regards,

Hermann

[Former Member]

The problem is not with SM35; this just executes your transaction for you.

Rob

[Former Member]

Hi Rob,

Agree that SM35 just executes the transaction but SM35 runs as dialog screen by screen which also effects the performance to complete the session.

Any options to improve the performance of the way SM35 works?

[HermannGahm]

Hi,

maybe i understood you wrong the first time when i suggested to race the application that is executed by SM35.

You have a performance problem within SM35 not with your application?

Kind regards,

Hermann

[Former Member]

Hi,

Yes - I am looking for ways to enhance performance of SM35 by itself.

[Former Member]

What analysis have you done that shows SM35 is the problem?

Rob

[Former Member]

Hi Raj,

The previous posters gave already all the information you need, but since the question is still open, let me try to summarize it.

You're getting almost 1 transaction processed per second, which might be ok depending on the application area and the complexity of the executed transaction. So as Hermann initially pointed out, you should first profile the transaction you're running and check for any inefficiencies (custom coding in exits/BAdI's are often sources of slow-downs). If you find any problems, tune your transaction/application (not SM35).

If your application is fast enough (i.e. you cannot find any easy measures for making your transaction faster), you can compare application/transaction processing time versus total time taken in SM35. I personally doubt that you'll find any worthwhile discrepancy there (i.e. process time taken up by SM35, which is not due to the called transaction). Thus you should be left with Hermann's initial point of running several BDC's in parallel - meaning that you'll have to split your input file (you can automate that if you have to run such loads regularly). Without parallel processing you will always encounter unacceptable processing times when running huge data loads (even with optimal coding throughout the application).

Kind regards, harald

[Former Member]

Hi all,

Thank you for valuable feedback. We have decided to replace the BDC programs to BAPI programs which was tested with significance performance improvement.

Thank you again for your time and comments.