Java Performance : Measuring and Tuning Nataraja Neelakanta - - PowerPoint PPT Presentation

java performance measuring and tuning
SMART_READER_LITE
LIVE PREVIEW

Java Performance : Measuring and Tuning Nataraja Neelakanta - - PowerPoint PPT Presentation

Java Performance : Measuring and Tuning Nataraja Neelakanta Overview Most of the applications today are designed and developed for simultaneous use by a large number of users. At times there are underlying problems in the code,


slide-1
SLIDE 1

Java Performance : Measuring and Tuning

Nataraja Neelakanta

slide-2
SLIDE 2

Overview

  • Most of the applications today are designed

and developed for simultaneous use by a large number of users.

  • At times there are underlying problems in

the code, which may cause error conditions the code, which may cause error conditions such as Memory leaks, Race conditions, Thread locks and so on which if neglected, stretches the use of resources beyond limits, causing the application to slow down

  • r even crash.
slide-3
SLIDE 3

Profiling

Java Profiling is the process of monitoring various JVM level parameters such as Method Execution, Thread Execution, Object Creation and Garbage Collection. CPU time being utilized per method

  • CPU time being utilized per method
  • Memory being utilized
  • Method call information
  • Objects being created
  • Objects being garbage collected
slide-4
SLIDE 4

Profile snapshot example

slide-5
SLIDE 5

JRE / JVM hmm … what is what ?

slide-6
SLIDE 6

More on JRE and JVM

  • JIT converts the .class file to machine

executable code that can be directly executed by OS.

  • This machine executable code is placed in

class segment of RAM by class loader. class segment of RAM by class loader.

  • Java <Program Name> starts the jvm, which

in turn invoke MM module of JRE to allocate three segments in RAM, based on -XX parameters.

  • JRE can be looked upon as an instance of

java.lang.Runtime class

slide-7
SLIDE 7

Classloaders : hierarchy and functions

slide-8
SLIDE 8

Class loading phases

slide-9
SLIDE 9

Class loading explained

1.

Physical loading- class file will be searched in the classpaths, if found, the byte code is

  • loaded. A basic memory structure is

established hence.

2.

Linking –

2.

Linking –

1.

  • i. Byte code verification

2.

  • ii. Class preparation – prepares data structures

fields, methods etc.

3.

  • iii. Resolving references.
  • 3. Initialization – static blocks, variables.
slide-10
SLIDE 10

Understanding the heap

  • The Java heap is divided into three sections
  • Young generation, Old generation,

Permanent Generation.

  • HotSpot VM

The HotSpot VM is the garbage collector that comes with the JavaSoft virtual machine.

  • The heap layout of a typical HotSpot VM is

depicted in the next slide

slide-11
SLIDE 11

Heap layout

slide-12
SLIDE 12

Young Generation

  • The Eden Space of the Young Generation

holds all the newly created objects.

  • When this generation fills,the Garbage Colle

ctor clears out of memory all objects that are unreferenced. unreferenced.

  • Objects that survive this gcare moved to the

“From” Survivor Space.

  • It has two equally‐sized subspaces “To” and

“From” which are used by its algorithm for fast switching and cleanup.

slide-13
SLIDE 13

Old generation

  • Once an object survives a given number GC

,it is promoted (or tenured) from the “To” Sp ace to the Old Generation.

  • Objects in this space are never garbage coll

ected except in the two cases- ected except in the two cases-

  • Full Garbage Collection
  • Concurrent Mark‐and‐Sweep Garbage Collection

If the Old Generation is full and there is no way for the heap to expand, an Out‐of‐Memory error (OOME) is thrown and the JVM will crash.

slide-14
SLIDE 14

Permanent Generation

  • The Permanent Generation is where class fil

es are loaded/kept. These are the result of c

  • mpiled classes and jsp pages.
  • If this space is full, it triggers a Full Garbage

Collection. Collection.

  • If the Full Garbage Collection cannot clean
  • ut old unreferenced classes and there is no

room left to expand the Permanent Space, an OOM is thrown and the JVM will crash.

slide-15
SLIDE 15

Code snippet causing PermGen

slide-16
SLIDE 16

Memory image for the class

slide-17
SLIDE 17

Reachability and GC

slide-18
SLIDE 18

Performance improvement – General aspects

1.

Using appropriate data structures.

2.

Making use of multi-threaded approach

3.

Using WeakHashMaps as appropriate.

4.

Careful usage of Singletons.

4.

Careful usage of Singletons.

5.

Removing unnecessary methods, variables, loops.

6.

Avoiding multiple calls to remote components.

7.

Implementing efficient hashing algorithms.

slide-19
SLIDE 19

Reference utility-java.lang.ref

  • Garbage Collector won’t remove a strong reference.
  • A soft reference will only get removed if memory is low. So

it is useful for implementing caches while avoiding memory leaks.

  • A weak reference will get removed on the next garbage

collection cycle. Can be used for implementing canonical collection cycle. Can be used for implementing canonical (conformance to standards)maps.

  • The java.util.WeakHashMap implements a HashMap with

keys held by weak references.

  • A phantom reference will be finalized but the memory will

not be reclaimed. Can be useful when you want to be notified that an object is about to be collected.

slide-20
SLIDE 20

Performance improvement – across layers

Plain java layers –

1.

Effective use of java.util.concurrent package utilities like ConcurrentHashMap.

2.

Future interface can be used to represent results of an asynchronous computation. results of an asynchronous computation.

3.

Using UncaughtExceptionHandler to get notified when a thread is about to get terminated due to uncaught exception.

4.

If UEH is used along with an executor service, care should be taken to use it via Future.

5.

Making thread a daemon.

slide-21
SLIDE 21

Performance improvement – across layers…Plain java layers

Plain java layers –

  • 5. Using of BlockingQueue, especially where

there is a need of Producer /Consumer scenario.

  • 6. Effective usage of ThreadPoolExecutor,

that provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead.

  • 7. They provide a means of bounding and managing

the resources, including threads, consumed when executing a collection of tasks.

  • 8. Effective String handling.
slide-22
SLIDE 22

Performance improvement – across layers…J2EE stack

  • 1. Using AJAX, that cuts the response and

presents only relevant part of response to the client.

  • 2. Effective design and implementation, using

responsive xml parsing mechanisms, like responsive xml parsing mechanisms, like StAX.

  • 3. Using JSON for presentation tier, for data

response, which gets interpreted faster than xml.

  • 4. Using Proxy / Prototype patterns wherever

necessary, whenever object creation / initialization is costly.

slide-23
SLIDE 23

Performance improvement – across layers…J2EE stack

Database interaction

1.

Using Prepared (pre-compiled) Statements

2.

Using frameworks such as Spring, Hibernate.

3.

Ensuring closing of Connection, ResultSet.

4.

Being rational in using Prepared vs normal Statements.

5.

Reducing Data Intensive operations in Java layer.

6.

Using frameworks such as quartz for job scheduling.

slide-24
SLIDE 24

Performance improvement – across layers…J2EE stack

Databases / Infrastructure

1.

Using Indices – Clustered / Non-Clustered.

2.

Denormalization of schema

3.

Query hints.

3.

Query hints.

4.

Optimal usage of joins, and avoiding inner/subqueries.

5.

Fail-over, load balancing mechanisms

  • ffered by application servers.

6.

Using cloud, SaaS,PaaS,IaaS.

slide-25
SLIDE 25

Performance improvement – across layers…J2EE stack

Databases / Infrastructure Sharding

  • Horizontal partitioning is a database design principle

whereby rows of a database table are held separately, rather than being split into columns. Each partition forms part of a shard, which may in turn be located on a separate database server or physical location.

  • Since the tables are divided and distributed into multiple servers,

the total number of rows in each table in each database is reduced.

  • This reduces index size, which generally improves search

performance.

  • A database shard can be placed on separate hardware, and

multiple shards can be placed on multiple machines.

  • Sharding differs from horizontal partitioning, where, Sharding has

the capability to partition across multiple instances of the schema.

  • Hibernate supports shards.
slide-26
SLIDE 26

Conclusion

Java Performance is an oceanic topic

i.

There should be an optimal / rational design.

ii.

More time should be spent on application design, and preparation for implementation.

iii.

Preparation for implementation means, finalizing the data structures, data types

iv.

Performance measurement should be part

  • f the project plan and a continued effort.
slide-27
SLIDE 27

Thank you !!

Thanks to all for your patience !