EP 7.0: FIne Tuning

[Former Member]

Hi all,

We are trying to improve/stabilize the overall performance of our Portal System (EP 7.0). Following note 723909, I have set few Java parameters. This is to tune the JVM. I don't see any significant improvements as such. I have been searching for how-to guides; found some for EP 6.0, nothing specific to EP 7.0.

How do I fine tune EP 7.0 better? Any how-to guide specific to EP 7.0?

Any inputs will be greatly appreciated.

Thanks and regards,

Rosun

[Former Member · Accepted solution]

Hi Rosun,

If you are looking for Portal 7.0 specific howto there is a must read guide

[Performance Best Practices Guide for SAP NetWeaver Portal 7.0|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/f0f1358d-0812-2c10-b58c-c7bdd7a0cdce], but Tobias has already summarized its content.

Best regards,

Alexander Zhukau

[Former Member · Accepted solution]

Hi,

I always see a lot of complaints about EP performances in the SDN forums. My portal in my company is also slow.

SDN forums (running also on EP ) and sapservice are also very slow and not very stable. This is in fact the scary part because if the software vendor can't get good performance from its own software, how would it be possible from the customers ?

I know that on forums, unhappy people post a lot and people with no problems don't post.

I would like to know if there are some EP users happy with the stability and performance of their portals.

Happy users, please, speak out !

That would give me some confidence in the product...

Olivier

[hofmann · Accepted solution]

Olivier,

I do have 2 portals. Portal A is pure standard while Portal B is customized. SAPS for both portals is more than sufficient.

Portal A has a poor performance.

- Logon is done by UIDPW, from an end-user perspective it needs time to see actual content

- navigation is slow because of the TLN and DLN concept

- iViews need some time to load

- UWL fetches data from backend, depending on the user and the number of items, this needs sometimes longer

- ITS get's loaded when starting ESS/MSS transactions every time the user clicks on a Tx.

- MDM has the usual performance, that is: user selects 1 item in iView A and the details get loaded in iView B, all depends on the time needed to load this data from the backend.

Portal B has a good performance

- logon is done by SSO -> faster access to the portal from the end-user perspective

- Navigation is done by NavTarget, user can bookmark the link in the browser and access it directly

- 1 navigation menu only, direct access to all navigation levels (most users only have to navigate to the 2nd, 3rd or 4th level)

- custom iViews, reduced the number of browser requests to the server and the size sent from the portal

- better use of portal + browser caches

- custom ESS/MSS applications combine in one screen several transactions. No switching between Tx needed

- same for Web Dynpro applications

br,

Tobias

[Former Member · Accepted solution]

Thanks Tobias for sharing your EP performance Experience.

It shows that you had to do heavy customizing and tuning to get good performance.

I think that the performance of a software should already be good when installed just out of the box.

SAP products are becoming so complex that the TCO is becoming very very high to get good results.

It is a big problem for us, SAP professionals, because customers are trying to reduce costs.

I try to push for SAP products in my company (because I make a living from it) but it is becoming harder and harder...

Olivier

[hofmann · Accepted solution]

Olivier,

I won't call it heavy customizing. Considering other portals (IBM, MS, Oracle) you get a default portal that has to work with every thinkable customer need. To speed it up, you have to adopt their standard to your needs. The SAP Portal is no difference.

I think someone has to look at the default Portal as a suggestion, a demonstration of what is possible.

The problem is that SAP isn't delivering more default options. You get the TLN and DLN and not just a 1 navigation. You get iViews that obviously got coded by different persons + coding standards (once every javascript is minified, next iView everything is still in debug mode).

Performance can be increased by cache optimizations of the portal. And there is still the AccAD product.

br,

Tobias

[Former Member]

Answered.

[Former Member]

Hi Rosun,

I´m looking for information on Portal Tunning, could you share how did you solved your issues?

Thanx in Advanced!

Kind Regards,

Gerardo J

[Former Member]

Hi Gerardo,

Are you facing any issues/problems with the portal in particular?

Here is what we did. We made few parameter changes following note 723909. Also, please take note of the various links/documents that are in the replies as above to understand about best practices in fine tuning.

Thanks and regards,

Rosun

[Former Member]

Hi Rosun,

Thanx Alot for sharing this information!

Really apreciate it!

Kind Regards,

Gerardo J

[anja_engelhardt2]

Hi,

just one additional comment on the 3rd point of your question:

"For ceratin user ID's, login takes a lot of time"

Do you use a very deep tree of delta links for your roles? Maybe those users also are involved in multiple personalization searches... It can take a lot of time having users with very large roles. You may run the PCDOverview tool of note 1086644 - be careful, this tool runs some queries against the DB so let it run in the night to catch all the data. The output gives you a good overview of this.

Furthermore do you use the CachePreloader Service for roles?

Regards

Anja

[anja_engelhardt2]

Hi,

sometimes a HTTP trace also shows that not the portal itself behaves slowly but the backend operation takes much time. Or the LDAP connection or what else. Please specify in detail what are you looking for.

Regards

Anja

[hofmann]

Hi,

what do you want to fine tune? The portal crashes, is slow , the logon needs a long time, applications need a long time to get loaded, end-user waits for ages to see the first screen, navigation is slow, KM access is unusable?

The SAP recommendations are quite generic:

- Java heap size

- KM access

- Caches

- Cluster

After you have applied these recommendations and the portal is still slow, you need to identify a specific problem and focus on it. So, whats you specific problem?

br,

Tobias

[Former Member]

Hi Tobias,

I see that the question needs a better way to put it through.

We have the following irregularities:

1. When the system is restarted, it takes a lot of time (30 to 45 mins) to come up (not everytime though).

2. For certain user ID's, UWL takes a long time to show up.

3. For ceratin user ID's, login takes a lot of time. I am guessing, this has to do wtih the portal roles assigned; the landing page seems different for different user ID's.

4. We have different portals (DEV, QAS etc) in our landscape. Certain user ID's (as the same or different ID's) who are trying to log in and work simultaneously in two portals seems to be getting "500 internal error"s.

Thanks and regards,

Rosun

[Former Member]

Hi Rosun,

My comments are inline

1. When the system is restarted, it takes a lot of time (30 to 45 mins) to come up (not everytime though).

Can you please check if database is sized or not. Also, please check the startup logs for any errors.

2. For certain user ID's, UWL takes a long time to show up.

Can you please try and clear the cache for UWL from System Admin, and then ask the users to try again.

3. For ceratin user ID's, login takes a lot of time. I am guessing, this has to do wtih the portal roles assigned; the landing page seems different for different user ID's.

Normally, the caching happens after the first user has logged into the portal. In case, these users are accessing roles/ applications which are not being used by other users, then yes, it might take a bit of time. However, it could also depend on network/ no of users logged in to portal at that time.

4. We have different portals (DEV, QAS etc) in our landscape. Certain user ID's (as the same or different ID's) who are trying to log in and work simultaneously in two portals seems to be getting "500 internal error"s.

Can you please which backend application is being accessed over here. You might have to increase timeout of ICM parameters or might have to look at the application if this is taking huge amount of time.

Thanks,

Nikhil

[hofmann]

Hi Rosun,

let's try to find at least some indications on how to solve your performance problems

1. When the system is restarted, it takes a lot of time (30 to 45 mins) to come up (not everytime though). 

That's normal. During startup of portal <7.3 the server will loada lot of applications that you don't even use, like guided procedures. That is one of the performance improvements made in 7.3: it won't load everything.

To ease this, maybe you don't restart the whole AS Java but just the IRJ application.

2. For certain user ID's, UWL takes a long time to show up.

How many work items do these users have? Do they load work items from an ABAP backend? Check the connection to the backend and the UWL cache / refresh mode. If it is set to pessimistic, the UWL isn't really making use of the cache

3. For ceratin user ID's, login takes a lot of time

Are the navigation and UME caches activated? The UME datasource is LDAP, Portal or ABAP? Maybe you are hitting a maximum connection setting?

Certain user ID's (as the same or different ID's) who are trying to log in and work simultaneously in two portals seems to be getting "500 internal error"s

That's interesting. Your portals are sharing some resources? The users are using different instances of the browsers or the same?

br,

Tobias

[Former Member]

Hi Tobias,

Thanks a lot for the crisp reply!

1. So 45 minutes is normal. I will make my peace with that. Point also noted about starting only the IRJ application.

2. Number of work Items differ from user to user. They load from ABAP backend. Connection is fine. Cache is in use.

3. UME is integrated to both LDAP and UME Database. How to activate navigation and UME caches? How do I check if I am hitting a maximum connection setting?

4. The portals are NOT sharing any resources. The users are using different instances of the browser.

Regards,

Rosun

[Former Member]

Hi Bansal,

Thanks for the reply.

Here are the answers to your queries.

>

>  
> Can you please check if database is sized or not. Also, please check the startup logs for any errors. 
> 
> 

Yes, the Database is sized. Logs never show any significant errors.

>

>  2. For certain user ID's, UWL takes a long time to show up.
> 
> Can you please try and clear the cache for UWL from System Admin, and then ask the users to try again.

Done that. But this keeps on happening on a regular basis.

>

>  3. For ceratin user ID's, login takes a lot of time. I am guessing, this has to do wtih the portal roles assigned; the landing page seems different for different user ID's. 
> 
> Normally, the caching happens after the first user has logged into the portal. In case, these users are accessing roles/ applications which are not being used by other users, then yes, it might take a bit of time. However, it could also depend on network/ no of users logged in to portal at that time.
> 
> 

Do you mean that caching happens for the first user login everytime? This seems very plausible. We are at a later part of Testing and the problem seems less due to too many number of users logged in all at once.

>

> 4. We have different portals (DEV, QAS etc) in our landscape. Certain user ID's (as the same or different ID's) who are trying to log in and work simultaneously in two portals seems to be getting "500 internal error"s.
> 
> Can you please which backend application is being accessed over here. You might have to increase timeout of ICM parameters or might have to look at the application if this is taking huge amount of time.
> 
>

At the backend, services from CRM and ECC are being accessed (we use SSO). How does increasing the ICM time out help?

Regards,

Rosun

[Former Member]

Hi Rosun,

In addition to all of the above mentioned by fellow community members I recommend the following:

At first, check your JDK version and update it to the latest one available for your software platform, especially if you have JDK older then 1.4.2_20. I had worked for a client who has an outstanding hardware solution based on Sun M5000 servers with more than enough RAM, but JDK 1.4.2_15 was a main culprit of poor portal performance.

At second, if you have Oracle DB you have to periodically update the database statistics on the portal tables (refer to [Note 1017324 - EP on Oracle: Poor portal performance|https://service.sap.com/sap/support/notes/1017324]). I believe there should similar procedures for other databases as well.

At third, keep portal log directories within size limits.

And last but not least avoid using worksets and chains of delta linked PCD objects in your roles.

Best regards,

Alexander Zhukau