Conceptual models of enterprise applications as instrument of performance analysis
1 like682 views
The article presents conceptual models for enterprise applications to aid in performance analysis by simplifying complex interactions between users, resources, and transactions. It emphasizes the importance of understanding both active and passive resources to identify bottlenecks and optimize application performance, particularly in virtualized environments. Overall, the models serve as tools to streamline performance assessments and offer insights into transaction delays and resource utilization.
![To identify where the bottlenecks can potentially take place, we have to monitor not only active resources, but also the passive resources. Among latter there are physical ones (memory and disk space), as well as the logical programmatic objects (software threads, connection pools, locks, semaphores, etc.). Monitoring passive programmatic resources requires knowledge of application architecture and software internal logistics.
The model on Figure 1 reveals that the bottlenecks in our application might happen when there are insufficient CPU and I/O capacities in Web, Application, and Database servers, as well as when the servers have limited memory, application spawns insufficient software threads, or connection pools are poorly tuned. Indeed, low network throughput also can cause the bottlenecks.
Performance ramifications of sharing time and resources in virtualized environments
The conceptual models of virtualized deployment feature the time slice constructs as well as the resources shared among VMs hosted on the same physical host.
The time slice constructs point to the very important fact that, in order for a VM to process transactions, it has to receive from the host’s hypervisor particular time interval to get an access to host’s physical hardware. The time slice allocation algorithms vary among virtual platform from different vendors. But the commonality among all algorithms is that a time slice gets allocated to a VM only when a demand from VM for a specific shared resource is met by resource availability. If that is not the case, than VM will wait and will not process transaction.
One significant implication of a host’s hardware time sharing is a flawed timekeeping by VMs. A detailed discussion can be found in [1, 2]; here we just point at its fundamental reason: in a virtual environment hypervisor treats guest VM as a process that can be stopped and resumed at any time. When guest VM is stopped, it cannot accept and count time interrupts from a hardware clock. That means guest VM misses time intervals which makes reported by VM time-dependent performance metric not representative. That affects the most popular performance counter groups:
- The counters reporting utilization of system resources during some time interval (for example, percent of total CPU utilizations, percent of CPU utilization by particular process, percent of physical disk utilization).
- Resource throughput measured in a number of operations executed by a resource during particular time interval (for example, network throughput measured in bytes/second, number of I/O Reads/second).
Taking into consideration this fact, what are the right performance counters to monitor in virtualized environments? To find it out let’s refer to our conceptual model on Figure 2. Each resource depicted on the model has a waiting queue; acquiring a time slice also requires VM to wait in a queue. The queues are the major phenomenon defining system performance, because waiting time in the queues adds up to the time a transaction is processed by system resources. A queue is an indicator of imbalance](https://image.slidesharecdn.com/conceptualmodelsofenterpriseapplicationsasinstrumentofperformanceanalysis-141202162634-conversion-gate01/85/Conceptual-models-of-enterprise-applications-as-instrument-of-performance-analysis-7-320.jpg)
![Conclusions
The conceptual models expose application fundamentals distilled of innumerable application particulars that conceal the roots of performance issues. The value of conceptual models for performance analysis is confirmed by the following judgments that are based on examination of the article’s models:
- A transaction delay can be caused by two circumstances – a shortage of an active resource capacity and a limited access to an active resource because of the shortage of passive resources.
- A shortage of the passive resources causes underutilization of the active resources.
- To identify where the bottlenecks can take place, we have to monitor not only active resources, but also passive resources.
- In virtual environment a time slice gets allocated to a VM only when a demand from VM for a specific shared resource is met by the resource availability. If that is not the case, than VM will wait and will not process transaction.
- Reported by VM time-dependent performance metric is not representative since a guest VM misses time interval counts.
- Because instantaneous counts of the queue lengths do not depend on implementation of a system timekeeping mechanism, monitoring resource queues delivers representative performance metrics for virtualized environments.
Application queuing models
The application conceptual models are indispensable instruments streamlining performance analysis. The conceptual models point to the facts that performance degradation happens when a resource does not have sufficient capacity or access to the resource is limited. In both cases processing of a transaction will be delayed as transaction will be placed into a waiting queue.
Queuing is a major phenomenon defining application performance, but conceptual models cannot quantitatively asses its impact. If we want the numerical estimates of architecture that delivers application performance according to a service level agreement, we have to build upon application conceptual models their queuing models. The book [3] can be a guide in that journey.
1. VMware document: “Timekeeping in VMware Virtual Machines” http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
2. Bernd Harzog. “White Paper: Application Performance Management for Virtualized and Cloud based Environments” http://www.virtualizationpractice.com/blog/wp-content/plugins/downloads- manager/upload/APM_for_Virtualized_and_Cloud_Hosted_Applications.pdf](https://image.slidesharecdn.com/conceptualmodelsofenterpriseapplicationsasinstrumentofperformanceanalysis-141202162634-conversion-gate01/85/Conceptual-models-of-enterprise-applications-as-instrument-of-performance-analysis-9-320.jpg)
Conceptual models of enterprise applications as instrument of performance analysis
- 1. Conceptual Models of Enterprise Applications as Instrument of Performance Analysis Leonid Grinshpan, PhD The article introduces enterprise applications conceptual models that uncover performance related fundamentals distilled of innumerable application particulars concealing the roots of performance issues. The value of conceptual models for performance analysis is demonstrated on two examples of virtualized and non-virtualized applications conceptual models. In the course of performance analysis of enterprise applications the biggest challenge to overcome is their tremendous complexity. Today’s distributed applications are comprised of the tanglewoods of physical and logical objects interacting in a very intricate manner. The applications implement multiple rules, algorithms, and protocols while serving communities of concurrent users generating fluctuating workloads. That makes application performance analysis extremely cumbersome and time consuming, particularly taking into account that each enterprise application features hundreds of tuning parameters on system and application levels. System level tuning parameters define the management policies of the operating systems. Microsoft offers 112 pages document “Performance Tuning Guidelines for Windows Server 2008 R2” (http://tinyurl.com/qx4v4gy). AIX operating system tuning guide by IBM is even fattier – it has 744 pages (http://tinyurl.com/o3b66o8). Application tuning parameters control allocation of system resources as well as configurations of application internal logical objects like software threads, connection pools, etc. Application vendors publish various tuning documents to help optimize their products. A few examples are: “Oracle® Fusion Middleware Performance and Tuning Guide” (http://tinyurl.com/kurmd9p), “Oracle® JRockit Performance Tuning Guide” (http://tinyurl.com/mggv55j), “Oracle® Fusion Middleware Performance and Tuning for Oracle WebLogic Server” (http://tinyurl.com/panje7g). All publications expose broad assortments of tuning variables, but do not provide any methodological guidance on efficient and targeted execution of performance tuning activities. Is it possible to perceive an application in a way that scales down its complexity (similar to taking an aerial view of the Earth)? In other words, can we conceptualize an application to abstract from numerous details and concentrate only on its objects and their relationships that reveal performance related cause-effect connections?
- 2. This article provides a positive answer by advocating enterprise application conceptual modeling as an instrument of application performance analysis. Application conceptual model exposes the relations between demand for services generated by transactional workload and supply of system resources that intended to satisfy such a demand. By devising a conceptual model we mentally leap into specific perspective on application; that perspective highlights system resources, their capacities, as well as demand for system resources from transactional workload. The representations of the conceptual models can differ (charts, tables, matrixes, text descriptions, pictures), but they all include the constructs describe in the next paragraph. Conceptual model constructs We need the following constructs to build the conceptual models that enable application performance analysis 1. Transactions – characterize user requests for application services. If we visualize a transaction as a physical object (for example, a car), we can create in our mind an image of a car-transaction visiting different system servers and spending some time in each one while being processed. The transaction examples are: - Login - Financial Report - Activity Report - Data transformation - Business rule execution 2. Resources – each system hardware component (servers, appliances, networking equipment) allocates its resources to transaction processing. In general, each component has the following assets to be allocated: Active resources: - CPU time (data processing) - I/O time (data transfer) - Network time (data transfer) Passive resources: - Software connections (for example, Web server connections, database connections) - Software threads - Storage space - Memory space - Software locks Active resources implement actual transaction processing and data transfer. Passive resources provide access to active resources. A consumption of an active resource by a single transaction
- 3. is measured by the time interval it was serving a transaction. A metric for a passive resource usage by a single transaction depends on a passive resource type: for software connections and threads it is a number of connections and threads; for memory and storage it is a size of allocated memory. A transaction waits for a resource when other transactions consume all resource capacity. 3. Physical nodes - symbolize physical servers, appliances, and networks. One physical node consists of active and passive resources of one physical server. Each resource has a queue where transactions are waiting while that resource is unavailable. Physical node 4. Virtual nodes - represent virtual machines (VM). One virtual node consists of one VM passive resources and a block indicating a waiting period for a time slice to be allocated to VM by a host’s hypervisor. VM is not running when it is waiting for a time slice. Virtual node 5. Nodes with shared hardware resources – a depiction of a physical host shared active and passive resources: Node with shared active resources
- 4. 6. Transaction-resource matrix (TR matrix) - defines active and passive resources each transaction receives the services from while being processed by application. As an example, in a matrix below a character “X” identifies the resources of three-tiered application consumed by each transaction. Active and passive resources for each hardware component Transactions Web server Application server Database server Network Load balancing appliance CPU Connections CPU Threads Memory CPU Connections I/O system Networking hardware CPU Login X X X X Financial Report X X X X X X X X X X Activity Report X X X X X X X X X X Data transformation X X X X X X Business rule execution X X X X X X Transaction-resource matrix (TR matrix) 7. Users – the source of transactional workload. An application has to have sufficient resource capacity to process transactional workload according to required service level. We can picture an interaction between users and application as below (the cars are transactions metaphors): User interaction with application The user-generated transactions are processed by the application; after completion the results are delivered back to the user. Between two subsequent transactions generated by the same user there is a time interval (called a “user think time”) that defines an intensity of transactional flow.
- 5. Conceptual models of non-virtualized and virtualized deployments Using described constructs, we can model non-virtualized three-tiered application as shown on Figure 1. The application consists of Web, Application, and Database servers; each one is hosted on dedicated physical hardware. Figure 1. Conceptual model of multi-tiered non-virtualized application A transaction starts its journey when a user clicks on a menu item or a link that implicitly initiates a transaction. In a model it means that a transaction leaves a block “users”. After that it gets processed in the nodes “WEB server”, “Application server”, “Database server”. Each transaction will request passive and active resources as described in TR matrix. If any of the needed resources is not available, a transaction will wait in the queues. At the end of its journey a transaction comes back to a user. The total time a transaction has spent in all nodes is a transaction response time. The model makes obvious that this time has two components: a processing time by the active resources and a waiting time for the passive and active resources. A conceptual model of the same three-tiered virtualized application deployed on one physical host can be seen on Figure 2.
- 6. Figure 2. Conceptual model of multi-tiered virtualized application Two major differences between non-virtualized and virtualized deployments our conceptual models highlight immediately: - A virtualized set up has resources shared among a number of VMs. - Each VM can use its own passive and host’s shared resources only when hypervisor allocates a time slice to VM. Those particulars of virtual deployment have profound performance implications we discuss in the next paragraph. Analyzing application performance using conceptual models Let’s consider what can cause a delay in a transaction processing in non-virtualized application deployment. As a conceptual model on Figure 1 suggests, a transaction delay can be cause by two circumstances – a shortage of an active resource capacity and a limited access to an active resource because of the shortage of passive resources. For example, in order to process a transaction in a server’s CPUs, an application has to request and to receive a particular memory space. But what will happen if a memory is not available? Obviously, a transaction will wait in a queue. This means that a transaction processing is delayed as a result of a limited access to CPUs even if they are not fully utilized. In general, a shortage of the passive resources causes underutilization of the active resources.
- 7. To identify where the bottlenecks can potentially take place, we have to monitor not only active resources, but also the passive resources. Among latter there are physical ones (memory and disk space), as well as the logical programmatic objects (software threads, connection pools, locks, semaphores, etc.). Monitoring passive programmatic resources requires knowledge of application architecture and software internal logistics. The model on Figure 1 reveals that the bottlenecks in our application might happen when there are insufficient CPU and I/O capacities in Web, Application, and Database servers, as well as when the servers have limited memory, application spawns insufficient software threads, or connection pools are poorly tuned. Indeed, low network throughput also can cause the bottlenecks. Performance ramifications of sharing time and resources in virtualized environments The conceptual models of virtualized deployment feature the time slice constructs as well as the resources shared among VMs hosted on the same physical host. The time slice constructs point to the very important fact that, in order for a VM to process transactions, it has to receive from the host’s hypervisor particular time interval to get an access to host’s physical hardware. The time slice allocation algorithms vary among virtual platform from different vendors. But the commonality among all algorithms is that a time slice gets allocated to a VM only when a demand from VM for a specific shared resource is met by resource availability. If that is not the case, than VM will wait and will not process transaction. One significant implication of a host’s hardware time sharing is a flawed timekeeping by VMs. A detailed discussion can be found in [1, 2]; here we just point at its fundamental reason: in a virtual environment hypervisor treats guest VM as a process that can be stopped and resumed at any time. When guest VM is stopped, it cannot accept and count time interrupts from a hardware clock. That means guest VM misses time intervals which makes reported by VM time-dependent performance metric not representative. That affects the most popular performance counter groups: - The counters reporting utilization of system resources during some time interval (for example, percent of total CPU utilizations, percent of CPU utilization by particular process, percent of physical disk utilization). - Resource throughput measured in a number of operations executed by a resource during particular time interval (for example, network throughput measured in bytes/second, number of I/O Reads/second). Taking into consideration this fact, what are the right performance counters to monitor in virtualized environments? To find it out let’s refer to our conceptual model on Figure 2. Each resource depicted on the model has a waiting queue; acquiring a time slice also requires VM to wait in a queue. The queues are the major phenomenon defining system performance, because waiting time in the queues adds up to the time a transaction is processed by system resources. A queue is an indicator of imbalance
- 8. between demand generated by fluctuating user’s workload and availability of system’s resources to satisfy the demand. As such, while analyzing a performance bottleneck, it is necessary to find out where in a system the queues are building up and exceeding the acceptable thresholds. Because instantaneous counts of the queue lengths do not depend on implementation of a system timekeeping mechanism, monitoring resource queues delivers representative performance metrics for virtualized environments. A performance impact of resource sharing depends on the specifics of application and VMs deployments on a physical server. A physical server can host single application installed on a few VMs as shown on Figure 2. A transaction that has to be processed on all tiers (Web, Application, and Database), will travel among different VMs. A transaction transition between VMs increases transaction response time because of delays in time slice allocations to each VM. In such a deployment the application software components residing on different VMs compete for shared host resources. Another deployment schema features a few applications each one fully installed on a dedicated VM (Figure 3). Figure 3. Conceptual model of multiple applications deployment on one physical host The conceptual model implies that, in this case, a full cycle of a transaction processing can occur during single time slice minimizing transaction waits for time slices. Still there is a competition for shared resources; however, in this case it is among different applications, but not the software components of the same application.
- 9. Conclusions The conceptual models expose application fundamentals distilled of innumerable application particulars that conceal the roots of performance issues. The value of conceptual models for performance analysis is confirmed by the following judgments that are based on examination of the article’s models: - A transaction delay can be caused by two circumstances – a shortage of an active resource capacity and a limited access to an active resource because of the shortage of passive resources. - A shortage of the passive resources causes underutilization of the active resources. - To identify where the bottlenecks can take place, we have to monitor not only active resources, but also passive resources. - In virtual environment a time slice gets allocated to a VM only when a demand from VM for a specific shared resource is met by the resource availability. If that is not the case, than VM will wait and will not process transaction. - Reported by VM time-dependent performance metric is not representative since a guest VM misses time interval counts. - Because instantaneous counts of the queue lengths do not depend on implementation of a system timekeeping mechanism, monitoring resource queues delivers representative performance metrics for virtualized environments. Application queuing models The application conceptual models are indispensable instruments streamlining performance analysis. The conceptual models point to the facts that performance degradation happens when a resource does not have sufficient capacity or access to the resource is limited. In both cases processing of a transaction will be delayed as transaction will be placed into a waiting queue. Queuing is a major phenomenon defining application performance, but conceptual models cannot quantitatively asses its impact. If we want the numerical estimates of architecture that delivers application performance according to a service level agreement, we have to build upon application conceptual models their queuing models. The book [3] can be a guide in that journey. 1. VMware document: “Timekeeping in VMware Virtual Machines” http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf 2. Bernd Harzog. “White Paper: Application Performance Management for Virtualized and Cloud based Environments” http://www.virtualizationpractice.com/blog/wp-content/plugins/downloads- manager/upload/APM_for_Virtualized_and_Cloud_Hosted_Applications.pdf
- 10. 3. Leonid Grinshpan. Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue, Wiley-IEEE Press; 1 edition, 2012 (http://tinyurl.com/7hbalv5)