Performance benchmarks and tuning

This topic contains information about performance testing, environments, performance and database tuning.

Summary of performance tests  

Performance testing for the Track-It! application was executed by using the JMeter tool. The objective of the performance test was to demonstrate the response time, CPU and memory consumption, and scalability characteristics of the Track-It! application for customers. No blocker issues were observed during the runs.

The following key metrics were captured during benchmark execution:

• Measure response time under different user loads
• Measure memory and CPU utilization
• Determine bottlenecks for the performance improvement
• Review sizing guidelines

Performance testing environments

Deployment for a 24-hour run

The following diagram shows the deployment of the lab environment for a small and large environment:

The following table provides information about the hardware used for the performance test:

Deployment for a 7-day endurance test

The following diagram shows the deployment of the lab split small environment for 7 days [24X7] endurance runs:

The following table provides information about the hardware used for the performance test on a small environment:

Performance test used

The product performance test was executed with JMeter [.jmx] scripts using basic operations, such as create tickets/assignments, update tickets/assignments, add additional note to tickets/assignments, open tickets/assignments, and search and link solutions to tickets/assignments from the technician portal. Also, from the Self Service portal, create ticket, view tickets, and search for solutions actions were performed.

• Create ticket/assignment action from the Technician portal: each technician created tickets/assignments at a frequency of approximately 7 to 8 tickets/assignments in an hour.
• Update or add note to ticket/assignment action from the Technician portal: each technician updated approximately 7 to 8 tickets/assignments in an hour.
• Open or view ticket/assignment action from Technician portal: each technician opened and viewed approximately 7 to 8 tickets/assignments in an hour.
• Search and link solution to ticket/assignments action from Technician portal: each technician searched and linked solutions to approximately 7 to 8 tickets/assignments in an hour.
• Create ticket action from Self Service: each requestor created tickets at a frequency of approximately 8 to 9 tickets in an hour.
• Open or view ticket action from Self Service: each requestor opened and viewed approximately 8 to 9 tickets in an hour.
• Search solutions from Self Service: each requestor searched approximately 8 to 9 solutions in an hour

All the above operations were executed in parallel with individual end users and the initial ramp-up time was maintained.

Example

Assume that the performance run was executed by four technicians and four requestors who were performing the following actions:

• One technician is creating a ticket.
• One technician is updating or adding a ticket note.
• One technician is opening or viewing a ticket.
• In Self Service, two requestors are creating tickets.
• Three requestors are opening or viewing tickets.

User scenarios for 24-hour run

Before starting the 24-hour small environment runs, the following volume data was generated on the server by using SQL scripts:

• Tickets – 5000
• Tickets with linked assignments – 5000

Before starting the 24 hours large environment runs, following volume data was generated on server using SQL scripts:

• Tickets created -10000
• Tickets with linked assignments created – 10000

The following user scenarios were executed as a part of 24-hours performance test:

User scenarios for 7-day endurance test

The following user scenarios were executed as a part of 7 days endurance test:

Performance reports

Performance tuning

Following are the checks for better performance tuning:

• For better performance on Ticket and Assignment forms, the Create, Update, and Open the Details section is disabled by default.
• For better performance on Helpdesk, during loading, keep the default user view with single level queries, such as, My Open tickets. Avoid views with multilevel queries such as, All works and also disable the Preview section.
• For better performance on Dashboard loading, keep minimum required panels with view with single level queries such as My Open tickets and avoid views with multilevel queries such as All works.
• Do not change the default log level of the Track-It! application from the LogConfig utility.

Database tuning

• Ensure no additional loads, such as SQL profiler are running on the SQL server.
• Do not alter the default values of Open Data Base Connectivity (ODBC) or SQL connection settings.
• Run only the required services on the SQL server.
• If the Track-It! application is installed in a split environment, try to keep both servers in the same domain (recommended latency ~1-3 millisecond).