Has anyone experienced performance issues since upgrading from 6.0 to 7.1? We've had complaints about pages loading slower than usual. Am wondering if anyone experienced similiar issues. If so, please share and offer any suggestions if possible.
Hi, if the slowness occures everywhere then I would guess also that the problem is either on database (have you re-build indexes for example) or then something has changed in your application server configuration. We noticed that e.g. SP5 re-wrote the start scripts for the instances and someof our customized settings were lost. Also, have you tried dynamic compression on? I think HP has a white paper about that somewhere.
Thank you all for the feedback. Jussi-Kristian Puustinen, can you please tell me a little bit more about dynamic compression? Is it a parameter or setting that you can enable within the applicatioin? I can't seem to find the white paper you are referring to.
I just copy the extract from our server.conf file where we specify the server processes:
---cut--- # # 1st Cluster Node: Base 8100 # Purpose: Background services only # com.kintana.core.server.KINTANA_SERVER_NAME=Test_svc com.kintana.core.server.SERVER_NAME=server01.ourdomain.com com.kintana.core.server.BASE_URL=https://front-end-apache.ourdomain.com/itg com.kintana.core.server.HTTP_PORT=8100 com.kintana.core.server.EXTERNAL_WEB_PORT=8103 com.kintana.core.server.RMI_URL=rmi://server01.ourdomain.com:8102/Kintana Server
# # 2nd Cluster Node: Base 8090 # Purpose: End-Users only # @node com.kintana.core.server.KINTANA_SERVER_NAME=Test1 com.kintana.core.server.SERVER_NAME=server01.ourdomain.com com.kintana.core.server.BASE_URL=https://front-end-apache.ourdomain.com/itg com.kintana.core.server.HTTP_PORT=8090 com.kintana.core.server.EXTERNAL_WEB_PORT=8093 com.kintana.core.server.RMI_URL=rmi://server01.ourdomain.com:8092/Kintana Server com.kintana.core.server.SERVICES_ENABLED=FALSE
# # 3rd Cluster Node: Base 8080 # Purpose: End-Users only # @node com.kintana.core.server.KINTANA_SERVER_NAME=Test com.kintana.core.server.SERVER_NAME=server01.ourdomain.com com.kintana.core.server.BASE_URL=https://front-end-apache.ourdomain.com/itg com.kintana.core.server.HTTP_PORT=8080 com.kintana.core.server.EXTERNAL_WEB_PORT=8083 com.kintana.core.server.RMI_URL=rmi://server01.ourdomain.com:8082/Kintana Server com.kintana.core.server.SERVICES_ENABLED=FALSE ---cut---
The "trick" is the SERVICES_ENABLED parameter which was introduced with 7.1 SP5. For performance I would recommend to run at least SP5; this was the first SP that made our system stable. Today we had to restart one of our services for the first time after one month uptime. With SP2, we restarted every day...
For the cluster setup, follow the guidelines in the SysAdmin Guide.
The process running the background services (in our example "Test_svc") should not be configured in your worker.properties file - this way you never have end users on your background services engine.
If you need more (specific) info, please write an email to ppmforum(at)tn-consulting.com.
One more word on compression: This was a standard internal feature with 6.0. In 7.1, you have to do compression on your external web server. It really is quite an important setting - especially if you use PPM over WAN connections.
We use mod_deflate with Apache 2.0.x with good results (dashboard pages compress down to 10%).
Thanks. We only run PPM internally on the LAN so do you think the dynamic compression is still necessary? Also, there are no more than 200 people concurrently in the application in a given day. We have a clustered application and web server on two separate servers so the load is distributed evenly between the two nodes. I am considering scheduling a maintenance window once a month just to bounce the application and database. For our volume of users, this may suffice.
For performance related issues, yo should also check that the cache is working for you. We had some problems with it some time ago. It is very important for a good performance.
Thorsten, have you experienced better performance with the implementation of background services or was the clustering key for you? This really could be something we should look at in our implementation.
separating the background services brought a more stable performance for the end users. We closely watch Java Memory consumption for all cluster processes. We derived from that info, that the process with the background services showed heavy usage (with peaks and garbage collection) while the end-user processes were running calmly.
For us, separating the background processes was key to provide end-users with a steady good performance (I don't just say it - we continuously measure key use cases with Silkvision over a few months now).
Thanks for the info. We've been measuring our environment for quite some time now and everything is working ok now but the environment is different from yours. I'm sure we'll try this out measure the effects on current overall performance and also how it affects our loadtest results also. The peaks and garbage collection on the background services make sense since they propably have the heaviest calculations etc. going there.
Thanks for the info. We've been measuring our environment for quite some time now and everything is working ok now but the environment is different from yours. I'm sure we'll try this out and measure the effects on current overall performance and also how it affects our loadtest results also. The peaks and garbage collection on the background services make sense since they propably have the heaviest calculations etc. going there.