Websphere Commerce Performance and Maintenance Services

Performance Tuning for Websphere Commerce Production Environment.

All the performance issues of production environment will be solved as top priority; dedicated WebSphere Commerce resource will be assigned to the project for up to 80 hrs

Experienced WebSphere Commerce resources:

Our WebSphere resources are IBM WebSphere Commerce certified. We have more than 10 years experience in IBM WebSphere Commerce. Dedicated WebSphere Commerce resource will be allocated to the project. In addition we have separate team of Performance Testers, Monitoring tools, and Quality Assurance. Separate shifts operate during daytime and night and will provide 24/7 support to your environment

Performance tuning of Websphere Commerce covers following areas:

• JVM™ tuning - Minimum and maximum heap memory allocations, garbage collection, class loader options, parameter passing options, and so forth.
• Queue settings - WebSphere has many queues for buffering waiting requests, such as Servlets container thread pools, EJB™ pools, JDBC™ connection pools, RMI/IIOP buffer pools, prepared statement caches, and so forth.
• Network settings - For example time-outs, keep-alive intervals, and connection sizing.
• Database tuning.
• JMS message tuning.
• DynaCache configuration, analysis, and tuning.
• Operating system tuning.
• CPU, hard disk, and general resource monitoring.
• Thread dumps analysis for troubleshooting thread contention problems.
• Memory usage/dump analysis for detecting leaks.
• Clustering
• Performance test tool scripting and operation

Performance Improvement using DynaCache

Caching can be used to maximize the performance and minimize the workload Cached items fall into two groups:

• Static data, such as HTML, images, and Java™ Script files
• Dynamically created data that contains the output results from the runtime program execution of code components, such as servlets and JSPs

Characteristically, the header, menu, and footer JSPs rarely change in most applications and therefore are ideal for caching. After implementing the cache you can see the most of the request that are loaded from the cache without involving the application server and database server.

Cache hit. The effectiveness of a cache is judged by its hit rate. You can see below in snapshot

Performance Methodologies we follow:

• Identifying the workload
• Data monitoring and analysis
• Top-down tuning approach
• Closed-loop cycle

Performance testing and analysis report

Load test will be performed using IBM Rational Performance Tester which involves following three steps:

• Build Scripts.
• Schedule Workload.
• Execute and Analyze.

Build Scripts

• Tests are created by capturing user interactions with a server.
• Test creation results in a tree view of the sequential web pages accessed.
• It eliminates the need of programming.
• Varying input data across users.
• Correlating system response data.

Scheduled Workload

• Schedule defines order and sequencing of script execution.
• Schedule defines physical Windows or Linux based agents to be used to generate load
• Flexibility to accurately model complex workloads.
• Dynamically add load during the run to find breakpoints.

Load test will be performed on daily basis before the start of business hours