Connection issues while executing test with 100 portal users
I have an HCM system ECC 6 with NW 7 - SP 14 for ABAP and Java and Enhancement Package 2. I am in the process of implementing ESS on this system using the web dynpro for java iviews. My scenarios are all set and work fine.
I have a central instance and two dialog instances on different hosts - all Solaris 10 - and my DB is DB2.
My 2 dialog instances each have 2 Java server processes and 6 dialog work processes and all are configured to use 2GB roll area and 2 GB heap - according to SAP notes. I have setup a web dispatcher to do load balancing between the central- and the 2 dialog instance - in fact the web dispatcher is configured to connect users ONLY to the two dialog instances so the central instance with database is freed of the http load.
Overall system performance is good and the errors only happen in case 100 people access my system simultaneously.
My problem is, whenever I schedule a test with say 100 people I receive errors in my portal. The users see al sort of errors but they all conclude to connections beeing turned down or stating that no backend connection was possible. In my defaulttrace I can see errors like this:
Exception com.sap.engine.services.connector.exceptions.BaseResourceException: Cannot get connection for 60 seconds. Possible reasons: 1) Connections are cached within SystemThread (can be any server service or any code invoked within SystemThread in the SAP J2EE Engine), 2) The pool size of adapter "SAPFactory" is not enough according to the current load of the system or 3) The specified time to wait for connection is not enough according to the pool size and current load of the system. In case 1) the solution is to check for cached connections using the Connector Service list-conns command, in case 2) to increase the size of the pool and in case 3) to increase the time to wait for connection property. In case of application thread, there is an automatic mechanism which detects unclosed connections and unfinished transactions.
or this one:
The Timelimit for this iView was exceedet and no data from backend was received...
I tried to change nearly all parameter that I know of have something to do with number of connections to solve this issue:
> rdisp/appc_ca_blk_no = 2000
> rdisp/wp_ca_blk_no = 2000
> rdisp/max_arq and rdisp/max_comm_entries = 2000
> gw/max_conn = 2000
> gw/max_sys = 2000
I increased the number of JCo connections in the system connection from 100 to 1000
I increased the maximum number of JDBC connections from 50 to 100
I increased the value of icm/HTTP/j2ee_0 in system profile from 500 connections to 1000
Finally I increased the number of concurrent JMS Connections (with Visual Admin) from 100 to 200.
But now I receive a new error from the portal stating that the iView could not be displayed because the backend did not respond
I am stuck - can anyone point me to a direction which parameter to check or where to look for more info?
Thanks in advance,
Michael Hofmänner replied
Congrats to this post, finally somebody takes some time to outline his situation. I am assuming that the backend is the ERP Abap part of the installation. I have two things as a start:
- If the timeouts occur after 60 seconds, then have a look at icm/keep_alive_timeout, the default is 60 seconds. I remember a case where setting it to 900 seconds solved a similar issue (make sure you don't override it in the icm/server_port_X settings)
- Even if the increase of the timeout above does help, the users might/should not have to wait over 60s to get a response, so you will need to investigate the situation in the backend system. Please have a look a the the work process occupation (6 processes might not be enough) and the cpu consumption. Do not forget to check the load on the CI/DB server as well. You should monitor the processing time as well, it might be necessary to tune the application in the end.
If you think you don't lack ressources on the CI-DB server, you can also try to add the CI (only for test purposes) to the web dispatcher logon group, and verify if this helps or not.
To help you further we will need more information on: what are the users doing (iview / transaction), where the bottleneck seems to be (cpu / io / database / dialog instance).