What do you get with Print?

Instant access to your digital copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Redeem a companion digital copy on all Print orders

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

WildFly Performance Tuning

Chapter 1. The Science of Performance Tuning

There are many definitions of science. However, the most common definition is the systematic gathering and organization of knowledge. This refers to knowledge that, apart from its original purpose, can be used for further explorations of even more, and possibly further detailed, knowledge. Gaining new knowledge often involves validating theorems or ideas through experiments and tests. When a test has been validated or falsified, some things can be changed, or tuned, and the test can be performed again in order to gather more knowledge about what is going on in certain environments or situations.

As we will see, this approach of searching for knowledge in science is directly transferable to the improvement of performance in IT systems. In our opinion, performance testing and tuning is a science that is possibly spiced with some gut feeling (which is often based on experience, so we would say knowledge possibly sprung from science).

In this chapter, we will kick off by defining some key terminologies and measures of performance. After that, we will turn our focus to the process of performance tuning and its place in the software development process and the software life cycle. This will include its iterative behavior and talking about when, where, and how performance tuning should be done in an enterprise stack.

Performance

In the world of Information Technology (IT), performance is often used as a generic term of measure. This measure can be experienced somewhat differently depending on the role an individual has.

A user of a certain application will think more or less favorably of the application depending on how fast it responds, or flows, from his or her individual perspective and interactions. For a developer, an administrator, or someone else with a more technical insight of the application, performance can mean several things, so it will need to be defined and quantified in more detail. These expert roles will primarily need to distinguish between response time, throughput, and resource utilization efficiency.

Response time

Response time is normally measured in seconds (and is often defined with some prefix, such as milli or nano) and relates to the sum of time it takes to send a request to an operation, the execution time of the operation in a specific environment, and the time taken to respond to the requester that the operation has completed. The request, the execution of the operation, and the response are collectively called a roundtrip: a there-and-back-again trip.

A typical example, (depicted in the following diagram), is a user who has filled out a form on a web page. When the user sends the form by clicking on the Submit button and sends the data in the form, the timer starts ticking. As the data is received by a server, the data populates a JavaBean in a Java Servlet. From the servlet, subsequent calls to other components such as other servlets and EJBs will occur. Some data will then be persisted in a database. Other data can be retrieved from the same or other databases, and everything will be transformed into a new set of data in the shape of an HTML page that is sent back to the browser of the end user. As this response of data materializes at the user's end, the timer is stopped and the response time of the roundtrip can be revealed:

The response time, starting at t=0 and ending at t=x, and the roundtrip for a use case in a system.

Deciding what, or how much, should be included in a use case for measuring the response time, will vary on the test or problem at hand.

The total response time for the roundtrip of a system can be defined as the total time it takes to execute a call from an end user through all layers of the network and code to a database or legacy system, and all the way back again. This is an important and common value that is often used in service level agreements (SLA). However, it provides a far from complete picture of the performance and health of a system. It is important to have a set of use cases with the measured response time from various points in the system that covers its common and most vital functionality and components. These will be extremely helpful during tuning and when changes or problems occur.

Note

It is important to remember that the roundtrip in a use case must be constant, in terms of start and stop points, between measurements. Changing the definition will render the measurements useless as they must be comparable!

So, what can affect the response time? In short, any change might affect the response time in a positive or negative way. Changes that you can perform as a technician in the software, hardware, and related infrastructure—code, configuration, hardware, network topology, and so on—of a system, will have their effect and not seldom other than you might expect.

With all these things static, there might still be changes that can make the response time vary. Here, we're mostly concerned with the load on the system. As the load of the system increases, its response times will eventually rise as the system throughput decreases.

When an application performs work, that work is often triggered by external or internal clients. This will require resources, such as CPU, volatile memory, network, and persistent storage. The level of this utilization is the load of the system. Load can be measured for one or several of these resources.

Take, for example, an increasing number of users and the interactions they do in a system. The increase in system transactions could eventually exhaust available connections of a pool. The excess of transactions would need to be queued for released resources or even timeout. This then turns into a bottleneck, where the system isn't able to handle the increasing number of transactions quickly enough.

Throughput

The load a system can manage is coupled to the measure of the system throughput. Throughput is generically measured in transactions per given time unit, where a transaction can be a task or operation, or even a set of operations that act as one.

The time unit is often measured in seconds but can be significantly smaller (milli, nano) or bigger (minutes, hours, and so forth). Commonly, throughput is denoted as transaction per second (TPS).

Here, a transaction or operation can be of any size such as a small computational function or a big business case spanning over several components or systems. The size is not of importance but the amount of operations is.

An alternative measure of throughput that is often used is the amount of data transferred per second, such as bytes per second. Just like an SLA often has one or more stated response times for a set of use cases, throughput normally also has TPS values for the system as a whole and possibly, some for subsystems/components that are important from a business perspective.

From a technical or IT-operations perspective, it is equally important to know what throughput certain systems or subsystems regularly have, and at what levels these might start to have problems and failures. These will be important indicators for when upgrades are in order.

With a focus on Java EE, it is important to remember that the Java EE specification, and therefore, most application servers that implement it, were designed for overall throughput and not guarantees about response times.

Utilization efficiency

Low response times and a high measure of throughput is normally what anyone wants from a system, as this will help in keeping customers happy and the business thriving. If money is of no concern, it might not be a big deal from a technical perspective to have a lot of hardware and using more resources than needed, as long as business is booming.

This poor efficiency will, however invoke unnecessary costs, be it to the environment, the employment force, development time, system management, administration, and so on. Sooner or later, a business that wants to be or stay profitable must have an efficient organization that can rely on cost-efficient IT departments and systems. This includes utilizing available resources in the most efficient way while keeping the customers happy. It's a balancing act that business and IT departments must do together.

Having a bit less computational force, memory, and IT staff available might (among many things) cause higher response times and worse throughput. Consequently, software must be more efficient on available hardware. To make the software efficient, we need to test and improve its performance.

Scalability

A system needs to be able to handle an increasing load in order for the business to stay attractive to customers. The response times need to be kept down for each individual user and the total throughput needs to increase as the amount of transactions increase. We say that the system needs to scale to the load, and scalability is the capability that the system needs in order to increase total throughput.

When a system needs to be scaled, there are two major disciplines that can be followed: vertical scaling and horizontal scaling. Vertical scaling (or scaling up), as shown in the following diagram, involves adding more hardware resources, such as processor cores and memory, to an existing computer. This was the prevalent way to scale in the days of the mainframes but is used to some extent even today as virtualization has gained momentum:

Vertical scaling involves adding more resources to an existing computer.

Horizontal scaling (or scaling out) involves adding more computers that are connected through a network. A simple example of horizontal scaling is shown in the following diagram. This has been the concept of most computer topologies for several years and has gained enormous momentum with cloud services and big data:

Horizontal scaling involves adding more computers to a networked collective of computers, such as a cluster.

In general, adding more resources to a single computer becomes more expensive than adding more computers at some point. The single computer will be of low volume and will often be very specialized, as it needs to have an advanced and expensive architecture to handle a lot of processors and memory, whereas the many cheap computers can be simple, off-the-shelf products. The single computer will be a better computer standing next to any of the cheap ones, but at some point, the grand number of cheap computers will collectively be cheaper, faster, and thereby, better than the expensive one.

In the extreme, having just one computer can be hazardous as it will be a single point of failure. Using one computer will, however, be easier from an administrative point of view. There will only be one place to make changes or configurations. It will also be easier from a developer's point of view, as the programming model won't have to deal with many of the more complex scenarios that a distributed model can require.

As with all things, there are pros and cons with the two different types of scaling. There are also several factors that bridge the gap between them. The single computer in the vertical scaling scenario is seldom a single one. It is most common to have at least one backup server. In the horizontal-scaling scenario, the programming model has been simplified thanks to modern enterprise frameworks and the topology of computers can be adapted to let each cheap server in the network work on its own without the need (and complexity) to know about the rest.

Performance tuning anti-patterns

To tune the performance of a system means to improve one or more of its measures of performance. The question is how, when, and where should it be done? This is an area of great underestimation and major misconception. In the subsections that follow, we'll give you some examples of common mistakes and problems. Try to avoid them, or help out by correcting them, whenever and wherever you can.

The one-off

For many not-so-developed or understaffed organizations, performance testing with some possible tuning is more or less a one-off, something done just before an application is shipped out to production.

By only performing the testing and tuning at this point, the amount of work, if done properly, is much higher and much more complex than if it was done iteratively during the development of the application.

Naturally, an organization must keep within its financial limits, but doing performance testing just before a release is very hazardous. What will happen if an application turns out to not live up to the expected and necessary measures in production? It would clearly be very bad for business.

The wrong team

Very often, performance testing and tuning is run by staff that lacks the knowledge of how this testing and tuning should be performed. Getting the right individuals, in terms of competence, on board in the testing and tuning team is crucial. This can vary but normally involves quality assurance (QA) staff, experienced performance testers, and technical staff, such as architects and developers that have actually been involved in creating the system under test.

The lack of mandate

Even though the quality value of a system's performance has grown to be relatively recognized in most organizations today, there are still places where staff responsible for performance-related tests and tuning lack the voice or mandate to enforce proper quality tall-gates.

The clever developer

As passionate developers, we like to be clever. Making our code run smoothly is satisfying, and the performance improvements we make can give us a feel-good boost and self-confidence. That is great, but it's often not very meaningful to just (over)optimize our own functions or components. As developers, we won't know for sure how much or what parts of our code will actually be executed in such an amount that it will need performance tuning. In the long run, it can even hamper the performance as our optimizations might cause problems in other places of the system as a whole.

So, performance tuning is something that an organization as a whole should take seriously. It should be done iteratively and handled by a competent team with complementing skills, experiences, and mandate. As it's such an important factor for today's businesses, it should have a given place in any organizational process map.

Description

Packed with practical examples, this book looks at a different aspect of performance tuning in each chapter and shows you how to apply them to their existing Java applications. Anyone with an interest in learning more and improving the performance of Java-based technology in general, all the way to WildFly in particular, will find this book useful.

What you will learn

Tune and monitor an OS, a JVM, and WildFly with components and applications

Make various tuning tools work with WildFly

Configure and tune the JVM by analyzing its behavior

Understand numerous best practices and howtos

Monitor and tune various JEE technologies within WildFly, such as EJBs, WebServices, and JSFbased applications

Know the insandouts for getting the most out of the platform, its components, and surrounding infrastructure

Discover how to tune a clustered WildFly environment

What do you get with Print?

Instant access to your digital copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Redeem a companion digital copy on all Print orders

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Frequently bought together

€41.99

€41.99

WildFly Configuration, Deployment, and Administration - Second Edition

€41.99

Total € 125.97

Filter reviews by

All

Amazon verified reviews

Sergiy Pylypets Aug 04, 2014

This book surprised me in a positive way. While expecting to read a manual for WildFly configuration and tuning, I found the book to be also a useful guide for the performance tuning of Java EE applications and JVM itself. It covers relational databases, their design and optimization, JDBC, ORM technologies, like Hibernate and JPA, Servlets and JSP, JMS, SOAP and REST Web services, and some other technologies. The content is arranged in a consistent way. The first chapter contains an interesting discussion of performance tuning essentials, approaches and methodologies used for optimization. The second chapter refers tools and applications useful for tuning and monitoring different parts of Java EE systems. The third chapter provides information about JVM optimization for the most common use cases. The next chapters describe performance tuning of the WildFly server and its subsystems, like EJB, persistence layer, Web container, Web applications and services. The last chapter provides receipts for tuning WildFly clusters. The book language is clear and precise. The content includes numerous illustrations, like schemes, tables, and screenshots. Some chapters contain brief technical reminders to refresh knowledge of the technologies being discussed. All these features add value to the book. Also, there are some interesting historical reviews, like WildFly's history or The evolution of web frameworks. In general, I think that this book can be useful for any Software engineer, for anybody who is interested in the performance tuning of computer applications.

Amazon Verified review

M. Eisele Aug 05, 2014

The ContentBeside the title, the book is a more general resource for performance tuning around Java EE applications. Most of the chapters do not really rely on WildFly but give general hints about performance tuning essentials, approaches and methodologies used for optimization, like the first chapter. The second chapter covers tools for monitoring and tuning of various Java EE subsystems.Chapter three gives a introductory overview about general JVM tuning principles and applies to any JVM development. Beginning with chapter four it is going to be a bit closer to WildFly. EJBs are covered in chapter 5, JMS in chapter 9 and a general pattern here is to refer to Java EE concepts and apply the WildFly specific examples and extensions.Writing and StyleThe language is clear and precise. Additional illustrations, tables, and screenshots make it an easy and understandable read. Occasional basic information about Java EE components and concepts make it easy to follow for beginners, too.Conclusion and recommendationBeside the title who implies a very narrow focus, this is a book which can be a useful read for almost any Java EE developer out there. The explanations are good and helpful. If you ever had to deal with performance tuning you probably know most of those concepts but having them all in one place also makes this a perfect reference for the experienced developers.

Dustin Marx Jul 29, 2014

Wildfly Performance Tuning presents concepts, tips, and suggestions related to performance of WildFly-hosted applications that include both Java EE standard performance ideas and ideas that are unique to tuning WildFly performance. Because WildFly is an implementation of Java EE, it's not surprising that some of the performance tuning concepts covered in this book are Java EE general and could be applied to other Java EE application servers as well."WildFly Performance Tuning" has ten chapters and the first, second, third chapters and sixth chapters have very little WildFly-specific detail in them. They are more general and mostly apply to other Java EE application servers as well. In some cases, they are even more general than Java EE, applying to Java SE and other languages in some cases. Chapter 3 is among the best introductory overviews I have seen of general JVM tuning principles in a single chapter and mostly applies to any JVM development (not limited to WildFly).Chapter 4 is a general WildFly tuning chapter and the remainder of the chapters focus on components/specifications of Java EE (and of WildFly). For example, Chapter 5 covers tuning EJBs on WildFly and Chapter 9 covers tuning JMS on WildFly. Most of these chapters provide WildFly-specific concepts and examples as well as Java EE-general concepts and examples.Packt Publishing provided me with a PDF version of this book that is the subject of this review, but I have received no compensation for the review.It was nice to have the color screen snapshots in the PDF version of this book. The code examples are well-formatted, but they do not have color coded syntax and do not include line numbers.

Allen Polo Nov 03, 2017

Some tips but there are many performance issues that not get addressed, like tools that could be used, how to make a plan for performance improvement issues, how to attack based on a strategy.

Kindle Customer Sep 17, 2014

This book focuses on the latest iteration of the JBoss JEE server, Wildfly. Like many performance books, it offers advice that applies to performance in general, JEE specifically, and a particular technology (Wildfly) especially.The first three chapters deal with methodology for performance tuning, tools of the trade (especially open source tools), and JVM tuning. The first chapter contains material that will be largely familiar to anyone who's done much tuning in the past, but is good for those who are new to tuning. The second chapter outlines tools that will probably be familiar to experienced tuners. There are some good tips here. The third chapter explains JVM tuning. Combined, these three chapters make for a good background for Java tuning.The next six chapters deal with Wildfly. They introduce the server in general, then specifically address EJBs, Persistence/JPA, Web Container (Undertow), Web Applications and Web Services (to include REST), and JMS. These chapters include some really good expert-level tips. If you are a user of Wildfly (or the product version, Red Hat's EAP) then these chapters alone will probably make the book a worthwhile purchase. There's some good advice here for users of other JEE servers, but the real value here is for JBoss users.The final chapter covers Wildfly clustering. If you use Wildfly (or the product equivalent, EAP) for production use, you will want to know about clustering.I thought the book was very strong from a technical standpoint. Users of Wildfly (future EAP) will be quite pleased with the solid advice provided.All things considered, I'd recommend this book for any Wildfly / EAP user. Users of other JEE servers (WebSphere, WebLogic) might consider it, but won't get the same bang for the buck. Users of JEE in general should benefit strongly from the first chapters, but the application-specific tips won't all fit.About 300 pages, this one is worth the money if this is your work area.

WildFly Performance Tuning: Develop high-performing server applications using the widely successful WildFly platform , Third Edition

What do you get with Print?

WildFly Performance Tuning

Chapter 1. The Science of Performance Tuning

Performance

Response time

Note

Throughput

Utilization efficiency

Scalability

Performance tuning anti-patterns

The one-off

The wrong team

The lack of mandate

The clever developer

Page 1 of 11

Description

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs

WildFly Performance Tuning: Develop high-performing server applications using the widely successful WildFly platform , Third Edition

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Response time

Throughput

Utilization efficiency

Description

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs