A REPORT

ON

LOAD AND PERFORMANCE ANALYSIS OF J2EE WEB

APPLICATIONS

BY

Piyush Kandpal 2005B4A8563P Prem Kumar 2006C6PS438G

AT

Reflexis Systems India Pvt. Ltd., Pune

A Practice School-II station of

BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE-PILANI

10th December, 2009

2

A REPORT

ON

LOAD AND PERFORMANCE TESTING OF J2EE WEB

APPLICATIONS

BY

Piyush Kandpal 2005B4A8563P Prem Kumar 2006C6PS438G

AT

Reflexis Systems India Pvt. Ltd., Pune

Report submitted for the partial fulfillment

of the course

BITS C412 / BITS G639: Practice School – II

BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE-PILANI

10th December, 2009

3

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE

PILANI (RAJASTHAN)

Practice School Division

Station: Reflexis Systems India Pvt. Ltd

Center: Pune (Maharashtra)

Duration: 5 ½ months Date of start: 2nd July, 2009

Date of submission: 10th December, 2009

Title of Project: “Load and Performance testing of J2EE web applications”

ID NO. Name Discipline

2005B4A8563P Piyush Kandpal M.Sc.(hons) Mathematics & B.E.(hons) Electronics And Instrumentation

2006C6PS438G Prem Kumar M.Sc.(tech) Information Systems

Name of Project Expert: Designation:

Mr. Parijat Sharma Project Manager of Load

And Performance Testing Team

Name of PS Faculty

Dr. B.V.Prasad

Key Words: Load test, Performance Test, Java, J2EE, JSP, Application Server, HTTP,

Database server.

Project Areas: Load and performance testing of J2EE web applications

Abstract : Load Testing of j2ee Web Applications for the achieving the desired result in

terms of Response time, Throughput, Resource utilization, Maximum user load, Byte

Transferred. Analyzing these results and suggesting the scope of performance

improvement to developer. Memory and Code profiling of the Web Application for the

detection of performance bottleneck.

Signature of the PS II Students: Signature of PS II Faculty:

Piyush Kandpal, Prem Kumar.

Date: 10 December 2009 Date:

4

I.Acknowledgement

We express our profound gratitude to the Founder and CEO of Reflexis Systems India Pvt. Ltd., Mr. Prashanth Palakuthi for having given this wonderful opportunity for doing our Practice School II in such an esteemed organization. We would also like to thank our PS II Coordinator Mr. Praveen Kulkarni, the HR Manager of Reflexis India, who cooperated a lot in conducting our Practice School programme in Reflexis Systems. We express our sincere thanks to our Team Manager of Performance and Load testing, Mr. Parijat Sharma who gave us an opportunity to work under his able guidance and gain a good experience in the field of testing in IT industry and spending some of his invaluable time by sorting out our queries. We would also like to thank Mr. Ashish Mane for giving us valuable information at times when we were facing difficulties to proceed and also for guiding us all along. We would also like to thank Prof. G.Sundar, Dean of Practice School Division, BITS Pilani for giving us the opportunity to work in industrial environment in form of Practice School programme of BITS Pilani. We express sincere thanks to our PS faculty, Dr. B.V. Prasad for making Practice School - II program run smoothly and guiding us at every step in Practice School programme. .

5

Table of Contents

I Acknowledgement 4

1 Introduction

1.1 Reflexis Systems India 8

1.2 Reflexis Retail Execution Management Platform 9

1.3 Some facts and figures about Reflexis Systems 10

Part I

2 J2EE Web application

2.1 Java Server Pages 12

2.2 Java Servlet 13

3 Application server

3.1 Examples of Application Servers 18

4 Database

4.1 Architecture 20

4.2 Database management systems 21

4.3 Components of DBMS 21

4.4 Primary tasks of DBMS packages 22

4.5 Types of Database 23

4.6 Models 25

6

4.7 Storage structures 26

4.8 Applications 30

4.9 Databases in new media 30

5 Factors That Impact Database Performance

5.1 System Characteristics 31

5.2 Memory 33

6 Examples of Databases

6.1 MySQL 34

6.2 MySQL Memory Usage 35

6.3 Tuning Server Parameters 36

6.4 MySQL Query Cache 37

6.5 Oracle Database 40

Part II

7 Software Performance Testing

7.1 Introduction 43

7.2 Performance Checklist 44

7.3 Performance Testing Methods 45

7.4 Load Testing by Apache Jmeter 47

8 Java memory management

8.1 Memory Leaks and Method to prevent those 52

8.2 Code Profiling using Java Interactive Profiler 58

7

8.3 Heapdump Analysys using Eclipse Memory Analyzer 59

9 Load Testing by AppPerfect 62

10 Conclusions and Recommendations 68

II Appendices 70

III References 72

IV Glossary 73

8

Introduction

1.1 Reflexis Systems India

Reflexis Systems Inc based on Norwood, MA, USA is a task management software company that implements a workflow system for retailers with multiple locations. It is the pioneer of management in Retail and is the only vendor in the world that combines Task Management, Scheduling and KPI/compliance. They have four products –Retail Auction KPI Activator for leveraging exception based metrics, Retail auction Store walk for conducting detailed store walks and audits, Retail Action Labor Scheduler for matching schedules to actual task driven workloads. It has 24 of world’s largest retailers as customers-most of whom are category leaders .The Home Depot, Sears Holding Corp, CircuitCity, Staples, Barnes and Noble, Dick’s Sporting Goods, etc are their customers, to name a few. Product development and maintenance is done at Reflexis Systems India Pvt. Ltd in Pune. Reflexis helps retailers turn strategy into action and increase sales. Reflexis customers have reported dramatic improvements in store-level compliance with corporate strategies; higher productivity of merchandising, field, and store management; and increased sales and profitability. Reflexis solutions enable retailers to drive excellence in their merchandising, store, and vendor operations by employees, suppliers, and third party service providers. Reflexis Systems, Inc. is privately held and headquartered in Dedham, Massachusetts, with the Customer Operations Group in Kennesaw, Georgia and international offices in the UK, Germany, and India.

Pic 1.1 reflexis logo

9

1.2 Reflexis Retail Execution Management

Platform

Reflexis has developed and delivered answers to this age-old retail challenge, to many of the most respected names in the business. Reflexis delivers on its promise of boosting sales and improving operations through its powerful Retail Execution Management Platform.

Pic 1.2 flowchart of reflexis retail execution platform

The Reflexis Retail Execution Platform enables execution excellence by the entire eco-system of retailers, suppliers, and their representatives. The Web-based solutions can be implemented individually or as an integrated suite to drive best-in-class execution in four areas: Merchandising Operations, Store Operations, Vendor Operations, and Execution Support. With Retail Execution solutions, retailers can coordinate planning, optimize workloads, streamline communication, monitor performance in real time, and respond pro-actively to key sales and operations metrics using best practices.

Merchandising Operations

With Reflexis solutions for Merchandising, retailers can coordinate planning, increase visibility, and bridge the execution gap between merchandising and store operations. Reflexis Merchandising Process Manager enables retailers to coordinate and monitor completion status of the many steps involved in complex merchandising projects. Reflexis Workload Optimizer integrates long-range planning and short-range scheduling to ensure stores have the labor resources to complete corporate-driven tasks while meeting customer service objectives. Reflexis Merchandising solutions allow retailers to streamline merchandising planning processes and consistently execute corporate strategy in their stores.

10

Store Operations

Reflexis solutions for Store Operations enable retailers to ensure consistent execution of their corporate strategy by all stores and recover the sales they would have otherwise lost. Reflexis solutions include Task Manager (for closed-loop task management), StoreWalk (for ensuring consistency from enhanced store walks and audits), Workforce Manager (for forecasting and scheduling labor based on sales forecasts, corporate initiatives, and employee skills and work preferences), and Visual Verification (for leveraging digital photographs to ensure compliance in the stores). Reflexis Store Operations solutions enable retailers to boost productivity, increase sales, and realize rapid ROI. Reflexis has repeatedly implemented its solutions in 21 weeks or less, across multiple store formats at some of the world's largest retailers.

Vendor Operations

Reflexis solutions for Vendor Operations enable retailers to optimize scheduling, streamline communication, and monitor tasks completed by suppliers, third party service providers, and mobile retail support teams. Vendor Activity Scheduler enables retailers to coordinate and schedule tasks performed by mobile teams in concert with other activities occurring in the stores. Vendor Performance Manager is a mobile workforce automation solution that drives task and project management to the point of execution in the field.

Retail Execution Support

Flawless execution requires a proficient workforce empowered by information tools and backed up by a team of hardware and software experts who support the system throughout its lifecycle. The Reflexis Retail Execution Support platform provides business intelligence, learning, store issue resolution, and mobility solutions that enable a highly skilled workforce to quickly identify key trends and respond using best practices. The platform includes the Enterprise Learning System (for improving employee proficiency and reducing costs by shifting from paper- to PDA-based learning), Managed Mobility Services (which supports fast and cost-effective deployment of mobile solutions through hosting, staging, training, user support, and break/fix services), Store Issue Manager (for closed-loop stores-to-headquarters communication of a wide variety of events with the ability to escalate issues and monitor resolution), and KPI Activator (for real-time, KPI-driven alerts with the ability to assign corrective response based on best practices).

11

1.3 Some facts and figures about Reflexis Systems

Founded - 2001

Global Presence - Headquartered in Massachusetts, USA with offices in Georgia, USA; UK; Germany; and India

Number of Employees - 350+

Number of Customers - 80+

Number of Stores - 40,000

Acquisitions - Enfotrust Networks, November 2007

Ownership - Private

Funding - Founders; FirstMark Capital, L.L.C.

Some of Partners of Reflexis Systems are Cisco, Fujitsu, IBM and Motorola.

12

2. J2EE Web application

2.1 Java Server Pages

Java Server Pages (JSP) is a server side Java technology that allows software developers to create dynamically generated web pages, with HTML, XML, or other document types, in response to a Web client request to a Java Web Application container (server). Architecturally, JSP may be viewed as a high-level abstraction of Java Servlets. JSP pages are loaded in the server and operated from a structured special installed Java

server packet called a J2EE Web Application often packaged as a .war or .ear file archive.

The technology allows Java code and certain pre-defined actions to be embedded into static page content and compiled on the server at runtime of each page request. Both the Java Server (J2EE specification) and the page scripts and/or extended customized programming added operate by (in the runtime context of being loaded programs used) a special pre-installed base program called a virtual machine (VM) that integrates with the host operating system, this type being the Java Virtual Machine (JVM).

JSP syntax has two basic forms, scriptlet and markup though fundamentally the page is either HTML or XML markup. Scriptlet tagging (called Scriptlet Elements)(delimited) blocks of code with the markup are not effectively markup and allows any java server relevant API (e.g. the servers running binaries themselves or database connections API or java mail API) or more specialist JSP API language code to be embedded in an HTML or XML page provided the correct declarations in the JSP file and file extension of the page are used.

Scriptlet blocks do not require to be completed in the block itself only the last line of the block itself being completed syntactically correctly as a statement is required, it can be completed in a later block. This system of split inline coding sections is called step over scripting because it can wrap around the static markup by stepping over it. At runtime (during a client request) the code is compiled and evaluated, but compilation of the code generally only occurs when a change to the code of the file occurs.

The JSP syntax adds additional XML-like tags, called JSP actions, to be used to invoke built-in functionality. Additionally, the technology allows for the creation of JSP tag libraries that act as extensions to the standard HTML or XML tags. JVM operated Tag libraries provide a platform independent way of extending the capabilities of a web server.

13

2.2 Java Servlet

Servlets are Java programming language objects that dynamically process requests and construct responses. The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as PHP, CGI and ASP.NET, and as such some find it easier to think of them as 'Java scripts' (Not to be confused with JavaScript). Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting.

The servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the Servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.

A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and

execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application. Servlets can be generated automatically by Java Server Pages (JSP) compiler, or alternately use template engines such as WebMacro or Apache Velocity to generate HTML. Often servlets are used in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model-view-controller pattern.

14

Client Server Database Architecture

15

Application server

An application server is a software framework dedicated to the efficient execution of procedures (scripts, routines, programs ...) for supporting the construction of applications. The term was created in the context of web applications. In these, the application server acts as a set of components accessible to the software developer through an API defined by the platform itself. These components are usually performed in the same machine where the web server is running, and their main job is to support the construction of dynamic pages.

Other uses of the term can refer to:

1. the services that a server makes available 2. the computer hardware on which the services run

Java application servers

Following the success of the Java platform, the term application server sometimes refers to a J2EE or Java EE 5 application server. Some of the better-known Java Enterprise Edition application servers include:

• Apache Tomcat (Apache Software Foundation) • Tomcat Server (MuleSoft) • tc Server (SpringSource) • WebSphere Application Server and WebSphere Application Server Community

Edition (IBM) • Sybase Enterprise Application Server (Sybase Inc) • WebLogic Server (Oracle) • JBoss (Red Hat) • JRun (Adobe Systems) • Apache Geronimo (Apache Software Foundation) • Oracle OC4J (Oracle) • Sun GlassFish Enterprise Server (based on GlassFish Application Server)(Sun

Microsystems) • SAP Netweaver AS (ABAP/Java) (SAP) • Glassfish Application Server (open source) • WebObjects (Apple Inc.)

The web modules include Servlets and Java Server Pages. Business logic resides in Enterprise JavaBeans (EJB-3 and later). The Hibernate project offers an EJB-3 container implementation for the JBoss application server. Tomcat from Apache and JOnAS from ObjectWeb exemplify typical containers which can store these modules.

16

A Java Server Page (JSP) (a servlet from Java) executes in a web container — the Java equivalent of CGI scripts. JSPs provide a way to create HTML pages by embedding references to the server logic within the page. HTML coders and Java programmers can work side by side by referencing each other's code from within their own. JavaBeans are the independent class components of the Java architecture from Sun Microsystems.

The application servers mentioned above mainly serve web applications. Some application servers target networks other than web-based ones: Session Initiation Protocol servers, for instance, target telephony networks.

Microsoft platform

Microsoft has contributed the .NET Framework to the world of application servers. .NET technology includes the Windows Communication Foundation, .NET Remoting, ADO.NET, and ASP.NET among several other components. It works with (or depends upon) other Microsoft products, such as Microsoft Message Queuing and Internet Information Services.

Zend platform

Zend offers an application server called Zend Server — used for running and managing PHP applications.

Other platforms

Open-source application servers also come from other vendors. Examples include:

• Appaserver, • Base4, • Zope, and • Spring Framework.

Non-Java offerings have no formal interoperability specifications on a par with the Java Specification Request. As a result, interoperability between non-Java products is poor compared to that of Java EE based products. To address these shortcomings, specifications for enterprise application integration and service-oriented architecture were designed to connect the many different products. These specifications include Business Application Programming Interface, Web Services Interoperability, and Java EE Connector Architecture.

17

Advantages of application servers Data and code integrity By centralizing business logic on an individual server or on a small number of server machines, updates and upgrades to the application for all users can be guaranteed. There is no risk of old versions of the application accessing or manipulating data in an older, incompatible manner. Centralized configuration Changes to the application configuration, such as a move of database server, or system settings, can take place centrally. Security A central point through which service-providers can manage access to data and portions of the application itself counts as a security benefit, devolving responsibility for authentication away from the potentially insecure client layer without exposing the database layer. Performance By limiting the network traffic to performance-tier traffic the client-server model improves the performance of large applications in heavy usage environments. Total Cost of Ownership (TCO) In combination, the benefits above may result in cost savings to an organization developing enterprise applications. In practice, however, the technical challenges of writing software that conforms to that paradigm, combined with the need for software distribution to distribute client code, somewhat negate these benefits. Transaction Support A transaction represents a unit of activity in which many updates to resources (on the same or distributed data sources) can be made atomic (as an indivisible unit of work). End-users can benefit from a system-wide standard behaviour, from reduced time to develop, and from reduced costs. As the server does a lot of the tedious code-generation, developers can focus on business logic.

18

3.1 Examples of Application Servers

Apache Tomcat

Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is a servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlets and the Java Server Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.

Tomcat should not be confused with the Apache web server, which is a C implementation of an HTTP web server; these two web servers are not bundled together. Apache Tomcat includes tools for configuration and management, but can also be configured by editing XML configuration files.

Components

Tomcat version 4.x was released with Jasper (a redesigned JSP engine), Catalina (a redesigned Servlets container) and Coyote (an HTTP connector).

Catalina

Catalina is Tomcat's Servlets container. Catalina implements Sun Microsystems' specifications for Servlets and Java Server Pages (JSP). The architect for Catalina was Craig McClanahan.

Coyote

Coyote is Tomcat's HTTP Connector component that supports the HTTP 1.1 protocol for the web server or application container. Coyote listens for incoming connections on a specific TCP port on the server and forwards the request to the Tomcat Engine to process the request and send back a response to the requesting client.

Jasper

Jasper is Tomcat's JSP Engine. Tomcat 5.x uses Jasper 2, which is an implementation of the Sun Microsystems's Java Server Pages 2.0 specification. Jasper parses JSP files to compile them into Java code as Servlets (that can be handled by Catalina). At runtime, Jasper is able to automatically detect JSP file changes and recompile them.

Jasper 2

From Jasper to Jasper 2, important features were added:

19

• JSP Tag library pooling - Each tag markup in JSP file is handled by a tag handler class. Tag handler class objects can be pooled and reused in the whole JSP servlet.

• Background JSP compilation - While recompiling modified JSP Java code, the older version is still available for server requests. The older JSP servlet is deleted once the new JSP Servlets has been recompiled.

• Recompile JSP when included page changes - Pages can be inserted and included into a JSP at compile time. The JSP will not only be automatically recompiled with JSP file changes but also with included page changes.

• JDT Java compiler - Jasper 2 can use the Eclipse JDT Java compiler instead of Ant and javac.

Glassfish

GlassFish is an open source application server project led by Sun Microsystems for the Java EE platform. The commercial version is called Sun GlassFish Enterprise Server. GlassFish is free software, dual-licensed under two free software licenses: the Common Development and Distribution License (CDDL) and the GNU General Public License (GPL) with the classpath exception.

GlassFish is based on source code donated by Sun and Oracle Corporation's TopLink persistence system. It uses a derivative of Apache Tomcat as the servlet container for serving Web content, with an added component called Grizzly which uses Java NIO for scalability and speed.

20

Database

Database is an integrated collection of logically related records or files consolidated into a common pool that provides data for one or more multiple uses. One way of classifying databases involves the type of content, for example: bibliographic, full-text, numeric, image. Other classification methods start from examining database models or database architectures: see below. Software organizes the data in a database according to a database model. As of 2009 the relational model occurs most commonly. Other models such as the hierarchical model and the network model use a more explicit representation of relationships.

4.1 Architecture

A number of database architectures exist. Many databases use a combination of strategies.

Databases consist of software-based "containers" that are structured to collect and store information so users can retrieve, add, update or remove such information in an automatic fashion. Database programs are designed for users so that they can add or delete any information needed. The structure of a database is the table, which consists of rows and columns of information.

Online Transaction Processing systems (OLTP) often use a "row oriented" or an "object oriented" data store architecture, whereas data-warehouse and other retrieval focused applications like Google's BigTable, or bibliographic database (library catalog) systems may use a Column oriented DBMS architecture.

Document-Oriented, XML, knowledgebases, as well as frame databases and RDF-stores (also known as triple stores), may also use a combination of these architectures in their implementation.

Not all databases have or need a database schema ("schema-less databases").

Over many years general-purpose database systems have dominated the database industry. These offer a wide range of functions, applicable to many, if not most circumstances in modern data processing. These have been enhanced with extensible datatypes (pioneered in the PostgreSQL project) to allow development of a very wide range of applications.

There are also other types of databases which cannot be classified as relational databases. Most notable is the object database management system, which stores language objects natively without using a separate data definition language and without translating into a separate storage schema. Unlike relational systems, these object databases store the relationship between complex data types as part of their storage model in a way that does

21

not require runtime calculation of related data using relational algebra execution algorithms.

4.2 Database management systems

A database management system (DBMS) consists of software that organizes the storage of data. A DBMS controls the creation, maintenance, and use of the database storage structures of social organizations and of their users. It allows organizations to place control of organization wide database development in the hands of Database Administrators (DBAs) and other specialists. In large systems, a DBMS allows users and other software to store and retrieve data in a structured way.

Database management systems are usually categorized according to the database model that they support, such as the network, relational or object model. The model tends to determine the query languages that are available to access the database. One commonly used query language for the relational database is SQL, although SQL syntax and function can vary from one DBMS to another. A common query language for the object database is OQL, although not all vendors of object databases implement this, majority of them do implement this method. A great deal of the internal engineering of a DBMS is independent of the data model, and is concerned with managing factors such as performance, concurrency, integrity, and recovery from hardware failures. In these areas there are large differences between the products.

A relational database management system (RDBMS) implements features of the relational model. In this context, Date's "Information Principle" states: "the entire information content of the database is represented in one and only one way. Namely as explicit values in column positions (attributes) and rows in relations (tuples). Therefore, there are no explicit pointers between related tables." This contrasts with the object database management system (ODBMS), which does store explicit pointers between related types.

4.3 Components of DBMS

According to the wikibooks open-content textbooks, "Design of Main Memory Database System/Overview of DBMS", most DBMS as of 2009 implement a relational model. Other less-used DBMS systems, such as the object DBMS, generally operate in areas of application-specific data management where performance and scalability take higher priority than the flexibility of ad hoc query capabilities provided via the relational-algebra execution algorithms of a relational DBMS.

RDBMS components

• Interface drivers - A user or application program initiates either schema modification or content modification. These drivers are built on top of SQL. They provide methods to prepare statements execute statements, fetch results, etc.

22

Examples include DDL, DCL, DML, ODBC, and JDBC. Some vendors provide language-specific proprietary interfaces. For example MySQL provides drivers for PHP, Python, etc.

• SQL engine - This component interprets and executes the SQL query. It comprises three major components (compiler, optimizer, and execution engine).

• Transaction engine - Transactions are sequences of operations that read or write database elements, which are grouped together.

• Relational engine - Relational objects such as Table, Index, and Referential integrity constraints are implemented in this component.

• Storage engine - This component stores and retrieves data records. It also provides a mechanism to store metadata and control information such as undo logs, redo logs, lock tables, etc.

ODBMS components

• Language drivers - A user or application program initiates either schema modification or content modification via the chosen programming language. The drivers then provide the mechanism to manage object lifecycle coupling of the application memory space with the underlying persistent storage. Examples include C++, Java, .NET, and Ruby.

• Query engine - This component interprets and executes language-specific query commands in the form of OQL, LINQ, JDOQL, JPAQL, others. The query engine returns language specific collections of objects which satisfy a query predicate expressed as logical operators e.g. >, <, >=, <=, AND, OR, NOT, GroupBY, etc.

• Transaction engine - Transactions are sequences of operations that read or write database elements, which are grouped together. The transaction engine is concerned with such things as data isolation and consistency in the driver cache and data volumes by coordinating with the storage engine.

• Storage engine - This component stores and retrieves objects in an arbitrarily complex model. It also provides a mechanism to manage and store metadata and control information such as undo logs, redo logs, lock graphs, etc.

4.4 Primary tasks of DBMS packages

• Database Development: used to define and organize the content, relationships, and structure of the data needed to build a database.

• Database Interrogation: can access the data in a database for information retrieval and report generation. End users can selectively retrieve and display information and produce printed reports and documents.

• Database Maintenance: used to add, delete, update, correct, and protect the data in a database.

• Application Development: used to develop prototypes of data entry screens, queries, forms, reports, tables, and labels for a prototyped application. Or use 4GL or 4th Generation Language or application generator to develop program codes.

23

4.5 Types of Database

Operational database

These databases store detailed data needed to support the operations of an entire organization. They are also called subject-area databases (SADB), transaction databases, and production databases. For example:

• customer databases • personal databases • inventory databases

Analytical database

These databases store data and information extracted from selected operational and external databases. They consist of summarized data and information most needed by an organization's management and other end-users. Some people refer to analytical databases as multidimensional databases, management databases, or information databases.

Data warehouse

A data warehouse stores data from current and previous years — data extracted from the various operational databases of an organization. It becomes the central source of data that has been screened, edited, standardized and integrated so that it can be used by managers and other end-user professionals throughout an organization

Distributed database

These are databases of local work-groups and departments at regional offices, branch offices, manufacturing plants and other work sites. These databases can include segments of both common operational and common user databases, as well as data generated and used only at a user’s own site.

End-user database

These databases consist of a variety of data files developed by end-users at their workstations. Examples of these are collections of documents in spreadsheets, word processing and even downloaded files.

External database

These databases provide access to external, privately-owned data online — available for a fee to end-users and organizations from commercial services. Access to a wealth of

24

information from external database is available for a fee from commercial online services and with or without charge from many sources in the Internet.

Hypermedia databases on the web

These are a set of interconnected multimedia pages at a web-site. They consist of a home page and other hyperlinked pages of multimedia or mixed media such as text, graphic, photographic images, video clips, audio etc.

Navigational database

In navigational databases, queries find objects primarily by following references from other objects. Traditionally navigational interfaces are procedural, though one could characterize some modern systems like XPath as being simultaneously navigational and declarative.

In-memory databases

In-memory databases primarily rely on main memory for computer data storage. This contrasts with database management systems which employ a disk-based storage mechanism. Main memory databases are faster than disk-optimized databases since the internal optimization algorithms are simpler and execute fewer CPU instructions. Accessing data in memory provides faster and more predictable performance than disk. In applications where response time is critical, such as telecommunications network equipment that operates emergency systems, main memory databases are often used.

Document-oriented databases

Document-oriented databases are computer programs designed for document-oriented applications. These systems may be implemented as a layer above a relational database or an object database. As opposed to relational databases, document-based databases do not store data in tables with uniform sized fields for each record. Instead, they store each record as a document that has certain characteristics. Any number of fields of any length can be added to a document. Fields can also contain multiple pieces of data.

Real-time databases

A real-time database is a processing system designed to handle workloads whose state may change constantly. This differs from traditional databases containing persistent data, mostly unaffected by time. For example, a stock market changes rapidly and dynamically. Real-time processing means that a transaction is processed fast enough for the result to come back and be acted on right away. Real-time databases are useful for accounting, banking, law, medical records, multi-media, process control, reservation systems, and scientific data analysis. As computers increase in power and can store more

25

data, real-time databases become integrated into society and are employed in many applications.

Relational Database

The standard of business computing as of 2009, relational databases are the most commonly used database today .It uses the table to structure information so that it can be readily and easily searched through.

4.6 Models

Post-relational database models

Products offering a more general data model than the relational model are sometimes classified as post-relational. The data model in such products incorporates relations but is not constrained by the Information Principle which requires the representation of all information by data values in relation to it.

Some of these extensions to the relational model actually integrate concepts from technologies that pre-date the relational model. For example, they allow representation of a directed graph with trees on the nodes.

Some products implementing such models do so by extending relational database systems with non-relational features. Others, however, have arrived in much the same place by adding relational features to pre-relational systems. Paradoxically, this allows products that are historically pre-relational, such as PICK and MUMPS, to make a plausible claim to be post-relational in their current architecture.

Object database models

In recent years, the object-oriented paradigm has been applied to database technology, creating various kinds of new programming models known as object databases. These databases attempt to bring the database world and the application-programming world closer together, in particular by ensuring that the database uses the same type system as the application program. This aims to avoid the overhead (sometimes referred to as the impedance mismatch) of converting information between its representation in the database (for example as rows in tables) and its representation in the application program (typically as objects). At the same time, object databases attempt to introduce key ideas of object programming, such as encapsulation and polymorphism, into the world of databases.

A variety of these ways have been tried for storing objects in a database. Some products have approached the problem from the application-programming side, by making the objects manipulated by the program persistent. This also typically requires the addition of

26

some kind of query language, since conventional programming languages do not have the ability to find objects based on their information content. Others have attacked the problem from the database end, by defining an object-oriented data model for the database, and defining a database programming language that allows full programming capabilities as well as traditional query facilities.

4.7 Storage structures

Databases may store relational tables/indexes in memory or on hard disk in one of many forms:

• ordered/unordered flat files • ISAM • heaps • hash buckets • B+ trees

These have various advantages and disadvantages - discussed further in the articles on each topic. The most commonly used are B+ trees and ISAM.

Object databases use a range of storage mechanisms. Some use virtual memory-mapped files to make the native language (C++, Java etc.) objects persistent. This can be highly efficient but it can make multi-language access more difficult. Others break the objects down into fixed- and varying-length components that are then clustered tightly together in fixed sized blocks on disk and reassembled into the appropriate format either for the client or in the client address space. Another popular technique involves storing the objects in tuples (much like a relational database) which the database server then reassembles for the client.

Other important design choices relate to the clustering of data by category (such as grouping data by month, or location), creating pre-computed views known as materialized views, partitioning data by range or hash. Memory management and storage topology can be important design choices for database designers as well. Just as normalization is used to reduce storage requirements and improve the extensibility of the database, conversely denormalization is often used to reduce join complexity and reduce execution time for queries.

Indexing

All of these databases can take advantage of indexing to increase their speed. This technology has advanced tremendously since its early uses in the 1960s and 1970s. The most common kind of index uses a sorted list of the contents of some particular table column, with pointers to the row associated with the value. An index allows a set of table rows matching some criterion to be quickly located. Typically, indexes are also stored in the various forms of data-structure mentioned above (such as B-trees, hashes, and linked

27

lists). Usually, a database designer selects specific techniques to increase efficiency in the particular case of the type of index required.

Most relational DBMSs and some object DBMSs have the advantage that indexes can be created or dropped without changing existing applications making use of them, The database chooses between many different strategies based on which one it estimates will run the fastest. In other words, indexes act transparently to the application or end-user querying the database; while they affect performance, any SQL command will run with or without indexes to compute the result of an SQL statement. The RDBMS will produce a query plan of how to execute the query: often generated by analyzing the run times of the different algorithms and select the quickest process. Some of the key algorithms that deal with joins are nested loop join, sort-merge join and hash join. Which of these an RDBMS selects may depend on whether an index exists, what type it is, and its cardinality.

An index speeds up access to data, but it has disadvantages as well. First, every index increases the amount of storage used on the hard drive which is also necessary for the database file, and second, the index must be updated each time the data are altered, and this costs time. (Thus an index saves time in the reading of data, but it costs time in entering and altering data. It thus depends on the use to which the data are to be put whether an index is overall a net plus or minus in the quest for efficiency.)

A special case of an index is a primary index based on a primary key: a primary index must ensure a unique reference to a record. Often, for this purpose one simply uses a running index-number (ID number). Primary indexes play a significant role in relational databases, and they can speed up access to data considerably.

Transactions and concurrency

In addition to their data model, most practical databases ("transactional databases") attempt to enforce database transactions. Ideally, the database software should enforce the ACID rules, summarized here:

• Atomicity: Either all the tasks in a transaction must happen, or none of them. The transaction must be completed, or else it must be undone (rolled back).

• Consistency: Every transaction must preserve the integrity constraints — the declared consistency rules — of the database. It cannot leave the data in a contradictory state.

• Isolation: Two simultaneous transactions cannot interfere with one another. Intermediate results within a transaction must remain invisible to other transactions.

• Durability: Completed transactions cannot be aborted later or their results discarded. They must persist through (for instance) restarts of the DBMS after crashes.

28

In practice, many DBMSs allow the selective relaxation of most of these rules — for better performance.

Concurrency control ensures that transactions execute in a safe manner and follow the ACID rules. The DBMS must be able to ensure that only serializable, recoverable schedules are allowed, and that no actions of committed transactions are lost while undoing aborted transactions.

Replication

Replication of databases often relates closely to transactions. If a database can log its individual actions, one can create a duplicate of the data in real time. DBAs can use the duplicate to improve performance and/or the availability of the whole database system.

Common replication concepts include:

• master/slave Replication: All write-requests are performed on the master and then replicated to the slave(s)

• quorum: The result of Read and Write requests are calculated by querying a "majority" of replicas

• multimaster: Two or more replicas sync each other via a transaction identifier

Parallel synchronous replication of databases enables the replication of transactions on multiple servers simultaneously, which provides a method for backup and security as well as data availability. This is commonly referred to as database clustering.

Security

Database security denotes the system, processes, and procedures that protect a database from unintended activity. Enforcing security is one of the major tasks of the DBA.

DBMSs usually enforce security through access control, auditing, and encryption:

• Access control ensures and restricts who can connect and what they can do to the database.

• Auditing logs what action or change has been performed, when and by whom. • Encryption: many commercial databases include built-in encryption mechanisms

to encode data natively into tables and to decipher information "on the fly" when a query comes in. DBAs can also secure and encrypt connections if required using DSA, MD5, SSL or legacy encryption standards.

In the United Kingdom, legislation protecting the public from unauthorized disclosure of personal information held on databases falls under the Office of the Information Commissioner. Organizations based in the United Kingdom and holding personal data in electronic format (databases for example) must register with the Data Commissioner.

29

Locking

Databases handle multiple concurrent operations with locking. This is how concurrency and some form of basic integrity is managed within the database system. Such locks can be applied on a row level, or on other levels like page (a basic data block), extent (multiple array of pages) or even an entire table. This helps maintain the integrity of the data by ensuring that only one process at a time can modify the same data.

In basic file system files or folders, only one lock at a time can be set restricting the usage to one process only. Databases, on the other hand, can set and hold multiple locks at the same time on the different levels of the physical data structure. The database engine locking scheme determines how to set and maintain locks based on the submitted SQL or transactions by the users. Generally speaking, any activity on the database should involve some or extensive locking.

As of 2009 most DBMS systems use shared and exclusive locks. Exclusive locks mean that no other lock can acquire the current data object as long as the exclusive lock lasts. DBMSs usually set exclusive locks when the database needs to change data, as during an UPDATE or DELETE operation.

Shared locks can take ownership one from the other of the current data structure.[5] Shared locks are usually used while the database is reading data (during a SELECT operation). The number, nature of locks and time the lock holds a data block can have a huge impact on the database performances. Bad locking can lead to disastrous performance response (usually the result of poor SQL requests, or inadequate database physical structure)

The isolation level of the data server enforces default locking behavior. Changing the isolation level will affect how shared or exclusive locks must be set on the data for the entire database system. Default isolation is generally 1, where data can not be read while it is modified, forbidding the return of "ghost data" to end users.

At some point intensive or inappropriate exclusive locking can lead to a "deadlock" situation between two locks, where none of the locks can be released because they try to acquire resources mutually from each other. The database should have a fail-safe mechanism which will automatically "sacrifice" one of the locks, thus releasing the resource. Processes or transactions involved in the "deadlock" get rolled back.

Databases can also be locked for other reasons, like access restrictions for given levels of user. Some DBAs also lock databases for routine maintenance, which prevents changes being made during the maintenance. However, many modern databases don't lock the database during routine maintenance. e.g. "Routine Database Maintenance" for PostgreSQL.

30

4.8 Applications

Databases function in many applications, spanning virtually the entire range of computer software. Databases have become the preferred method of storage for large multi-user applications, where coordination between many users is needed. Even individual users find them convenient, and many electronic mail programs and personal organizers are based on standard database technology. Software database drivers are available for most database platforms so that application software can use a common API to retrieve the information stored in a database. Commonly used database APIs include JDBC and ODBC.

4.9 Databases in new media

Within new media, databases collect items on which the user can carry out various operations such as viewing, navigating, create, and searching. Though there are various types of items within the database, each item has the same significance. Unlike a narrative or film, the collections are computerized and therefore may offer a unique experience with each view. This form of data may present a unique presentation of what the world is like. Databases can be seen as a symbolic form of the computer age.

31

5. Factors That Impact Database

Performance

5.1 System Characteristics

Performance is influenced by characteristics of the system hosting the database server, for example:

• Disk input/output (I/O) speed. • Amount of memory available. • Processor speed. • Network bandwidth.

All of these factors have an impact on performance. For example, performance of a SQL statement depends upon whether or not a complete table can fit in memory, the time it takes to load the table into memory, the time it takes to process the data in memory, and the network bandwidth available for interaction between the user and the database server.

Disk I/O Speed

Database performance depends heavily on disk I/O speed. Disk accesses are very slow compared to memory operations. In addition to using faster disks, database performance can be improved by minimizing disk accesses. Also, once data is brought into memory (data buffer), keeping it there for future use as long as memory is available will reduce disk accesses there by speeding up query execution. The larger the data buffer, the more the data that can be kept in memory.

Disks are mechanical devices with moving parts which is slow electronic memory. The time to read/write data consists of three components in order of decreasing time consumption:

• Seek Time: Time taken by the disk head to move to the appropriate track. • Rotation Time: Time taken by the platter to rotate so that the appropriate block on

the track is under the disk head. • Transfer Time: Time to read or write the data block.

Optimizing Disk Accesses

• Database systems try to optimize disk access time by storing tables, indexes, and other database items to minimize seek and rotational times. Rows inserted into a table are stored contiguously in a block with other rows or in adjacent blocks, as appropriate. The execution time of a query, such as a SELECT statement without a WHERE clause, that needs to access a complete table will be minimized if the

32

table is stored in contiguous blocks. Data placement decisions are made by the database system and are hidden from the users.

• A disk block is the unit of disk I/O and storage. The size of the block can be explicitly specified by a database designer or a DBA, overriding the default size. A typical block size ranges from 2K to 16K bytes. The block size is specified when a database is created and typically cannot be altered once defined.

• Large disk block sizes increase the number of bytes transferred per expensive seek thus reducing number of seeks. But using large blocks for applications with updates involving several blocks will cause each update to take longer as it gets expensive to write larger blocks. The default block size should suffice for most applications. In case of databases with special needs, say for multimedia databases with large items, a larger block size may be beneficial to reduce the number of items spread over more than one disk block for storage.

• Disk seeks problem becomes more pronounced as data volumes starts to grow so large that effective caching becomes harder. For large databases with random data access, you will likely need at least one disk seek to read and a couple of disk seeks to write things. For database servers, employ disks with lower seek times.

• Increase the number of available disk spindles which reduces the seek overhead by either symlinking files to different disks or striping the disks.

Using Symbolic Links

You can move tables and databases from the database directory to other locations and replace them with symbolic links to the new locations. You might want to do this, for example, to move a database to a file system with more free space or increase the speed of your system by spreading your tables to different disk.

The recommended way to do this is simply to symlink databases to a different disk.

Striping

If an installation has several disks, Striping means putting the first block on the first disk, the second block on the second disk, and the N-th block on the (N MOD number_of_disks) disk, and so on.

If your average data size is less than or equal to the stripe size, performance for multiple reads will improve.

Striping may be suitable for some parallel disk-access systems such as RAID.

We can also tune the Operating System settings for the filesystem that the database is deployed under.

33

5.2 Memory

• If the needed data is in memory or data buffers, then disk accesses are not required saving time. If not, then disk blocks containing the data must be read from the disk into the data buffer. Larger data buffers increase the chance of finding the needed data in the buffer.

• If the data buffer is running out of space for new items, then some items in the buffer must be deleted. And if these memory blocks have been altered via updates, then they must be written to disk before removal.

To determine which items should be deleted, database systems use algorithms similar to those used in operating systems such as the least- recently-used (LRU) and the first-in-first-out (FIFO) algorithms and their variants. Note that the data buffer is conceptually similar to a cache in an operating system.

• The DBA has the primary responsibility of determining and specifying memory needs of a database system to ensure optimal performance. To tune performance, the DBA must determine and specify buffer sizes.

In MySQL, it is possible to configure the buffer sizes for:

• Indexes • Joins • Data • Sorting • Caching queries • Caching query results

Buffers for caching queries and their results are very useful in situations where the database does not change often and the same queries are executed repeatedly. This is typical for many web servers that serve dynamic pages using database content.

34

6. Examples of Databases

6.1 MySQL

MySQL is a relational database management system (RDBMS) that has more than 6 million installations. MySQL stands for "My Structured Query Language". The program runs as a server providing multi-user access to a number of databases.

The project has made its source code available under the terms of the GNU General Public License, as well as under a variety of proprietary agreements. MySQL is owned and sponsored by a single for-profit firm, the Swedish company MySQL AB, now a subsidiary of Microsystems As of 2009 Oracle Corporation began the process of acquiring Sun Microsystems.

MySQL is often used in free software projects that require a full-featured database management system, such as WordPress, phpBB and other software built on the LAMP software stack. It is also used in very high-scale World Wide Web products including Wikipedia, Google and Facebook

Uses

Many web applications use MySQL as the database component of a LAMP software stack. Its popularity for use with web applications is closely tied to the popularity of PHP, which is often combined with MySQL. Several high-traffic web sites (including Flickr, Facebook, WikipediaGoogle (though not for searches), Nokia Auction marts and YouTube) use MySQL for data storage and logging of user data.

Platforms and interfaces

The MySQL Administrator in LinuxMySQL code uses C and C++. The SQL parser uses yacc and a home-brewed lexer, sql_lex.cc.

MySQL works on many different system platforms, including AIX, BSDi, FreeBSD, HP-UX, i5/OS, Linux, Mac OS X, NetBSD, Novell NetWare, OpenBSD, OpenSolaris, eComStation, OS/2 Warp, QNX, IRIX, Solaris, Symbian, SunOS, SCO OpenServer, SCO UnixWare, Sanos, Tru64 and Microsoft Windows. A port of MySQL to OpenVMS also exists.

All major programming languages with language-specific APIs include Libraries for accessing MySQL databases. In addition, an ODBC interface called MyODBC allows additional programming languages that support the ODBC interface to communicate with a MySQL database, such as ASP or ColdFusion. The MySQL server and official libraries are mostly implemented in ANSI C/ANSI C++.

35

To administer MySQL databases one can use the included command-line tool

(commands: mysql and mysqladmin). Potential users may also download from the MySQL site: GUI administration tools: MySQL Administrator, MySQL Migration Toolkit and MySQL Query Browser. The GUI tools are now included in one package called MySQL GUI Tools.

In addition to the above-mentioned tools developed by MySQL AB, several other commercial and non-commercial tools integrate with MySQL. Examples include Navicat Free Lite Edition, AnySQL Maestro Freeware Edition or SQLyog Community Edition, they are free desktop based GUI tools, and phpMyAdmin, a free Web-based administration interface implemented in PHP.

6.2 MySQL Memory Usage

• All threads share the same base memory. When a thread is no longer needed, the memory allocated to it is released and returned to the system unless the thread goes back into the thread cache. In that case, the memory remains allocated.

• The key buffer is shared by all threads; its size is determined by the key_buffer_size variable

• Each thread that is used to manage client connections uses some thread-specific space. The following list indicates these and which variables control their size:

o A stack (default 192KB, variable thread_stack) o A connection buffer (variable net_buffer_length) o A result buffer (variable net_buffer_length)

The connection buffer and result buffer both begin with a size given by net_buffer_length but are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks to net_buffer_length after each SQL statement. While a statement is running, a copy of the current statement string is also allocated.

• Most requests that perform a sort allocate a sort buffer and also zero to two temporary files depending on the result set size.

• Each request that performs a sequential scan of a table allocates a read buffer defined by variable read_buffer_size.

• For each table having BLOB columns, if you scan a table, a buffer as large as the largest BLOB value is allocated.

• Some memory is allocated for query itself for column structures, parsing, calculating and queries.

• MySQL tests mysqld with several memory-leakage detectors to prevent memory leaks.

• All joins are executed in a single pass, and most joins can be done without even using a temporary table.

• In some cases, the server creates internal temporary tables while processing queries. A temporary table can be held in memory and processed by the

36

MEMORY storage engine, or stored on disk and processed by the MyISAM storage engine.

Processor Speed

Faster processors are always a good thing. Typically, disks are likely to be the cause of performance problems because of disk I/O is very slow compared to processor execution time. However, if there are multiple disks and I/O is being performed in parallel, then processors can be a bottleneck. In such cases, faster processors can help speed up response time and improve throughput.

Network Bandwidth

In a client-server architecture, one factor that can affect response time is available bandwidth. In case of intranets and broadband networks, network bandwidth is usually not an issue. However, even in such cases, transferring large amounts of data between the client and the database server can be time consuming and will adversely affect response time.

6.3 Tuning Server Parameters

You can determine the default buffer sizes used by the mysqld server using this command:

Code Sample: TuneMySQL/Demos/Show-Vars.bat mysqld --verbose --help

Code Explanation

This command produces a list of all mysqld options and configurable system variables. The output includes the default variable values

When tuning a MySQL server, the two foremost variables to configure are key_buffer_size and table_cache. You should set these appropriately before varying other variables.

The following examples indicate some typical variable values for different runtime configurations.

If you have at least 256MB of memory and many tables and want maximum performance with a moderate number of clients, you should use something like this:

shell> mysqld_safe --key_buffer_size=64M --table_cache=256 \ --sort_buffer_size=4M --read_buffer_size=1M &

If you have only 128MB of memory and only a few tables, but you still do a lot of sorting, you can use something like this:

37

shell> mysqld_safe --key_buffer_size=16M --sort_buffer_size=1M

If there are very many simultaneous connections, swapping problems may occur unless mysqld has been configured to use very little memory for each connection. mysqld performs better if you have enough memory for all connections.

With little memory and lots of connections, use something like this:

shell> mysqld_safe --key_buffer_size=512K --sort_buffer_size=100K \ --read_buffer_size=100K &

Or even this:

shell> mysqld_safe --key_buffer_size=512K --sort_buffer_size=16K \ --table_cache=32 --read_buffer_size=8K \ --net_buffer_length=1K &

For GROUP BY or ORDER BY operations on tables larger than available memory, you should increase the value of read_rnd_buffer_size to for faster reading of rows post-sorting.

6.4 MySQL Query Cache

• The query cache stores the text of a SELECT statement together with the corresponding result that was sent to the client. If an identical statement is received later, the server retrieves the results from the query cache rather than parsing and executing the statement again.

• The query cache is extremely useful in an environment where you have tables that do not change very often and for which the server receives many identical queries. This is a typical situation for many Web servers that generate many dynamic pages based on database content.

• The query cache does not return stale data. When tables are modified, any relevant entries in the query cache are flushed.

• The query cache does not work in an environment where you have multiple mysqld servers updating the same MyISAM tables.

• A query also is not cached under these conditions: o Server-side prepared statements, or sub-queries or Queries executed

within the body of a stored function or trigger. o user-defined functions (UDFs) or stored functions, user or internal

variables, uses explicit locking,uses TEMPORARY tables, generates warnings, or if The user has a column-level privilege for any of the involved tables.

o A query cannot be cached if it contains some of the system-info functions such as DATABASE() or LAST_INSERT_ID().

o Searches for a single row in a single-row table are 238% faster with the query cache than without it.

38

o To disable the query cache at server startup, set the query_cache_size system variable to 0.

o Incoming queries are compared to those in the query cache before parsing o Queries must be exactly the same (byte for byte) to be seen as identical. In

addition, query strings that are identical may be treated as different for other reasons. Queries that use different databases, different protocol versions, or different default character sets are considered different queries and are cached separately.

• the following two queries are regarded as different by the query cache: • SELECT * FROM film

Select * from film

• If a table changes, all cached queries that use the table become invalid and are removed from the cache.

• The query cache also works within transactions when using InnoDB tables. • Two query cache-related options may be specified in SELECT statements:

o SQL_CACHE: The query result is cached if it is cacheable and the value of the query_cache_type system variable is ON or DEMAND.

o SQL_NO_CACHE: The query result is not cached. o

Code Sample: TuneMySQL/Demos/Query-Cache-In-Select.sql SELECT SQL_CACHE customer_id, first_name, last_name FROM customer; SELECT SQL_NO_CACHE customer_id, first_name, last_name FROM customer;

Code Explanation

The first query is cached if cache is enabled or on DEMAND.

The second query is not cached at all.

Query Cache Parameters

By default, the query cache is not enabled. You can set up query caching on your system by using the following three system variables:

• query_cache_type: Specifies the operating mode of the query cache, values are explained below.

• query_cache_limit: Specifies the maximum size for a result set that can be cached. For example, if the limit is set to 2M, no result set larger than 2M will be cached. The default limit is 1M.

• query_cache_size: Specifies the amount of memory allocated for caching queries. By default, this variable is set to 0, which means that query caching is turned off. To implement query caching, you should specify a query_cache_size setting in the [mysqld] section of your option file.

39

As you can see, the only action that you need to take to implement query caching is to set the query_cache_size variable, which is set to 0 by default.

If the query cache size is greater than 0, the query_cache_type variable influences how it works. This variable can be set to the following values:

• 0 or OFF: Prevents caching or retrieval of cached results. • 1 or ON: Allows caching except of those statements that begin with SELECT

SQL_NO_CACHE. • 2 or DEMAND: Cache only those statements that begin with SELECT

SQL_CACHE.

Code Sample: TuneMySQL/Demos/set-Query-Cache-Type.sql SET SESSION query_cache_type = OFF; SET SESSION query_cache_type = 2;

Code Explanation

The first SET turns off query caching.

The second SET will cache only queries demanding caching via SQL_CACHE option.

You can defragment the query cache to better utilize its memory with:

Code Sample: TuneMySQL/Demos/Flush-Query-Cache.sql FLUSH QUERY CACHE;

Code Explanation

The statement does not remove any queries from the cache.

To remove all query results from the query cache:

Code Sample: TuneMySQL/Demos/Reset-Query-Cache.sql RESET QUERY CACHE;

Code Explanation

The FLUSH TABLES statement can also do the same thing.

To monitor query cache performance:

Code Sample: TuneMySQL/Demos/Show-Qcache.sql SHOW STATUS LIKE 'Qcache%';

Code Explanation

Descriptions of each of these variables can be found in MySQL documentation.

40

The system variables related to your query cache are not the only variables that can affect performance. There are other system variables related to your table and index cache, as well as other components of MySQL. Refer to the MySQL product documentation for more.

6.5 Oracle Database

Oracle Database (commonly referred to as Oracle RDBMS or simply Oracle) is a relational database management system (RDBMS) produced and marketed by Oracle Corporation. As of 2009, Oracle remains a major presence in database computing.

Physical and logical structures

An Oracle database system — identified by an alphanumeric system identifier or SID— comprises at least one instance of the application, along with data storage. An instance — identified persistently by an instantiation number (or activation id: SYS.V_$DATABASE.ACTIVATION#) — comprises a set of operating-system processes and memory-structures that interact with the storage. Typical processes include PMON (the process monitor) and SMON (the system monitor).

Users of the Oracle databases refer to the server-side memory-structure as the SGA (System Global Area). The SGA typically holds cache information such as data-buffers, SQL commands, and user information. In addition to storage, the database consists of online redo logs (or logs), which hold transactional history. Processes can in turn archive the online redo logs into archive logs (offline redo logs), which provide the basis (if necessary) for data recovery and for some forms of data replication.

If the Oracle database administrator has implemented Oracle RAC (Real Application Clusters), then multiple instances, usually on different servers, attach to a central storage array. This scenario offers advantages such as better performance, scalability and redundancy. However, support becomes more complex, and many sites do not use RAC. In version 10g, grid computing introduced shared resources where an instance can use (for example) CPU resources from another node (computer) in the grid.

The Oracle DBMS can store and execute stored procedures and functions within itself. PL/SQL (Oracle Corporation's proprietary procedural extension to SQL), or the object-oriented language Java can invoke such code objects and/or provide the programming structures for writing them.

Storage

The Oracle RDBMS stores data logically in the form of tablespaces and physically in the form of data files. Tablespaces can contain various types of memory segments, such as Data Segments, Index Segments, etc. Segments in turn comprise one or more extents.

41

Extents comprise groups of contiguous data blocks. Data blocks form the basic units of data storage.

Oracle database management tracks its computer data storage with the help of

information stored in the SYSTEM tablespace. The SYSTEM tablespace contains the data dictionary — and often (by default) indexes and clusters. A data dictionary consists of a special collection of tables that contains information about all user-objects in the database. Since version 8i, the Oracle RDBMS also supports "locally managed" tablespaces which can store space management information in bitmaps in their own

headers rather than in the SYSTEM tablespace (as happens with the default "dictionary-managed" tablespaces).

42

Part II

Introduction of the Java Performance

Issue

The issue of the performance is quite obvious and vivid in Java application development. The case with Java is completely different from that of the C or CPP programming Language. Answer of relatively low performance of Java compared with C lies at the architecture design of Java Runtime Environment. The java run time system requires the Java Virtual Machine. It takes the complied code away from the underlying hardware. Thus the overheads increase resulting issue of high execution time. The case is similar just as C programming is slower than the assembly level programming. More over the Java complier is relatively newer than the C compiler so it is relatively less optimized and bug free and it is still in the improvement stage. Java provides a good environment in terms of platform-independence, memory management, powerful exception checking, built-in multithreading, dynamic resource loading, and security checks. JVM add extra costs in terms of an interpreter, garbage collector, thread monitors, repeated disk and network accessing, and extra runtime checks. These facilities provide the developer a good environment to write enterprise level application. The development of the enterprise level application in the Java has also has enhanced the expectation and requirement of the client. The issue of the relatively faster (in terms of the execution time) is usual demand of the client. It is necessary to test the application from every front to enhance its performance. This document gives the information about the performance testing and tuning practices of J2EE web application. It describes the load testing, stress testing and profiling techniques in detail.

43

7. Software Performance Testing

7.1 Introduction

In software engineering, performance testing is testing that is performed, from one perspective, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance testing is a subset of Performance engineering, an emerging computer science practice which strives to build performance into the design and architecture of a system, prior to the onset of actual coding effort. Following can be Motives behind the testing

• Demonstrate that the system meets performance criteria.

Before dispatching the final product to the customer, it is necessary to verify every issue related to the functional behavior and the system behavior like:

1. How much time it is taking to process the request 2. What is the memory requirement 3. How many users it can serve simultaneously 4. And what would be performance at different system configuration

• Compare two systems to find which performs better.

1. In this case we can compare between two releases in home production. 2. This provides the comparative data to prefer one application over

another in the market.

• Measure what parts of the system or workload cause the system to perform badly.

In this type of analyses we profile the code for the execution time and memory consumption. 1. It helps us to figure out the portion of the code that is taking more time to

execute and has enhanced the total time. 2. It helps us to figure out the portion that is consuming the memory usage and

increasing weight on the system. 3. This information provides a great help for the developer to improve the

application performance.

44

7.2Performance Checklist

• Specify the required performance.

1. Ensure performance objectives are clear. 2. Specify target response times for as much of the system as possible. 3. Specify all variations in benchmarks, including expected response ranges

(e.g., 80% of responses for X must fall within 3 seconds). 4. Include benchmarks for the full range of scaling expected (e.g., low to high

numbers of users, data, files, file sizes, objects, etc.). 5. Specify and use a benchmark suite based on real user behavior. This is

particularly important for multi-user benchmarks. 6. Agree on all target times with users, customers, managers, etc., before tuning.

• Make your benchmarks long enough: over five seconds is a good target.

1. Use elapsed time (wall-clock time) for the primary time measurements. 2. Ensure the benchmark harness does not interfere with the performance of the

application. 3. Run benchmarks before starting tuning, and again after each tuning exercise. 4. Take care that you are not measuring artificial situations, such as full caches

containing exactly the data needed for the test

• Break down distributed application measurements into components, transfer layers, and network transfer times.

• Tune systematically: understand what affects the performance; define targets; tune; monitor and redefine targets when necessary.

1. Approach tuning scientifically: measure performance; identify bottlenecks; hypothesize on causes; test hypothesis; make changes; measure improved performance.

2. Determine which resources are limiting performance: CPU, memory, or I/O. 3. Accurately identify the causes of the performance problems before trying to

tune them. 4. Use the strategy of identifying the main bottlenecks, fixing the easiest, then

repeating. 5. Don't tune what does not need tuning. Avoid "fixing" non bottlenecked parts

of the application. 6. Measure that the tuning exercise has improved speed.

45

7. Target one bottleneck at a time. The application running characteristics can change after each alteration.

8. Improve a CPU limitation with faster code and better algorithms, and fewer short lived objects.

9. Improve a system-memory limitation by using fewer objects or smaller long-lived Objects. 10. Improve I/O limitations by targeted redesigns or speeding up I/O, perhaps by Multithreading the I/O.

• Work with user expectations to provide the appearance of better performance

1. Hold back releasing tuning improvements until there is at least a 20% improvement in response times.

2. Avoid giving users a false expectation that a task will be finished sooner than it will.

3. Reduce the variation in response times. Bear in mind that users perceive the mean response time as the actual 90th percentile value of the response times.

4. Keep the user interface responsive at all times. 5. Aim to always give user feedback. The interface should not be dead for more

than two seconds when carrying out tasks. 6. Provide the ability to abort or carry on alternative tasks. 7. Provide user-selectable tuning parameters where this makes sense. 8. Use threads to separate out potentially blocking functions. 9. Calculate "look-ahead" possibilities while the user response is awaited. 10. Provide partial data for viewing as soon as possible, without waiting for all

requested data to be received. 11. Cache locally items that may be looked at again or recalculated.

7.3 Performance Testing Methods

• Load • Stress • Endurance • Spike • Scalability

Load Testing

This is the simplest form of performance testing. A load test is usually conducted to understand the behavior of the application under a specific expected load. This load can be the expected concurrent number of users on the application performing a specific

46

number of transactions within the set duration. This test will give out the response times of all the important business critical transactions. If the database, application server, etc are also monitored, then this simple test can itself point towards the bottleneck in the application.

Stress Testing

This testing is normally used to break the application. Double number of users is added to the application and the test is run again until the application breaks down. This kind of test is done to determine the application's robustness in times of extreme load and helps application administrators to determine if the application will perform sufficiently if the current load goes well above the expected load.

Endurance Testing

This test is usually done to determine if the application can sustain the continuous expected load. During endurance tests, memory utilization is monitored to detect potential leaks. Also important, but often overlooked is performance degradation. That is, to ensure that the throughput and/or response times after some long period of sustained activity are as good as or better than at the beginning of the test.

Scalability Testing

Scalability testing is an extension of performance testing - it's part of the battery of non-functional tests, is the testing of a software application for measuring its capability to scale up or scale out in terms of any of its non-functional capability - be it the user load supported, the number of transactions, the data volume etc. The purpose of scalability testing is to identify major workloads and mitigate bottlenecks that can impede the scalability of the application.

Profiling

Measurements and Timings:

In order to measure the time taken by the method of a class, timing profiling is done. There are several commercial and open source tools available. These tools increase the overhead on the JVM. Thus they can result to the slowing of the execution. By means of attaching System.currentTimeMillis( ) the measuring of the time can be done with the precision. But this technique becomes tedious for the large application. In this case we are left with no option but to use readymade profiler. In further section the usages of the jip Profiler has been shown to address the timing issue.

47

Monitoring Gross Memory Usage

This technique is employed to observe the memory usage of different section of the code. The best is the use of totalMemory( ) that returns a long, which is the number of bytes currently allocated to the runtime system for this particular Java VM process. Within this memory allocation, the VM manages its objects and data. Some of this allocated memory is held in reserve for creating new objects. When the currently allocated memory gets filled and the garbage collector cannot allocate sufficiently more memory, the VM requests more memory to be allocated to it from the underlying system. If the underlying system cannot allocate any further memory, an OutOfMemoryError error is thrown. Total memory can go up and down; some Java runtimes can return sections of unused memory to the underlying system while still running.

In further section the use of eclipse memory profiler has been demonstrate

7.4 Load Testing by Apache Jmeter

Apache JMeter is a 100% pure Java desktop application designed to load test client/server software (such as a web application). It may be used to test performance both on static and dynamic resources such as static files, Java Servlets, CGI scripts, Java objects, databases, FTP servers, and more. JMeter can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types.

Input

The important and difficult issue with the Web Application load-testing is identifying the scenario, set up the benchmark. When these criteria have been defined the test has to be engineered. The following are useful inputs for load-testing a Web application:

• Performance-critical usage scenarios

• Workload models

• Performance acceptance criteria

• Performance metrics associated with the acceptance criteria

• Interview feedback from the designer or developer of the Web application

• Interview feedback from end users of the application

• Interview feedback from the operations personnel who will maintain and manage the application

Output The main outcomes that load testing helps you to accomplish are:

48

• Updated test plans and test designs for load and performance testing

• Various performance measures such as throughput, response time, and resource utilization

• Potential bottlenecks that need to be analyzed in the white-box testing phase

• The behavior of the application at various load level. http://msdn.microsoft.com/en-us/library/bb924372.aspx

Test Engineering Process

The overall process of setting up a script is:

1. Record a script. 2. Edit the script to remove hard-coded values. 3. Add assertions to validate that the test is getting the expected results. 4. Test the basic script. 5. Enhance the script with logic, randomness, etc. 6. Run the script, analyze the results, tune the application, and repeat. Once created and tested, scripts can be saved, shared, and reused. Pieces of scripts can be used in other scripts, and multiple scripts can be merged into a single test plan.

Pic 2.1 a load test script in Jmeter tool

49

Pic 2.2

Pic 2.2 shows the 1. Test Plan 2. Thread Group 3. View Results in Table 4. Graph Result 5. Workbench

The role of Workbench is to record the test to load test it. When test is recorded appears like Pic 2.2under the node Test Plan and Thread Group .

Thread Group defined the criteria related to test 1. Number of Thread or Virtual User 2. The Ramp up time 3. Loop Count

These help us to create the client-side like scenario and hence increase the load on the server. If this test is performed with a purpose to see how much load server can take the test is called Stress testing.

50

It has several other features like timer to set the waiting time of the whole test or for each web page. Http Request Defaults helps to set the default data for each Http Request(Sampler).

Pic 2.3 options available in the tool after test has been done

The load testing has the most difficult part of setting the parameter with each Http Request. Jmeter provides different features for that. Mainly focus over these.

1. CSV Data Set Configuration. 2. Random Variable 3. User Defined Variables 4. Counter 5. Regular Expression Extractor

51

Finally for the result display it has several listeners.

Pic 2.4 result display in JMeter

Mainly focus over these 1. View Results in Tree 2. View Result in Table 3. Graph Result. This helps in obtaining Following

• Response time. For example, the product catalog must be displayed in less than 3 seconds.

• Throughput. For example, the system must support 100 transactions per second. • Resource utilization. A frequently overlooked aspect is the amount of resources

your application is consuming, in terms of processor, memory, disk input output (I/O), and network I/O.

• Maximum user load. This test objective determines how many users can run on a specific hardware configuration.

• Byte Transferred: For knowing the size of the data transferred to the client

browser with each HTTP Response.

52

8 Java memory management

8.1 Memory Leaks and Method to prevent them In any language, application-level memory management problems revolve around the deallocation of memory. These problems fall into two categories: premature deallocation (corrupted pointers) and incomplete deallocation (memory leaks). In the case of incomplete deallocation, there are two subcases: coding bugs and design bugs. Coding bugs are language dependent. In the case of C, this would involve free()ing less than was malloc()ed, while in C++ this might involve using delete in lieu of delete[]. Design bugs, on the other hand, do not depend on the language; instead, they involve simple programmer negligence. In languages like C/C++, all memory management is handled by the programmer, so all of these problems can arise, even after the programmer has expended much effort to ensure the code is free of such defects. In fact, in C/C++ the more we try to avoid memory leaks, the more likely we are to create corrupted pointers, and vice versa. And, by nature the risk of such bugs increases with code size and complexity, so it's difficult to protect large C/C++ applications from these types of bugs.

In Java, on the other hand, the Java language and runtime together entirely eliminate the problems of corrupted pointers and code-level memory leaks. Here's how:

• In Java, memory is allocated only to objects. There is no explicit allocation of memory, there is only the creation of new objects. (Java even treats array types as objects.)

• The Java runtime employs a garbage collector that reclaims the memory occupied by an object once it determines that object is no longer accessible. This automatic process makes it safe to throw away unneeded object references because the garbage collector does not collect the object if it is still needed elsewhere. Therefore, in Java the act of letting go of unneeded references never runs the risk of deallocating memory prematurely.

• In Java, it's easy to let go of an entire "tree" of objects by setting the reference to

the tree's root to null; the garbage collector will then reclaim all the objects (unless some of the objects are needed elsewhere). This is a lot easier than coding each of the objects' destructors to let go of its own dependencies (which is a coding-level problem with C++).

53

So what about memory leaks caused by poor program design? In such designs, unnecessary object references originating in long-lived parts of the system prevent the garbage collector from reclaiming objects that are in fact no longer needed. Such errors typically involve a failure "in the large" to properly encapsulate object references among various parts of the code. Another design flaw occurs "in the small," at the level of a faulty algorithm; the use of Collections objects in such cases will typically magnify the error. As the technology improves, a suitably implemented JVM could help reduce the effects of such designed-in memory leaks by using the garbage collector to track object usage over time. The garbage collector could then rearrange objects in memory according to a freshness factor based on when they were last referenced, for example. Stale objects would become eligible for physical RAM swap-out (even though, for safety, they would still exist). Ideally of course, programmers would design applications with objects' lifecycles in mind, rather than rely on clever features of state-of-the-art JVM implementations. In conclusion: Design problems can be mitigated by letting go of object references in one's own classes as soon as one can (knowing that in Java there is no risk of damaging another part of the code).

So let us now take a closer look at Java memory problems. Problems can be categorized into four: groups

• Memory leaks in Java are created by referencing objects that are no longer used. This easily happens when multiple references to objects exist and developer forget to clear them, when the object is no longer needed.

• Unnecessarily high memory usage caused by implementations consuming to much memory. This is very often a problem in web applications where a large amount of state information is managed for “user comfort”. When the number of active users increases, memory limits are reached very fast. Unbound or inefficiently configured caches are another source of constant high memory usage.

• Inefficient object creation easily results in a performance problem when user load increases, as the garbage collector must constantly clean up the heap. This leads to unnecessarily high CPU consumption by the garbage collector. As the CPU is blocked by garbage collection, application response times increases often already under moderate load. This behaviour is also referred to as GC trashing.

• Inefficient garbage collector behaviour is caused by missing or wrong configuration of the garbage collector. The garbage collector will take care that object are cleaned up. How and when this should happen must however by configured by the programmer or system architect. Very often people simple “forget” to properly configure and tune the garbage collecotr. I was involved in a number of performance workshops where a “simple” parameter change resulted in a performance improvement of up to 25 percent.

54

In most cases memory problems affect not only performance but also scalability. The higher the amount of consumed memory per request, user or session the less parallel transactions can be executed. In some cases memory problems also affect availabilty. When the JVM runs out of memory or it is close to memory limits it will quit with an OutOfMemory error. This is when management enters and let us know that we are in serious trouble.

Beside these I would present a couple of memory antipatterns which are often found in real world world applications. Those patterns should help to be able to already avoid memory problems during development.

HTTP Session as Cache

This antipattern refers to the misuse of the HTTPSession object as a data cache. The session object serves as means to store information which should “survive” a single HTTP request. This is also referred to a as conversational state. Meaning data is stored over a couple of requests until it is finally processed. This approach can be found in any non-trivial web application. Web applications have no other means than storing this information on the server. Well, some information can be put into the cookie, but this has a number of other implications.

It is important to keep as few data as possible and as short as possible. It can easily happen that the session contains megabytes of object data. This immediately results in high heap usage and memory shortages. At the same time the number of parallel users is very limited. The JVM will respond to an increasing number of users with an OutOfMemoryError. Large user sessions have other performance penalties as well. In case of session replication in clusters increased serialization and communication effort will result in additional performance and scalability problems.

Session caching problems often arise because the application architecture has not been clearly defined. During development data is simply put into the session as it is comfortable. This very often happens in an “add and forget” manner, as nobody ensures that this data is removed when no longer needed. Normally unneeded session data should be handled by the session timeout. In enterprise applications which are constantly under heavy use the session timeout, this will not work. Additionally very often very high session timeouts are used – up to 24 hours – to provide additional “comfort” to users so that they do not have to login again.

A practical example is putting selection choices from list, which have to be fetched from the database, in the session. The intention is to avoid unnecessary database queries. (Smells like premature optimization – doesn’t it). This results in several kilobytes being put into the session object for every single user. While it is reasonable to cache this information the user session is definitely the wrong place for it.

Another example is abusing the Hibernate session for managing conversational state. The Hibernate session object is simply put into the HTTP session to be have fast access to

55

data. This however results in much more data to be stored as necessary and the memory consumption per users rises significantly.

In modern AJAX applicatoins conversational state can also be managed at the client side. Ideally this leads to a stateless or nearly stateless server application which also scales signifcantly better.

ThreadLocal Memory Leak

ThreadLocal variables are used in Java to bind variables to a specific thread. This means every thread gets it’s own single instance. This approach is used to handle status information within a thread. An example would be user credentials. The lifecycle of a ThreadLocal variable is however related to the lifecycle of the thread. ThreadLocal variables are cleaned up when the thread is terminated and removed by the garbage collector – if not explicitly removed by the programmer.

Forgotten ThreadLocal variables can especially in application servers easily result in memory problems. Application servers uses ThreadPools in avoid constant creation and destruction of threads. An HTTPServletRequest for example gets a free thread assigned at runtime, which is passed back to the ThreadPool after execution. If the application logic uses ThreadLocal variables and forget to explicitly remove them, the memory will not be freed up.

Depending on the pool size – in production systems this can be several hundred threads – and the size of the objects reference by the ThreadLocal variable this can lead to problems. A pool of 200 threads and a ThreadLocal size of 5MB will in the worst case lead to 1 GB of unnecessarily occupied memory. This will immediately result in high GC activity leading to bad response times and potentially to an OutOfMemoryError.

Large Temporary Objects

Large temporary objects can in the worst case also lead to OutOfMemoryErrors or at least to high GC activity. This will for example happen if very big documents (XML, PDF, images, …) have to be read and processed. In a specific case the application was not responsive for a couple of minutes or performance was so limited that it was not practically usable. The root cause was the garbage collection going crazy. A detailed analysis lead down to the following code for reading a PDF document.

byte tmpData[] = new byte [1024]; int offs = 0; do{ int readLen = bis.read (tmpData, offs, tmpData.length - offs); if (readLen == -1) break; offs+= readLen; if (oofs == tmpData.length){ byte newres[] = new byte[tmpData.length + 1024]; System.arraycopy(tmpData, 0, newres, 0, tmpData.length);

56

tmpData = newres; } } while (true);

The documents which have been read using the method had a size of several megabytes. They were read into the bytearray and then send to the user’s browser. Several parallel requests rapidly led to a full heap. The problem got even worse due to highly inefficient algorithm for reading the document. The idea is that an initial byte array of one KB is created. If this array is full a new array which is 1 KB large is created and the old array is copied into the new one. This means when reading the document a new array is created and copied for each KB read. This results in a huge number of temporary objects and a memory consumption which is two times the size of the actual amount of data – as the data is permantently copied.

When working with large amounts of data, optimization of the processing logical is crucial to performance. In this case a simple load test would have shown the problem.

Bad Garbage Collector Configuration

In the scenarios presented so far the problem was caused by the application code. In a lot of cause the root cause however is wrong – or missing – configuration of the garbage collector. I frequently see people trusting the default settings of their application servers and believing these application server guys know best what is ideal for their application. The configuration of the heap however strongly depends on the application and the actual usage scenario. Depending on the scenario parameters have to adopted to get a well performing application. An application processing a high number of short lasting requests has to be configured completely different than a batch application, which is execution long lasting tasks. The actual configuration additionally also depends from the used JVM. What works fine for Sun JVM might be a nightmare for IBM (or at least not ideal).

Misconfigured garbage collectors are often not immediately identified as the root cause of a performance problem (unless you monitor Garbage Collector acitvity anyway). Often the visual manifestation of problems are bad response times. Understand the relation of garbage collector activity to response times is not obivous. If garbage collector times cannot be correlated to response times, people find themselves hunting a very complex performance problem. Response times and execution time metric problems will manifest across the applications – at different places without an obvious pattern behind this phenomenon.

ClassLoader Leaks

When talking about memory leaks most people primarily think about objects on the heap. Besides objects, classes and constants are also managed on the heap. Depending on the JVM they are put into specific areas of the heap. The Sun JVM for example uses the so called permanent generation or PermGen. Classes very often are put on the heap several times. Simply because they have been loaded by different classloaders. The memory

57

occupation of loaded classes can be up to several hundret MB in modern enterprise applications.

Key is to avoid unecessarily increasing the size of classes. A good sample is the definition of large amount of String constants – for example in GUI applications. Here all texts are often stored in constants. While the approach of using constants for Strings is in principle a good design approach, the memory consumption should not be neglected. In a real world case all constants where define in one class per language in an internationalized application. A not obviously visibile coding error resulted in all of this classed being loaded. The result was a JVM crash with an OutOfMemoryError in the PermGen of the application.

Application servers suffer additional problems with classloader leaks. These leaks are causes as classloaders cannot be garbage collected because an object of one of the classes of this classloader is still alive. As a result memory occupied by these classes will not be freed up. While this problem today is handled well by J EE application server, it seems to appear more often in OSGI-based application environments.

In the following sections we will discuss different tool to figure out these memory problems.

58

8.2 Code Profiling using Java Interactive Profiler

Performance Timings.

JIP gathers performance data of the Web Application. The utility like hprof too profile the code but the analysis becomes the difficult task. On the other hand, jip actually tracks the amount of time used to gather performance data and factors that time out of its analysis. This allows us to get close to real world timings for every class in our code. So

there is no need to litter code with System.currentTimeMillis().

Pic 2.5 time analysis of performance test data

59

Pic 2.6 analysis of the methods used in the load test

Here one can find that the access$00 and getNextRunnable() is called most of the number of times. Hence for back tracing these methods we can find out the final method and the class that is calling these functions and hence creating the timing issue for the application. In this way the jip profiler helps to detect the problem of the high execution timing. Detail of the tool can be obtained from http://jiprof.sourceforge.ne

8.3 Heapdump Analysys using Eclipse Memory

Analyzer

It is handled by Garbage Collector in Java. But sometimes if there is java.lang.OutOfMemoryError Exception, memory leak is certainly strong suspect. If any application eats more & more system memory and never seems to return memory back to the system until large amount of physical memory allocation to that application then this is the sign of memory leak. Also there is a common problem when we register a class as an event listener without bothering to free when the class is no longer needed. Some Memory debugging programs can come in handy when we're trying to detect memory leaks. These are better that task manager. We can prevent memory leaks by watching for some common problems. Collection classes, such as hash tables and vectors, are common places to find the cause of a memory leak. This is particularly true if the class has been declared static and exists for the life of the application. and many times member variables of a class that point to other classes simply need to be set to null at the appropriate time.These Memory leak can found out by Heap Dump Analysis. Eclipse Memory Analyzer . It produces the report and also provides different useful utilities to analyzing it.

60

Pic 2.7 Eclipse memory Analyzer tool

Pic 2.8 classes used and heap analysis

Here we can find out what the classes that is consuming the major chunk of memory. Finally back tracing from it we can find out about the memory bottle necks. Hence it

61

helps us to detect the crux of the problem. This information helps the developer to improve the code and reduce the memory usage in a well directed way. Mainly the classes of the Java Collection frame work create the memory leakage so the use of these classes should be done carefully.

62

9. Load Testing by AppPerfect

AppPerfect Load Test is a fully Automated Load test, Stress test and Performance Test

solution that is easy to use and cost effective. Most application performance and stability issues arise only when the server is stressed with a high user load. AppPerfect Web Load Test helps us design and simulate thousands of users in a realistic manner which can be used to load test our application infrastructure for performance, reliability and scalability.

AppPerfect Load Test is designed to answer vital questions such as:

• The number of concurrent users/requests application can support? • Is current infrastructure sufficient to meet user demand? • Will application scale as more users access it? • How does application's response time change as number of users increase? • Does Web application perform the same after 96 hours of deployment as it did

after 4 hours?

AppPerfect Load Test can help user identify a variety of problems before going into production:

• Software design issues (incorrect concurrency/pooling mechanism, poor optimization, memory build-up, etc.)

• Server configuration issues (Web server, application server, database server, load balancer, etc.)

• Hardware limitation issues (Excessive disk I/O, CPU maximization, memory limitations, network bottleneck, etc.)

AppPerfect Load Test is easy to use with no programming required. It provides a unique view of the target machine with integrated load testing, stress testing and performance testing parameters such as response time and hit count along with monitoring of system resources such as CPU, disk, network and memory.

63

A load test run in AppPerfect

64

AppPerfect Load Test Screenshots

Project Properties - Run Settings: Start project by defining appropriate Run Settings. Load Test provides extensive customization of wer project run behavior.

Project Properties - Machine Settings: Here we can configure various remote machines where we need to run the project or need to monitor the system resources.

Project Properties - Other Settings: Here we can configure additional general settings for wer test run.

Project Properties - Advanced Settings: Here we can configure settings related to Browser Simulation, Network Bandwidth and IP Spoofing.

Test Editor - Project: All actions we perform are recorded and can be viewed and modified using the Test Editor. This view shows the top-level project data.

Test Editor - Group: Click on any node on the tree on left to view details about that node. We can group a set of actions in to Groups that can be managed individually.

65

Test Editor - Task: Each action that is records is called a task. Click on any task node on the tree on left to view details about that task.

Test Editor - Validations: We can validate responses of each Task during test run. Validation can be defined using this view.

Test Editor - Parameters: We can replace recorded values with dynamically created values using the Parameters sheet. Dynamic values can come from a database, a manually specified list of values, or a CSV file.

Script Editor: While most features are available through the GUI, for times when added logic is needed, Load test provides an easy-to-understand scripting language. The Script Editor can be used to code the scripts.

Test Replay Status View - Project: When a test is replayed we can see total hits and response time charts here. In addition, this Status view in Load test also provides additional information about the test replay settings.

Test Replay Status View - Virtual Users: Here we can see Virtual User-wise hit and a Response time detail as test is being replayed.

66

Test Replay Status View - Task: Here we can see Task wise hit and Response time details as test is being replayed.

Test Replay Status View - Server Monitor: In case we have defined to monitor system resources of target machine then we can view the details for same in this view.

Verify Test in browser: We can also execute the test in browser and verify the responses received.

Results View - Project: Once our test is completely replayed, the Results are automatically displayed in the Project Summary view in the Results tab.

Results View - Virtual Users: Here we can see Virtual User-wise hits and Response time details

Results View - Task: Detailed Results of a test replay can be viewed for each task by clicking on that task. These details are necessary when diagnosing failed tasks.

67

Results View - Failed Task Details : In case task fails then we can view its complete details here.

Results View - Server Monitoring: In case we have defined to monitor system resources of target machine then we can view the details for same in this view.

Results - In HTML: All results can be exported in various file formats such as HTML, PDF, XML, etc. Here the results are exported in HTML.

68

10. Conclusions and Recommendations

There can be several reasons for the low performance of the application. Sometimes it is because of the poor configuration of the Application Server and JVM. Sometimes the code has been written inefficiently. Sometimes in the code usage of the classes and object has been done carelessly. Sometimes though application code is efficient but Http data size is large, so the Web Application does not perform as per expectation at the web browser. During the testing of the application the person should not make any presumption but should be open minded. The crux of the problem can be reached with the set procedure of analyzing the data obtained by the load testing. Then making that data basis we should do the code profiling or memory profiling based on the need of the situation. Moreover we should also focus over the log files of the corresponding application server and database server. Sometimes the database queries create the bottleneck and slow the application. In this case the database queries should be analyzed for its efficiency. There are many open source tool available for the obtaining the data. A lot of dependencies on them can overburden the JVM too. This can too manipulate the result to some extent. Hence for the better result the data obtaining work should be done step wise. In this report more attention has been paid over the performance improvement at the server side. It constitutes the major chuck of the performance issue. Further we shall try to introduce the code improvement at the client side. So that we can have more information about how the application is behaving at the client side. It will involve the profiling of the JavaScript code and the profiling of the User Interface. Here ways has been shown to address the Memory leak problem. we also worked to solve the permanent generation memory problem. In fact it is memory space that behaves as the class loader of the JVM. It is also an issue of the Memory Leak problem but little

different form the heap Memory Leak Issue.

Performance and load testing allows us to pinpoint system bottlenecks. To conduct performance and load testing we need to engage in a carefully controlled process of business transactions measurement and analysis. The main purpose behind this approach is defining the limit of system failure and evaluates how the system reacts to failure. Performance and load testing demands a controlled environment and repeatable measurements.

Load testing activities are composed by six different steps. We start to plan and design our load test cases according to our performance requirements. Create virtual user scripts that simulate human user interaction with the system under test. Virtual users emulate human users interacting with the application under test. A virtual user script contains the actions that each user performs during the load test procedure execution. Create load procedures specifying the load test cases, virtual user number and load agents. A load test

69

procedure includes a list of load test cases that will be executed from specified machines simulating a predefined number of virtual users. Execute load test procedures, monitor their execution and finally analyze the execution results. Tune the system under test if necessary and repeat executions until performance time reach performance requirements. The load is emulated during the load test procedure execution by instructing multiple virtual users to perform tasks simultaneously. Before executing the load test procedure you must determine how the virtual users will behave during the simulation. While executing a load test procedure you can monitor transactions performance times, errors, and machines performance counters, like operating systems, databases, web servers and application components . Successfully load testing requires us to develop a thorough test plan. A clearly defined test plan will ensure that all load test procedures that we develop will accomplish our load test objectives. Design our load test cases by defining transactions to simulate, performance response times, hits per second, acceptable error levels and expected number of concurrent users according to our performance requirements. We start to define and manage load test cases providing all the information needed. Here we can trace our load test cases from your performance requirements

In choosing a right tool for the load test, we should select the one which measures, monitors and analyze system performance and guarantees that the most current data is available to the people who need it, whenever they need By an efficient and successful load test we can determine the no of concurrent users can access your software system, amount of data can be loaded without performance degradation system's throughput requirements and how often are these requirements tested. We can also specify and validate that these load and performance requirements are being met at least once a day by running load tests as part of a scheduled and automated build, and more quickly determine how our system performs under certain load conditions and quickly adapt to changes.

70

II. Appendices

Load Testing: Elapsed time: JMeter measures the elapsed time from just before sending the request to just after the last response has been received. JMeter does not include the time needed to render the response, nor does JMeter process any client code, for example Javascript.

Latency: JMeter measures the latency from just before sending the request to just after the first response has been received. Thus the time includes all the processing needed to assemble the request as well as assembling the first part of the response, which in general will be longer than one byte. Protocol analyzers (such as Wireshark) measure the time when bytes are actually sent/received over the interface. The JMeter time should be closer to that which is experienced by a browser or other application client.

Median: Number which divides the samples into two equal halves. Half of the samples are smaller than the median, and half are larger. [Some samples may equal the median.] This is a standard statistical measure. See, for example: Median entry at Wikipedia. The Median is the same as the 50th Percentile

Standard Deviation: It is a measure of the variability of a data set. This is a standard statistical measure. See, for example: Standard Deviation entry at Wikipedia.

The Thread Name Thread Name as it appears in Listeners and log files is derived from the Thread Group name and the thread within the group. The name has the format

groupName + " " + groupIndex + "-" + threadIndex where: * groupName - name of the Thread Group element * groupIndex - number of the Thread Group in the Test Plan, starting from 1 * threadIndex - number of the thread within the Thread Group, starting from 1 A test plan with two Thread Groups each with two threads would use the names:

71

Thread Group 1-1 Thread Group 1-2 Thread Group 2-1 Thread Group 2-2 Throughput is calculated as requests/unit of time. The time is calculated from the start of the first sample to the end of the last sample. This includes any intervals between samples, as it is supposed to represent the load on the server.

The formula is:

Throughput = (number of requests) / (total time).

72

III. References

Websites: http://www.reflexisinc.com http://jakarta.apache.org/jmeter/usermanual/intro.html

http://msdn.microsoft.com/en-us/library/bb924372.aspx http://jiprof.sourceforge.net/ http://en.wikipedia.org/wiki/Web_application_testing http://en.wikipedia.org/wiki/Software_performance_testing http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://en.wikipedia.org/wiki/GlassFish http://en.wikipedia.org/wiki/Apache_Tomcat http://www.appperfect.com/products/load-test.html http://en.wikipedia.org/wiki/Database http://en.wikipedia.org/wiki/Application_server http://jakarta.apache.org/jmeter/usermanual/intro.html http://www.atyoursideconsulting.com/docs/Qualitymate_for_LoadTesting.pdf

Books:

1. Haines, Steven “Pro Java EE 5 Performance Management and Optimization”, 1st edition, Apress Publications, USA, 2006 . 2. Shirazi, Jack “Java Performance Tuning”, 2nd edition, Oreilly Publications, USA, 2002. 3. Schildt, Herbert “Java 2: The Complete reference”, 5th edition, Tata McGraw Hill publications, USA, 2008.

73

IV. Glossary

1. Java Runtime Environment: JRE provides the java classes and object the necessary resources for the running of the Java application.

2. Java Virtual Machine: Java programs are complied into the byte code then Java

Virtual Machine provides its framework for the application to run.

3. Platform-independence: The Application can be executed on any operating system.

4. Memory management: This is feature of allocating Heap, Stack and permanent

generation Memory to the class and object and freeing it at regular interval through garbage collection.

5. Multithreading: This kind of application has more than one thread to perform

different application. 6. Dynamic resource loading: The resources are acquired with the requirement and

freed it too with time.

7. Performance testing: The practice of testing , analyzing and validating the application for its performance in terms of resource.

8. Execution time: It is time taken for the Web Server to process the Http Request.

9. Load Testing: Process of creating the certain amount of load and analyzing the

performance of Web Application at that load. 10. Stress Testing: Process of gradually increasing the load on the server till it breaks

down. 11. Memory profiling: Practice of obtaining the data about the memory requirement

of different part of the code

12. Time Profiling: Practice of obtaining the data about the time requirement of different part of the code