The iterative performance-tuning process

The iterative performance-tuning process is a set of guidelines that will help improve application performance drastically. These guidelines can be applied in iterations until the desired output is achieved. These guidelines can also be applied to a variety of web applications, regardless of the technology used to build the application.

The first and most important part of any application is the rendering of static content. The delivery of static content is one of the most common performance bottlenecks. The static content includes images, logos, browser executable scripts, cascaded style sheets, and themes. As this content remains the same all the time, it is unnecessary to serve this content dynamically. Instead, the web server, such as Apache, should be configured to have a long browser cache time while serving static resources to the response. This improvement in static content delivery can significantly improve the application's overall performance. The web server must also be configured to compress static resources. Web accelerators can be used for caching a web resource. For content-driven public portals, it is highly recommended to cache whole pages through the web accelerator. Varnish is an open source web accelerator tool.

Server resource monitoring must be included as part of iterative performance analysis. The reason is that as the application grows, it starts occupying more resources at a particular instance in time. The higher demand for server resources, such as CPU, memory, and disk I/O, can cause it to exceed the operating system limits and become prone to failure. The monitoring systems must be set up in order to observe resource utilization. Resource monitoring usually includes:

  • Web servers
  • Application servers
  • Processes—Maximum versus actual
  • Threads—Maximum versus actual
  • Memory usage
  • CPU utilization
  • Heap memory as a separate measurement
  • Disk I/O operations
  • Database connections—Maximum versus busy
  • JVM garbage collection
  • Database slow queries
  • Cache
  • Cache hits—Number of times the result is found from the cache
  • Cache misses—Number of times the result is not found from the cache

In order to monitor the resources, the following tools can be used:

  • jconsole and jvisualvm come bundled with the standard Java Development Kit (JDK). Using these tools, we can monitor JVM, garbage collection execution, cache statistics, threads, CPU usage, memory usage, and database-connection pooling statistics.
  • mpstat and vmstat are available on Linux-based operating systems. Both of these are command-line tools and are used for collecting and reporting processor-related statistics.
  • ifstat and iostat are useful for monitoring system input/output operations.

There might be a question on why we should do this iterative performance tuning process while we follow best practices. The goals of the iterative performance tuning process are as follows:

  • Identify bottlenecks in the system's performance at various levels
  • Improve the performance of the portal as per the expectations
  • Find the solution and approach
  • Put the solution workflow in place
  • Understand the performance pain areas of the system
  • Define the performance strategy for the application
  • Identify the performance measurement tool based on the technologies
  • Understand application key user scenarios
  • Document key scenarios
  • Prepare sufficient data to generate considerable distributed load on all flavors in a single execution
  • Customize and combine load testing scripts to prepare a performance test suite that can be used for execution on any single flavor or on all flavors at a time
  • Execute performance scripts with different scenarios and load combinations to identify bottlenecks using response times

The iterative performance tuning process is followed at all stages of the application development life cycle. The following table demonstrates the items being reviewed with input and output expectations:

Review item Input Output

Architecture

  • High availability
  • Scalability
  • Caching
  • Integration
  • Network
  • Search Engine
  • Database
System architecture diagram Recommendations on best practices

User interface

  • Frontend code
  • Existing technology selection criteria
  • Review of the code
  • Recommendations for the change

Hardware configuration

  • Web server details
  • App server details
  • Database details
  • Server type (Virtual or Physical)
  • Number of CPU
  • Hard disk space
  • Memory configuration
Changes recommended in hardware configuration

Software configuration

  • Framework configuration
  • Dependent modules/integrations configuration, if any
Recommendations on configuration change

Application server configuration

  • App server configuration files
Recommendations on configuration change

Web server configuration

  • Web server configuration files
  • Cache control settings
  • Static resource-handling settings
Recommendations on configuration change

Deployment architecture

  • Deployment diagram
  • Software installation details
  • Configuration details

Recommendation on deployment architecture changes

Code and database

  • Code review
  • DB design review
  • Code duplication
  • Modularization of code
  • Any third-party libraries/APIs
  • Coding standard implemented
  • Loops and conditions
  • Data normalization
  • Indexing
  • Long-running queries
  • Relations between tables
  • Code review results
  • Recommendations for improvement
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset