Skip to end of metadata
Go to start of metadata

How to Fine Tune the Performance of Portal Platform - EP 6.0 NW04/NW 2004s

Reason and Prerequisites

Enhance the performance of processes in the portal environment

1.Note 975942 - deadlock in sql server on table EP_PRT_CACHE
There is a deadlock exception on table EP_PRT_CACHE when trying to insert or delete content from table.
An exception with the following error raised : [SQLServer JDBC Driver][SQLServer]Transaction (Process ID 63) was deadlocked on lock
resources with another process and has been chosen as the deadlock
victim. Rerun the transaction.

Reason and Prerequisites

Deadlock happens because there are many tranactions that try to insert and delete content from table.and during that process  cause pages to lock. For example we have two transaction, the first locks a page then the second tries to lock another page. Then both of them try to get lock of the other transaction's page and a deadlock occurs. at that time the SQL Server identifies the deadlock and realese one of the processes.
Solution
The solution is disable the locking of entire pages. The action need to be taken is:
run the next command on query analyser on the instance database.
on SQL Server 2000-installations you should use
EXEC sp_indexoption 'EP_PRT_CACHE', 'disallowpagelocks', TRUE
on SQL 2005-installations you should use
alter index ALL on EP_PRT_CACHE SET ( ALLOW_PAGE_LOCKS = OFF )

2.Note 952163 - fix of memory leak of StringBuffers SP15,SP16,SP17

a memory leak might occur on load. The leak is rooted in the CoreStringBuffer Object.

Reason and Prerequisites

this fix is to de deployed on SP15,16,17

 3.Note 936612 - Activity Report Service-CPU Consumption Overhead (Fine-Tune)
When using the Activity Report service, the overhead on CPU consumption is up to 10 percent.
You may want to take this into consideration when sizing your system.

Solution

Disable the Activity Report service, as follows:

  • Login with the administrator user.
  • Go to System Administration --> System Configuration --> Service Configuration, and select the service called com.sap.portal.activityreport.core.
  • Change the field "Activate portal activity report" to "false", and save the configuration.
  • Restart the service.

4.Note 862674 - Reduced Performance of SAP NetWeaver Java in Debug mode
When customers launch SAP NetWeaver J2EE applications in "debug" mode on AIX and Linux on Power and they are using an IBM JDK version lower than SR5, there is a reduction in application performance when compared to running in production mode. The performance reduction in particular leads to a greatly increased startup time for the SAP NetWeaver Java applications, making interactive debug impracticalReason and Prerequisites
When running in debug mode, earlier Versions of the IBM JVM required to disable the Just In Time (JIT) Compiler. This is done in order to allow the code being debugged to be dynamically altered, but removes the vast performance enhancements produced by the usage of the JIT compiler. The JIT compiler has been enhanced in the IBM JVM V5.0 release to implement a dynamic recompilation framework, allowing code to be dynamically altered whilst still being compiled with the JIT compiler. This is termed "High Speed Debug" and is available with the IBM JDK 1.4.2 SR5.
SolutionPlease install the latest recommended version of the IBM JDK. For AIX consult note 716927 and for Linux on Power the note 810008.
In addition an updated version of the SAP Startup Framework is required or the SP17 for NW04 or SP08 for NW04s.
5.Note 807000 - Http requests are not fully read after timeout1) When an http servlet tries to read the request input stream, the following error is thrown or logged: com.sap.engine.services.httpserver.exceptions.HttpIOException: Read timeout. The client has disconnected or a synchronization error has occurred. Read<read-bytes>bytes. Expected<expected-bytes>.

<read-bytes>and<expected-bytes>are actual values.
2) Low bandwidth and high latency clients do not receive the full response from http service or receive error http response - 500.
3) During high load some clients do not receive the full response from http service or receive error http response - 500.
4) ICM is setup to forward requests to the Engine and clients randomly fail with the mentioned in 1) "Read timeout" error.
Reason and Prerequisites
When an http client establishes connection to the Engine it should send the http request in certain time.
If the Engine detects that the stream is not being filled in with new data, it notifies the application processing the request by throwing an error and closes the connection to save resources.
The parameter which specifies the time in milliseconds for which the J2EE Engine will wait for an http client to write the next byte from the request into the stream is called
ServletInputStreamTimeout
and has default value of 10000.
This means that by default if a given http client does not send even a single byte into the stream for 10 seconds, the transmission is interrupted and the Engine notifies the reading servlet by raising an HttpIOException.
During high load (including load test scenarios) it is possible that a request is not reaching the Engine for more than 10 seconds which might be caused by overloading of the http client machine or the machine where the Engine is running.

To prevent the raising of the HttpIOException at the cost of increased resource usage you can set the value of the ServletInputStreamTimeout property to a higher value, for example30000(30 seconds) or effectively switch off the timeout by setting1728000000(20 days).
Even though for debugging purposes it might be useful to switch off the timeout, for productive systems unless there is explicit requirement to support very slow clients (dial-up and so on) it is better to set the timeout high enough.

If you have configured ICM to forward requests to a J2EE Engine with SP 12 or earlier, then you need to upgrade the Engine to SP13 to solve the problem. There is a coding error in earlier versions which causes the communication problem. Patch for SP11 is attached to the Note, see the solution section for instructions how to apply it.
Solution
I. If you have configured ICM to forward requests to the J2EE dispatcher and you are running SP12 or earlier, you need to apply the attached patch. The fix for the problem will enter SP13 as a standard release.
  1. Make sure you are running SP11 or SP12 of the Engine
  2. Download the attached httpSP11.zip or httpSP12.zip
  3. Unzip the archive to a temporary directory
  4. Deploy the http.sda from the temporary directory as per Note 656711. Make sure you select the option "Update deployed SDAs/SCAs that have any version" from teh Deployment configuration after selecting the sda in the SDM filechooser dialog.
  5. The engine will be restarted as part of the deployment
  6. If you are still having the problem, then implement section II.

II. The request bytes are reaching the Engine too slowly
  1. Start the configtool in <J2EE>/configtool directory
  2. Browse the tree in the left pane
           cluster-data -> Global server configuration -> services -> http
  3. Press the ServletInputStreamTimeout key in the keylist on the right

  4. Change the value of the "Value" field at the bottom of the right paneto the preferred one (in milliseconds).
           -1 means there is no timeout - that is unless the full request comes into a single chunk, an error will be thrown
           30000 means the Engine would wait for 30 seconds for any byte to be entered in the stream.
           1728000000 means the Engine would wait for 20 days for any byte to be entered in the stream
  5. Press the "Set" button in the top-right corner
  6. Select from the menu File -> Apply and confirm all popups.
  7. Restart the Engine for changes to take effect

  • No labels