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
Bluesky
