Quote:
Originally Posted by sknmail@rediffmail.com  Hi Ian,
Good to know about the production migration from 5.0 to 5.5. I would interested in knowing if you have performed any volume testing on migrated 5.5 (probably Test or Dev environment) for performing bulkplan in comparison to the performance you had in 5.0 environment. Can you compare directly the performance we had on 5.0 to 5.5 after migration.
Also I would like to know what was the weblogic (I hope your app is weblogic and not wepshere or OAS) memory configured in weblogic.conf and for tomcat in tomcat.conf in 5.0 and now in 5.5 setup after migration.
In our case a bulk plan of 25 Orders is taking around 5-6 min on an average, while 77 bulkplans of 25 orders each took around 4 hours to plan. We have the weblogic and tomcat memory configured to 1536 and 1500 respectively. We have App having 4 CPUs around 8G RAM and DB 2 CPUs and 8G RAM. Do you know any planning parameter or properties which can eat up the planning performance after migration which can be turned off if its related to new features 5.5? I understand there are many things needs to be considered on the configuration on OTM and setup when we decided on performance.
Appreciate your information.
Thanks and Regards,
Suresh |
Hi Suresh,
Sorry for this late reply. But yes we did extensive performance and load testing prior to migration to 5.5. We did a direct comparision because we were able to re-create the database and reload the orders again each time. This provided us with a reference environment to ensure that we had no performance issues.
However, during go-live, even after *extensive* performance testing we still hit performance issues. Interestingly the issue was not on the app or web. Rather it was the Oracle DB.
We realised that any DB migration especially one with a large change such as 9i to 10g, you cannot guarantee the same performance.
Honestly, I don't know whats going on inside the Oracle DB but it did not take us long to realise that after the production migration, the bottleneck was the DB as we had performance monitoring on both the app, web and DB. The Oracle was maxing out all our CPU (we have 4 CPU, IBM pSeries 1.6 GHZ Power5, 8 GB RAM)
We ended up having to spend about 1 week re-tuning the Oracle DB parameters as well as our queries.
The important thing is that you should be runninig the gather_table_stats.sql scripts provieded by Oracle (in the glog/oracle/script8 directory) at least once weekly. With the updated stats over a few weeks, performance improved alot.
I know you suspect that it is the app server but I think the app server being *static* code, the only variant here will be the DB. Hence, my bet is on the DB.
What are your thoughts? Have you had success yet?
Thanks and Best Regards,
Ian