WCS Quick Performance Tuning Cheat sheet
Performance tuning of an application is best achieved and measured through an iterative approach, Although not a comprehensive list the performance gains from these steps should be worth it, there isn't any silver bullet here, every application is different and hence tuning settings will differ based on your application / infrastructure / architecture and performance workload profile.
Refer my previous blog on SQL tuning to read more on this topic.
http://techhari.blogspot.com/2011/01/websphere-commerce-developer-sql.html
While using the JDBC OCI driver with RAC, the database can be specified with an Oracle Net keyword-value pair. The Oracle Net keyword-value pair substitutes for the tnsnames entry.
E.g. jdbc:oracle:oci:@MyHostString
This configuration requires Oracle client installed on WCS JVM and a TNS entry for MyHostString
Thick drivers are written in native language C and JNI code, they can potentially reduce the amount of GC, but they add an overhead of JNI calls.
Recommendation is to go with thick driver for RAC setup.
There is a general misconception that more Heap means applications will perform better, WRONG... as a best practice never cross max JVM heap size of 1.5 GB, more heap means lesser GC cycles, but you might spend more time in every GC cycle, every GC cycle will pause JVM for a while and hence it will queue up the requests until GC completes, a longer GC cycle under high load could actually overwhelm the JVM and be a perfect recipe for a JVM crash.
On a 64 bit machine you could potentially set heap size higher than 2 GB in case you are using JVM for dynacache.
Every thread means consumption of additional CPU and Heap, you need to size this based on your server configuration, thumb rule is to have 3x times of the cores available on the box, so on a 8 core box we could have close to 25 threads
It is always good practice to leave it at default of 25/25 on a 8 core box and then reduce it if it consumes more CPU.
This should normally be equivalent to Thread pool size, it is quite rare that you will find all threads occupied and busy concurrently, Try to keep this value slightly higher than that thread pool size.
DataSource Conn Pool Size = (# Of Webcontainer Threads)
+ (# Of WC Scheduler Threads)
+ 1 (for WC Key Manager)
+ 1 (for WC Auditing)
+ (# of Parallel and Serial MQ listener threads)
+ (# of Non-Webcontainer Threads used by Custom Code).
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/concepts/cpmwas.htm
You can also explore the usage of WAS reserve pool configuration for large application deployments, this feature is available through a feature pack, more information is available here.
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/tasks/tpm_was_reservepool.htm
This is one of the parameters which you would most certainly tune in every production environment, by default these are set at 1024, you can safely set this to 65 K or unlimited for WCS installtion.
IHS supports many different types of algorithm, Here is an Excellent tech note on how to setup plugin configuration, ensure you define "LoadBalanceWeight" as recommended by this technote.
http://www-01.ibm.com/support/docview.wss?uid=swg21219567
To generate a system dump automatically on an OOM you will need to set the following JVM generic argument:-Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError,request=nodumps+exclusive+prepwalk
In order to generate java core dump, system core dump, heap dump and a snap dump at user signal, the dump agents must be configured through JVM options as follows.-Xdump:java+heap+system+snap:events=user
1. Tune Application
Begin with the basics, ensure you do not have any long running queries, you can easily debug WCS SQL using the RAD SQL profiler, make use of Oracle AWR reports to refine SQL, index etc..
Validate logging from application makes use of Apache logging level appropriately, on production you don't want to log details unnecessarily and cause high I/O, this will have impact on CPU and application performance.Refer my previous blog on SQL tuning to read more on this topic.
http://techhari.blogspot.com/2011/01/websphere-commerce-developer-sql.html
2. JDBC Thin vs. Thick Driver
While using the JDBC OCI driver with RAC, the database can be specified with an Oracle Net keyword-value pair. The Oracle Net keyword-value pair substitutes for the tnsnames entry.
E.g. jdbc:oracle:oci:@MyHostString
This configuration requires Oracle client installed on WCS JVM and a TNS entry for MyHostString
Thick drivers are written in native language C and JNI code, they can potentially reduce the amount of GC, but they add an overhead of JNI calls.
Recommendation is to go with thick driver for RAC setup.
3. JVM Heap Size
There is a general misconception that more Heap means applications will perform better, WRONG... as a best practice never cross max JVM heap size of 1.5 GB, more heap means lesser GC cycles, but you might spend more time in every GC cycle, every GC cycle will pause JVM for a while and hence it will queue up the requests until GC completes, a longer GC cycle under high load could actually overwhelm the JVM and be a perfect recipe for a JVM crash.
On a 64 bit machine you could potentially set heap size higher than 2 GB in case you are using JVM for dynacache.
4.Webcontainer thread.
Every thread means consumption of additional CPU and Heap, you need to size this based on your server configuration, thumb rule is to have 3x times of the cores available on the box, so on a 8 core box we could have close to 25 threads
It is always good practice to leave it at default of 25/25 on a 8 core box and then reduce it if it consumes more CPU.
5. Database Connection Pool size
This should normally be equivalent to Thread pool size, it is quite rare that you will find all threads occupied and busy concurrently, Try to keep this value slightly higher than that thread pool size.
DataSource Conn Pool Size = (# Of Webcontainer Threads)
+ (# Of WC Scheduler Threads)
+ 1 (for WC Key Manager)
+ 1 (for WC Auditing)
+ (# of Parallel and Serial MQ listener threads)
+ (# of Non-Webcontainer Threads used by Custom Code).
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/concepts/cpmwas.htm
You can also explore the usage of WAS reserve pool configuration for large application deployments, this feature is available through a feature pack, more information is available here.
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/tasks/tpm_was_reservepool.htm
6. Server ULIMIT
This is one of the parameters which you would most certainly tune in every production environment, by default these are set at 1024, you can safely set this to 65 K or unlimited for WCS installtion.
7. WebServer Load Balancer Configuration
IHS supports many different types of algorithm, Here is an Excellent tech note on how to setup plugin configuration, ensure you define "LoadBalanceWeight" as recommended by this technote.
http://www-01.ibm.com/support/docview.wss?uid=swg21219567
8. Generic JVM arguments
To generate a system dump automatically on an OOM you will need to set the following JVM generic argument:-Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError,request=nodumps+exclusive+prepwalk
In order to generate java core dump, system core dump, heap dump and a snap dump at user signal, the dump agents must be configured through JVM options as follows.-Xdump:java+heap+system+snap:events=user
Further Reading
Garbage collection options used by JVM
WCS WAS Tuning
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/concepts/cpmwas.htm
Native Memory Issues on Linux
Enabling Verbose GC
Webserver plugin settings
Blogger | Freelancer |Operations Manager | Marketing and Sales Manager | Lancer Evo 4 Community.
Indonesian Bloggers Who Become Bloggers Because of Hobby.
Feel free to connect with me on Social Media Instagram @alberandesko
0 Response to "WCS Quick Performance Tuning Cheat sheet"
Post a Comment