Maintaining software is hard and therefore expensive; and IT departments are often under-funded. However, if they are in a Just do it mode, then non-functional requirements are easy to be forgotten. The consequences of leaving these NFRs lead directly to the aforementioned maintenance problems and increased technical debt.
NFRs are necessary to finishing the IT applications journey. While one might consider two or three important NFRs (such as performance and security), one will probably not cover the others extensively, or you might miss out on them all together. And if one does allocate time to deal with them, when the schedule slips, the NFRs may be the first thing to get dropped. So, whether you plan for NFRs or not, chances are high you won't cover them 100%. One should try to avoid adding technical debt and maintenance nightmares to the application portfolio.
Performance is defined as the responsiveness of the application to perform specific tasks in a given span of time. It is scored in terms of throughput or latency. Throughput is the number of events in a given span of time while Latency is the time it takes to respond to an incident. An application's performance directly impacts software scalability. Enhancing application's performance often enhances scalability by virtue of reducing shared resource contention. Following is a list of design principles:
- Load balancing is a key technique used to spread the load evenly between various nodes. Load balancing or distribution through the DNS Round Robin algorithm will facilitate superior performance.
- Lowering traffic on the wire and only sending what is required and only retrieving what is necessary.
- Reduce the number of transitions between boundaries, and reduce the amount of data transferred over the wire. Choose batch mode to minimize calls over the network channel.
- When communications tier boundaries are crossed, leverage coarse-grained interfaces requiring a reduce number of calls for a specific process, and consider using an asynchronous model of communication.
- Design effective locking, transactions, queuing, and threading mechanisms. Leverage optimum queries for superior performance, and avoid bulk fetching of data when only a subset is required for the operation. Leverage asynchronous APIs, message queuing, or one-way calls to minimize blocking while making calls across tier boundaries.
- Application, database, and server tuning also improve system performance.
- Architect efficient communication methodology and protocols between tiers to ensure entities securely interact with no performance degradation.
- Leverage the container's built-in features such as distributed transaction and authentication that will improve robustness and simplify the architecture.
- Largely granular interfaces require multiple invocations to perform a task and are the best solution alternatives when located on the same physical node.
- Interfaces that make only one call to accomplish each task provide outstanding performance when the components are distributed across physical boundaries.
Separate long-running critical processes that might fail by using a separate physical cluster. For example, a web server provides superior processing capacity and memory but may not have robust storage that can be swapped rapidly in the event of a hardware failure.
The following is a list of the typical units of measurement:
- Throughput: The ability of the system to execute a specified number of transactions in a given span of time
- Response times: The allowable distribution of time which the system takes to respond to the request
- Time: The time it takes to complete a transaction
Probability indicator: 
Scalability is the capability of the application to handle an increase in workload without performance degradion, or the ability to quickly enlarge. Scalability is the ability to enlarge the architecture to accommodate users, processes, transactions, and additional nodes and services as the business system evolves to meet the needs of the future. The existing systems are extended as far as possible without replacing them. Scalability directly affects the architecture as well as the selection of hardware and system software components. Following is a list of design principles:
- There are two architecture choices for achieving scalability. One is vertically, by adding memory, processors, or disks. The other is horizontally, by adding more machines to the system.
- Handling more customer requests requires the system to be scaled by deploying additional web servers.
- Design layers and tiers for scalability, namely to scale out or scale up a web, application, or database tier.
- The key scalability patterns include distributed computing, parallel computing, SOA, event-driven architecture, a push-and-pull data model, optimal load sharing, enterprise portals, and a message model.
- Clustering allows the ability to add processing capability by simply adding nodes to the cluster.
- Using connection pooling for database and resource pooling improves the scalability of applications. Resource pooling, such as database connection pools, is also maintaining multiple logical connections over fewer physical connections and they reusing the connections, bringing in more scalable efficiencies.
- Supplementary application or database servers can be added (horizontal scaling) to improve the scalability of the application.
- Partitioning data across multiple database servers to improve scalability and allowing flexible location for datasets.
- Design logical layers on the same physical tier to reduce the number of physical nodes while also increasing load sharing and failover capabilities.
- Leverage design that uses alternative systems when it detects a spike in traffic or increase in user load for an existing system.
- Architect store and forward technique to allow the request to be stored when the target is offline, and send it when it's back online.
- Stateless nature of transactions and requests makes the application more scalable. Design applications using stateless session beans improve the scalability.
- Business logic needs be loosely coupled with the web tier, hence deploying the application components on the separate node is easier. SOA provides scalability at the integration layer through the loose coupling.
The following is a list of typical units of measurement:
- Throughput-how many transactions per hour the system needs to be able to handle
- Year-on-year growth requirements
- Storage-the amount of data the system requires to archive
Probability indicator:
- Availability is defined as the time span the application is normally functional. It is scored as the percentage of total application downtime over a specified period. Availability is affected by faults and exceptions, hardware issues, malicious attacks, and maintenance and upgrades. Availability is the span of time the system is operational and available for its end users. Availability is established as few applications are architected with expected downtime for activities like database upgrades and backups. Following is a list of design principles.
- The application is designed with a hot standby configuration for high availability. In case the primary servers go down the load balancer will be able to route the request to secondary/hot standby nodes. Make the system more available so if one node is down, another node can take over the work.
- The load balancer is configured to route traffic to hot standby if the primary reaches its threshold. The load balancer policies should be optimized to distribute the burden and fail over to standby instances in the event of issues with the primary node.
- Transaction Manager component increases availability and reliability by ensuring the application is always in a consistent state and through a strategy for handling certain classes of failures.
- The design should be stateless so that when a stateless server fails, its work can be routed to a different server without implications for state management.
- The ability to prevent application failures in the event of service/s failures, is commonly architected via redundancy. This can be achieved through fault tolerance techniques such as active and passive replication.
- A robust monitoring infrastructure set up to frequently do a health check of all internal systems such as the web server, application server, and database servers. Develop an internal and external monitoring and alerting infrastructure. This serves as an early warning indicator and helps the operations team to respond quickly in case of issues. Continuous real-time monitoring of internal and external systems is essential to identify and fix production issues
- Ensure that a disaster recovery (DR) site is present, and should have a mirror replica of the code and data from the main site. The load balancer is configured to route the requests to the DR site during peak traffic. A geographically separate site is a redundant site to fail over in the case of natural disasters such as hurricanes or floods.
- Recommended high availability: HA configurations for the database can be set up and configured. This includes clusters, data replication, and all other configuration proposed by the product vendor.
- Avoiding chatty conversations with upstream services to minimize data transfer.
- An open source caching framework, Memcached, can be leveraged to cache the database records and search results. Additionally, a distributed and cluster cache can be implemented for handling large data.
The following are the typical units of measurement:
- Availability: Application availability considering weekends, holidays, and maintenance times and failures.
- Geographic location: Connection requirements and the restrictions of a local network prevail.
- Offline requirement: Time available for offline operations including batch processing and system maintenance. Length of time between failures.
- Recoverability: This is the time needed to be able to resume operation in the event of fault or exceptions.
- Resilience: The reliability characteristics of the system and sub-components.
Probability indicator:
Reliability is the characteristic of an application to continue functioning in an expected manner over time. Reliability is scored as the probability that the application will not fail and that it will keep function for a defined time span. Reliability is the ability of the application to maintain its performance over a specific time span. Unreliable software fails frequently, and specific tasks are more prone to failure because they cannot be restarted or resumed. The following are the design principles:
- Establish an alternative to detect exceptions and automatically initiate a system fail over, or redirect the request to a standby system. Implement code that leverages alternate nodes when a failed request is detected from an existing application.
- Design for instrumentation, such as events or performance counters, that is unavailable, and detects performance problems or external systems failures and expose information through standard interfaces like Windows Management Interface (WMI), Trace files, event Log. Log performance, errors, exceptions and auditing information about calls made to other systems and services.
- Establish alternatives to manage unreliable application, failed APIs, and failed transactions. Identify queuing pending requests if the application goes offline.
- Design store and forward or cached mechanism that allows requests to be stored when the target application is unavailable, and to be forwarded when the target is online.
- Design the solution by leveraging queuing to provide a reliable alternative for asynchronous APIs.
- Solution capability of recovering from error or exception on the basis of the defined error and exception strategy.
- The primary node serves the entire request, but a backup server is added to route traffic if the primary goes down or is made offline for upgrades.
- Data Integrity is established with security controls/mechanisms preventing a third party from making any unauthorized access and/or changes to data.
- Database transactions ensure data integrity as it will be a full commit or a rollback based on the success/failure status.
The following are the typical units of measurement:
- The capability of application to perform required functions under stated conditions for a specific time period.
- Mean Time Between Failures is the acceptable threshold for downtime
- Mean Time To Recovery: Is the time available to get the application back online.
- Data integrity is the referential integrity in databases
- Application Integrity and Information Integrity - during transactions
- Fault trapping (I/O): Handling failures and recovery
Probability indicator: 
Maintainability is the quality of the application to go through changes with a fair degree of effortlessness. This attribute is the flexibility with which the application can be modified, for fixing issues or to add new functionality with a degree of ease. These changes could impact components, services, functionality, and interfaces when modifying for fixing issues, or to meet demands of the future. Maintainability has a direct baring on the time it takes to restore the application to a normal status following a failure or an upgrade. An enlightening maintainability attribute will enhance availability and reduce run-time defects. Following is a list of design principles:
- The logical separation of the application into different tiers (client, presentation, business logic, integration, and Enterprise Integration System (EIS) tier) allows a system to be flexible and easily maintained. When there are any changes in the presentation, they will be done at the presentation tier, and it will not affect the other tiers. If there are any business logic changes, only the EJB component's business logic gets changed; it will not affect other tiers and vice versa.
- The MVC pattern leverages the command pattern at the web tier (JSF Backing Bean classes) for handling web events. Therefore, when new functionalities are added to the system, it will not affect the existing system. We can easily create a new web action by developing new Backing Bean class and configuring it in the
faces-config.xmlfile. Even modifying the existing functionality becomes easy by changing the respective Backing Bean classes. - Object orientation like encapsulation, inheritance, low coupling and high cohesion are leveraged in application design. Any changes to subsystems will have less impact on systems which are using it as long as the interfaces remain the same.
- Independence of the interface from the implementation permits substituting of different implementations for the same functionality.
- Design applications consisting of layers, or areas of concern; that clearly demarcate the UI, business processes, and data access layers.
- Design cross-layer dependencies by using abstractions instead of concrete classes, and minimize dependencies between tiers, layers, and components.
- Define and establish proper communication protocols, models, and formats.
- Design pluggable architecture that facilitates easy maintenance, and improves testing processes.
- Architect interfaces to provide plug-in architecture to maximize flexibility and extensibility.
- Leverage built-in container and platform functions and features wherever possible instead of custom application.
- Architecture to have high cohesion and have low coupling in order to maximize flexibility and facilitate reusability.
- Establish methodology to manage dynamic business processes and dynamic business rules, by using workflow engine for dynamic business processes.
Following are the typical units of measurement:
- Conformance to design standards, coding standards, best practices, reference architectures, and frameworks
- Flexibility: The degree to which the system is intended to support change
- Release support: The way in which the system will support the introduction of initial release, phased rollouts and future releases
- Up-to-date and consistent documentation
Probability indicator:
Extensibility is a characteristic where-in the architecture, design, and implementation actively caters to future business needs.
Extensible applications have excellent endurance, which prevents the expensive processes of procuring large inflexible applications and retiring them due to changes in business needs. Extensibility enables organizations to take advantage of opportunities and respond to risks. but While there is an significant difference extensibility is often tangled with modifiability quality. Following is a list of design principles:
- The logical separation of the application into various tiers (that is, client, presentation, business logic, integration, and EIS tier) allows a system to be flexible and easily maintained. When there are any changes in presentation, it will be done at presentation tier, and it will not affect the other tiers. If there are any changes to the business logic, only the EJB component's business logic is changed; it will not affect other tiers, and vice versa.
- The MVC architecture leverages the command pattern at the web tier (JSF Backing Bean classes) for handling web events. Therefore, when new functionalities are added to the system, it will not affect the existing system. We can easily create a new web action by developing a new
BackingBeanclass and configuring it in thefaces-config.xmlfile. Modifying the existing functionality becomes easy by changing the respectiveBackingBeanclasses. - Object orientations such as, encapsulation, inheritance, high cohesion and low coupling are leveraged in application design. So the subsystem's changes will have less impact on applications that are using it as long as the interfaces remain the same.
- Independence of the interface from the implementation permits substituting different implementations for the same functionality.
- Design systems and layers that demarcate the system's UI, processes, and data access functionality.
- Design cross-layer inter dependencies by leveraging abstractions rather than concrete implementations, and minimize dependencies between layers and components.
- Design a plug-and-play architecture that facilitates easy maintenance and upgrades, and improves QA processes by solutioning APIs, enabling plug-n-play modules or components to maximize flexibility and extensibility.
- Leverage the built-in platform's features wherever available instead of a custom implementation.
- Design modules to have high cohesion and low coupling to enhance flexibility and provide reusability and replacement.
- Establish a method to manage dynamic processes and dynamic rules, by leveraging the workflow engine if the business process tends to change.
- Solution business components to implement the rules if the rule values are dynamic, or a component such as rules engine if the business decision rules are dynamic.
- Provide artifacts that explain the overall structure of the application. Good documentation of the application consists of architecture diagrams, interfaces, class diagrams, sequence diagrams, coding guidelines are the key criterion for maintainable IT systems.
- Identify areas of concern and consolidating them into the logical depiction, business, data, and service layers as appropriate.
- Establishing a development model with tools and frameworks to provide workflow and collaboration.
- Establishing guidelines for architecture, design and coding standards, and incorporating reviews into your SDLC process to ensure guidelines are diligently implemented.
- Establish a migration roadmap from legacy applications, and isolating applications from inter dependencies.
- Expose functionality from layers, subsystems, and modules through APIs that other systems and layers can invoke.
Typical units of measurement:
- Handles new information types
- Manages new or changed business entities
- Consumes or provides new feeds
Probability indicator: 
Security is the ability to avoid the malicious events and incidences of the designed system usage, and prevent loss of information. Establishing proper security enhances the reliability of system by reducing the likelihood of an attack succeeding and disrupting critical functions. Securing protects assets and prevents unauthorized access to sensitive data. The factors affecting security are integrity and confidentiality. The features used to secure applications are authorization, authentication, logging, auditing and encryption. Following is a list of design principles.
- Leverage authorization and authentication to prevent spoofing of identity and identify trust boundaries.
- Design various controls to prevent access to sensitive data or system.
- Establish monitoring and instrumentation to analyze user interaction for critical operations.
- Protect against damages by ensuring that you validate all inputs for type, range, length, and sanitized principles.
- Partition users into anonymous, identified, and authenticated and leverage monitoring and instrumentation for audit instrumentation, logging, and root cause analysis.
- Leverage encryption, sign sensitive data, and use secured transport channels.
- Reduce session timeouts and implement solutions to detect and mitigate against attacks.
- Security will be provided through the DMZ using an inner and outer firewall. Application and database servers will be behind the inner firewall, and the web server will be behind an outer firewall in the DMZ.
- The architecture uses Form Based authentication for the web tier, and the security logic is implemented in are usable business component in the application tier.
- SSL will provide the desired security for sending sensitive information to critical systems like Merchant Bank and Market Place.
- Leverage message-level encryption, digital signatures, and transport-layer security (SSL).
- The application will use LDAP for authentication at the web tier and will use role-based security at the web and business tier for authorization.
- Authorization is control access to information in the application once a user is identified and authenticated.
- Authentication: Identification of the end user in the system and validating that the user is telling the veracity.
- Auditing: Instrumentation and monitoring of security.
- Integrity: Protection against improper modification of information in transit or storage.
- Confidentiality: Protection against inappropriate disclosure of data during transit and storage.
The following are the typical units of measurement:
- Authentication: Correct Identification of parties attempting to access systems and protection of systems from unauthorized parties
- Authorization: Mechanism required to authorize users to perform different functions within the systems
- Encryption (data in flight and at rest): All external communications between the application data server and clients to be encrypted
- Data confidentiality: All data must be proactively established, secured, and archived
- Compliance: The process to confirm systems compliance with the organization's security standards and policies
Probability indicator:
The requirement for session failover enables that the data specific to user sessions needs to be available across all cluster nodes. This mechanism is required to be made invisible to the end users. Session replication is leveraged in application server to achieve session failover namely a session is replicated to other machines, every time the session changes. If a node fails, the load balancer routes in-coming requests to another server in the cluster since all machines in a cluster have a copy of the session. Session replication allows session failover, but it costs in terms of memory and network bandwidth.
Sharing of session data is also implemented through application-level APIs. This is enabled through the persistence layer that allows session data to be managed by other nodes when a failure occurs. Sessions stored in cookies are often cryptographically signed, but the data is not unencrypted. Session data stored in cookies should not contain any sensitive information like credit card data or other personal data. The session data can also be stored in a database or in Memcached component.
The efficiency of session management comes with a cost. Applications that leverage a session management mechanism must maintain each user's session state, stored in memory. This greatly increases the memory footprint of the application. If the session management capability is not implemented, applications will have a smaller footprint.
Probability indicator:
Java EE includes distributed transactions through two specifications:
- Java Transaction API (JTA)
- Java Transaction Service (JTS)
JTA is an protocol that is implementation-independent and allows applications to handle transactions. On the other hand, JTS specifies the implementation of transaction manager for JTA and implements the OMG or Object Transaction Service specification for Java mapping. JTS enables transactions using the Internet Inter-ORB Protocol (IIOP). The transaction manager supports both JTA and JTS. The EJB container itself leverages the Java Transaction API to interact with JTS component. The transaction manager controls all EJB transactions, except for bean-managed transactions and Java Database Connectivity transactions, and allows beans to update multiple databases with a single transaction:
- The application design incorporates container-managed transaction for database transactions, which allows for simpler, more portable code.
- All transactions for one component are managed by a single workflow manager object which is typically stateless bean.
- Architecture leverages JPA Entity to manage payment transactions. The method is invoked with Requires New transaction attribute by a stateless session bean.
- Entity instance is based on rows and Entity Manager takes care of concurrency.
Transaction properties
These properties are known by the ACID acronym. Each letter stands for a property:
- Atomicity: This means that the operations are executed as a whole and by an "all or nothing" rule
- Consistency: Data must be consistent at the beginning and the end of the transaction
- Isolation: When we have concurrent access to data, operations cannot access modified data in the current transaction
- Durability: Once the transaction is finished, modified data must not be lost and should be the same afterward
Transaction types
The following are the types of transactions:
- Global transactions: These transactions are leveraged when dealing with multiple resources such as databases or message queues. In order to use global transactions, Java Transaction API (JTA) is leveraged and it's available in the application server environment.
- Local transactions: Unlike global transactions, local transactions are used to deal with a single resource for example, a JDBC connection for a single database. Normally local transactions are easier to manage than global transactions.
Probability indicator:
Java Authentication and Authorization Service (JAAS) is leveraged to control authentication and authorization in the application. Authentication and role are stored in LDAP server. The UI framework is configured to connect with LDAP and control access according to the roles in the application. Access to the JSP page is controlled by the UI framework. Authentication is done via the HTTP form. Username is the e-mail address mostly and once the user submits the form with username and password, the application checks the details against LDAP server.
Probability indicator:
Instrumentation is the ability to measure the level of a IT system's performance, diagnose errors, and trace audit information. Instrumentation takes the form of code instructions that monitor specific components in an IT application, for example, logging information to appear on UT. When an application has instrumentation embedded, it can be managed using a management tool. Instrumentation is mandatory for reviewing the performance of an application.
Probability indicator:
Compliance means conforming to rules, principles, policies, standard or law. Regulatory compliance describes the goal organizations aspirations to achieve to ensure that they comply with laws and regulations. Due to the increase in regulation domains and the need for transparency, enterprises are adopting consolidated and harmonized sets of compliance controls. This approach ensures that all necessary governance policies can be met without the unnecessary duplication of effort from resources. Data retention is one part of regulatory compliance that is a challenge for many organizations. The security that comes from compliance with regulations can be contrary to maintaining user privacy. Data retention regulations requires the service providers to retain extensive logs of activities beyond the time for normal business hours.
Probability indicator:
Business Continuity (BC) reflects an organization's capability to maintain access to IT resources after unexpected system outages or natural calamities. A comprehensive BC plan and strategy defines an instantaneous failover to redundant resources hosted on-site, off-site, or on the cloud.
Disaster Recovery (DR) strategy provides an organization with recovery for its applications and data within an accepted recovery time, which can translate into hours or even days in the absence of DR plan. The goal is to achieve the best recovery time objective (RTO) and minimize data loss a good recovery point objective (RPO).
Probability indicator:
Such a list can be drawn up and maintained by getting together the heads of IT Operations, IT Architecture and other stakeholders who have an interest in the project's outcome and the solution it will create. The organization must decide who these stakeholder groups are-operations/support and security, architecture, and business.
The following is a checklist of NFRs:
|
NFR |
Attributes |
|
Performance |
|
|
Scalability |
|
|
Availability |
|
|
Capacity |
|
|
Security |
|
|
Maintainability |
|
|
Manageability |
|
|
Reliability |
|
|
Extensibility |
|
|
Recovery |
|
|
Interoperability |
|
|
Usability |
|
Table 1: NFRs KPIs
Probability indicator:
Clustering consists of a group of loosely connected servers or nodes that work in tandem are viewed as a single entity. The components of clusters are connected to each other through fast networks, each node running an instance of the operating system. Clustering provides superior performance and availability over single node, while being more cost-effective than single computers of comparable speed. The benefits of clustering include fault tolerance, load balancing, and replication.
Server clustering is a technique of inter-connecting a number of servers into one group, which works as a unified solution. Server clustering enables multiple servers together to form a cluster that offers higher power, strength, redundancy and scalability. The server clustering ensures high availability and performance, even if there are challenges with one of servers in the cluster solution. The main objective of clustering is to achieve greater availability. A typical server runs on a machine and it runs till there is no hardware failure or some other failure. By creating a cluster, one reduces the probability of the business service and components becoming unavailable in case of a hardware of software failure.
Here are the two types of clusters:
- Application cluster: An application server cluster is a set of machines that can run an application server and can be reliably leveraged with minimum downtime
- Database cluster: A database server cluster is a set of machines that run a database server can be reliably leveraged with a no downtime
The following are the benefits of clustering:
- Server clustering is designed for high availability. In case one of the servers has faults, another server from the cluster takes over and ensures high availability for the business.
- Server clustering is scalable solution and hence nodes can be added or deleted from the cluster as per the business demands.
- If a server from the cluster requires maintenance, it can be made offline while other servers handle its load, making the maintenance simpler.
These are the disadvantages of clustering:
- Server clustering requires more servers to manage and monitor. Thus it increases the infrastructure and cost of IT.
- Server clustering is not very flexible, as not all types of servers can be clustered. There are many applications that do not support clustering.
- It is not a cost-effective solution, as it needs an optimum server design, which can be expensive.
Middle tier clustering
Middle tier clustering is configured in the middle tier of an IT application. This is a common topology as many applications have a middle tier and heavy loads are serviced through the middle tier requiring high scalability and availability. Failure of middle tier causes multiple systems and components to fail. Therefore one of the approaches to do clustering is at the middle tier of an IT application. In the Java world, it is common mechanism to create EJB containers clusters that are leveraged by many clients. Applications with the business logic that needs to be shared across multiple clients can leverage middle tier clustering.
Probability indicator:
Distributed caching, compared to in-memory caching, is one of the common caching mechanisms that deal with large and unpredictable data volumes. In an IT landscape with multiple application instances, consistency of cache and reliability in case of node failures are critical challenges. An in-memory cache resides in the memory of the application instance. So if a node goes down, its cached data is lost. This means another instance of the application has to fetch the data all the way from the database and populate its in-memory cache which is an overhead and inefficient.
Distributed cache stays outside of the application instance. Although there would be several 'cache nodes' part of this distributed cache solution (for high availability), the object is passed from the application to the cache through a single API. This preserves the state of the cache, and results in data consistency. The cache engine determines which node to get the object from, leveraging a hashing algorithm. Also, since the distributed cache isn't linked to any one node, node failures wouldn't always make a difference to the application performance.
Examples of distributed cache solutions are Memcached, Redis, and HazelCast.
Probability indicator:
Capacity planning is a technique of estimating the space, hardware, software and network infrastructure resources that will be needed by an enterprise over future time span. A capacity concern for many enterprises is whether resources will be in place to handle increasing demands on the workload as the number of users increase. The aim of planner is to plan so that new capacity is added just in time to meet the future needs but ensuring the resources do not go unused for a long period. The successful planner is one that makes the trade-offs between the present and the future and proves to be the most cost-efficient.
The planner, leverages business plans, forecasts, trends, and outlines the future needs for an organizations. Analytical modeling tools are also leveraged by planner to get answers to different scenarios and options. The planner leverages tools that are scalable, stable and predictable in terms of upgrades over the life of the product.
Probability indicator:
The table lists various tools that are leveraged by the SMEs for troubleshooting performance issues in Java applications:
|
Tool |
Description |
|
VisualVM |
jconsole comes with JDK 1.5. It is Java Monitoring and Management Console -JMX compliant tool for monitoring a Java VM. It can monitor both local and remote VMs. |
|
VisualVM |
VisualVM integrates with various existing JDK softwares and provides lightweight CPU and memory profiling capabilities. This tool is designed for both production and development environments and enhances the capability of monitoring and analysis for solutions. |
|
HeapAnalyzer |
HeapAnalyzer allows finding possible heap leak area through its heuristic engine and analysis of the heap in applications. It analyzes heap dumps by parsing the heap dump, creating graphs, transforming them into trees, and executing the heuristic search engine. |
|
PerfAnal |
PerfAnal is a GUI tool for analyzing performance of applications on the Java Platform. One can leverage PerfAnal to identify performance problems in code and locate areas that need tuning. |
|
JAMon |
JAMon is a free, simple, high performance, thread safe, Java API that allows developers to easily monitor production applications. |
|
Eclipse Memory Analyzer |
Eclipse Memory Analyzer is a feature rich Java heap analyzer that helps find memory leaks and reduce memory consumption. |
|
GCViewer |
GCViewer is an open source tool used to visualize data produced by the VM options: |
|
HPjmeter |
HPjmeter diagnose the performance problems in applications on HP-Unix, Monitors Java applications and analyzes profiling data. HPjmeter also captures profiling data and improves garbage collection. |
|
HPjconfig |
HPjconfig is a configuration tool for tuning your HP-UX system kernel parameters to match the characteristics of application. HPjconfig provides kernel parameter recommendations tailored to your HP-UX platform. When given specific Java and HP-UX versions, HPjconfig will determine if all of the latest HP-UX patches required for Java performance and functionality are installed on the system, and highlight any missing patches. |
Table 2: Performance Tools
Probability indicator:
A load balancing mechanism is leveraged for distributing user loads across multiple nodes. The most common algorithm for a load balancing algorithm is the Round Robin algorithm. In this mechanism the request is divided in a circular format ensuring all nodes get an equal number of requests and no single node is over or under utilized. The failover mechanism switches to another nodes when one of the node fails or becomes offline. Typically a load balancer is configured to support fail over to another node when the primary node fails. To achieve least downtime, most load balancers support the feature of heart beat check which ensures that target machine is responding and is up and running. As soon as a heartbeat signal fails, load balancer stops sending the requests to that node and redirects the requests to other node of the cluster solution.
The most common load balancing techniques for applications are:
- Round-Robin load balancing
- IP address affinity
- Session affinity or sticky session load balancing
The benefits of load balancing:
|
Benefit |
Description |
|
Redundancy |
Redundancy is a mechamisn of running two or more identical servers, providing a fail-safe behaviour in the event of one server going offline. With load balancing, the system "senses" when a server becomes unavailable and instantly reroutes traffic to other nodes in the cluster. A load-balanced architecture always includes a secondary load balancing device, guaranteeing full redundancy across every component of the network. |
|
Scalability |
Even if there is currently a modest resource requirement, scalability should always be given a consideration for the solution. In a few months, there may be a requirement to add more horse power to your cluster. The smart thing to do is to configure load balancing, which not only lets you get the most out of your current hardware, but also lets you scale your application as needed. |
|
Resource optimization |
With a load balancer in place, one can optimize the traffic distribution to the server cluster to ensure best performance. Load balancers also speed up the application by taking over time-consuming tasks such as SSL encryption and decryption. |
|
Security |
The appliction's security is improved many-fold. Load balancing exposes only one IP to the external world, that is, the Web, which greatly lowers the number of breach points for any attack. The topology of the IT network is hidden, which improves the safety of the entire setup. The servers from the cluster receive virtual IPs, which enables the load balancer to route traffic as needed without exposing the addresses to hackers. |
Table 3: Benefits of LoadBalancing
Load balancing tools
There are both hardware and software load balancing solutions. Hardware load balancers are usually located in front of the web tier and sometimes in between web and application tiers. Most software clustering solutions include load balancing software that is leveraged by upstream software components. A reverse proxy, such as Squid, is used to distribute the load across multiple servers. Open source load balancing software solutions include Perlbal, Pen, and Pound. Hardware-based solutions include BigIP and ServerIron, among others.
Probability indicator:
IP address affinity is a common mechanism for load balancing. In this method, the client IP address is associated with a server node. All requests from a client IP address are serviced by one server node. This technique is very simple to deploy since the IP address is available in the HTTP header and no additional configuration is required to be done.
This type of load balancing can be useful if the clients are likely to disable cookies. There is a flipside to this approach, however. If the users are behind a network address translation or NATed IP address, then all of them will end up routed to the same server node. This may lead to uneven load on the server. NATed IP addresses are very common; in fact, if one is browsing from an office network, it's likely that NATed IP address is leveraged.
Probability indicator: