cancel
Showing results for 
Search instead for 
Did you mean: 
Subscribe

Hi folks,

i do have several customers that have performance problems with their enterprise portal.

But these problems don´t have to be "real" problems with the portal itself. It is also possible that they are based in connection to the backend system, they can be network problems, slow database(s), the j2ee engine etc...

Do you know a tool or a process that will enable people like me to find the real problem systematically? Do you have an idea what to test first, have a look at what kind of logs to get some information about the performace bottlenecks?

The best case would be a unified process that will check all possible bottlenecks systematically (does not have to be automated) and help the guy doing the measurement in finding the solution. Is there anybody who already has a solution for this problem?!

I hope you can help me

Kind regards

Michael

0 Likes
View Entire Topic
joerg_nalik
Explorer
0 Likes

Hi Michael,

I can feel with you and your customers as I have had very similar experiences. There might be no ultimate solution since every customer case has its individual challenges. However, here some tips:

- process/methodology: most important! If there is no clear concept for your approach likely a lot of time and money will be wasted. The strategy which worked best for me is start with small simple tests first, like do a manual 1 user test and use all available monitors for OS, databases, back-ends, network, back-ends to get clues. The work your way up to load tests. More is described in https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/how to perform sap enterprise portal load testing.zip

One thing to add beyond this paper is that you want to test individual systems, like back-ends first for performance by themselves before moving on to EP embedded scenarios. You also want to start with LAN tests and then move to WAN tests. WAN tests can be challenging to do but are often important to see the "end-user" true experience.

- tools: all available monitors, Mercury Loadrunner for load testing.

- network: In particular if end-users are sitting on other continents network latency time becomes often the dominant response time contribution part. Do two things: Reduce number of application roundtrips as much as possible (see above paper for details) and get the network IT people into the boot to see what they can do from their end.

All the Best, Joerg