Performance? That's what version 2 is for!

Performance? That's what version 2 is for!

Eduard Tudenhöfner

Performance? That's what version 2 is for!

Overview
► Introduction / Motivation

► Performance Issues & Solution Strategies

► How to proactively reduce risk of Performance Issues?

► Conclusion

Why is performance important?

Trustworthy
Real User Experience
USABILITY
Profit
Performance Monitoring
Maintenance SPEED MATTERS
Success Factor Stress
Bottlenecks
Revenue Economical
Efficiency
Less Resources Stability Security

Conversion Rate FASTERSatisfied customers SPEED SLA Monitoring
More
Higher Fault Tolerance BETTER
Key Performance Indicators Reputation
SALES

Why is performance important?

A page that was 2 seconds slower 400 ms delay cause 0.59% drop
results in a 4.3% in searches/user
drop in revenue/user
(Bing) (Google)

400 ms slowdown cause Introducing gzip compression resulted
5-9% drop in full-page traffic in 13-25% speedup and cut outbound
network traffic by 50%
(Yahoo) (Netflix)
Source: www.stevesouders.com

Investing in Performance
really pays off

Consequences of Poor Performance

Consequences
► Damaged customer relations
– Reputation of the company suffers
– People will continue to associate poor performance with the product, even when
the issue is fixed later on

► Lost income & Delayed project schedules
– Revenue is lost
– Penalties have to be paid due to late delivery

► Increased development & maintenance costs
– Delivering features requires more time and effort if performance issues are
hindering the acceptance of those features
– Additional time and resources are required if performance issues are found

Consequences of Poor Performance

The cost to fix a performance issue
► Is a Technical Debt (defined by Ward
Cunningham)
– doing things the quick&dirty way sets us
up with technical debt

– technical debt incurs interest payments
(in the form of additional effort)

– The later technical debt is payed Source: Steven Haines. Pro Java EE 5: Performance Management
and Optimization
back, the higher the interest will be

► So should we pay huge interest at the end or
pay back technical debt every development
cycle?

Performance Issues & Solution Strategies


Application Server

Client

Databases
Legacy Systems / Service Provider


Application Server

Application
Client

Databases


Client (UI / Browser)
► Bloated Clients

► Very expensive DOM manipulations

► Too many requests required until a page is fully loaded
– Time to first impression

– JavaScript files are at the wrong places

► Unsuitable communication patterns
– long running synchronous calls that block the UI

► Network bandwidth
– especially in the mobile area

done with: www.webpagetest.org
Chrome / DSL (1.5 Mbps/384Kbps)
50ms RTT

done with: www.webpagetest.org
Chrome / DSL (1.5 Mbps/384Kbps)
50ms RTT

DOM complete
after 2.6 s

Rendering starts
after 3.4 s

49 requests
two uncompressed
images

3.9 s till page
is fully loaded


Solution Approach
► Reducing RTTs by
– Reducing number of resources

– Avoiding bad requests
– Minimizing redirects
– Combining CSS / JS resources (e.g. during build process)
► Reducing Request overhead by
– Using compression (gzip, deflate)
– Minifying CSS / JS resources (cssminifier.com, jscompress.com)
► Placement of CSS and JS files
– CSS at the top / JS at the bottom
● browser should start rendering as early as possible (user perceives a faster loading
page)
● anything below the script is blocked from rendering and downloading until after the
script is loaded (even when threads are available)→ entire page is delayed


How to achieve that in Java (e.g. in JSF)?
► JAWR (jawr.java.net)
– Built-in minification

– Enforced caching
– Bundling of resources
– CSS image sprite generation
– Can be integrated in Ant / Maven
– Can be used with (JSF, Spring MVC, Wicket, Grails, ...)

source: jawr.java.net

JAWR

What we would How we want How we can define
like to achieve to structure files bundles
our work


Application Server / Application eden
► Memory issues
– Memory leaks / OutOfMemoryErrors (but not every leak leads to OOME) survivor
survivor
– Unnecessary creation of expensive objects
– Static fields and Lists / ThreadLocal usage within AppServer
– inappropriate GC strategy / Heap sizing (for generational GC)
old

► Caching
– Wrong caching strategy
– Too much or the wrong stuff is cached perm

► Remote boundaries too fine-grained
– remote communication often done transparently for the developer
– increased round trips
– increased serializations/deserializations


Application Server / Application
► Synchronization issues
– synchronized blocks are too wide (method locks vs block locks) → code is locked that
is not necessary
– issue will not be present when doing tests with a small number of users
– can't scale when number of requests grows (the surprise comes when doing load tests
or putting application to production)
– not taking advantage of lock-free data structures (java.util.concurrent.atomic)

► Verbose Logging log.debug("Starting " + getInstName() + "/" + getInst());
– What is the cost of getInstName() and getInst()?
– too much is logged / unnecessary string concatenations

► Not taken advantage of the possiblities of the underlying containers (Web, EJB, …)
– unsuitable pool sizes (Thread Pools, EJB Pools, Connection Pools, …)


Solution Approaches eden
► Memory
– Generation sizing (for generational GC) survivor
● -XX:NewRatio=3 → 1:3 (Young:Old) → Young takes ¼ of what was specified survivor
with -Xmx
● Sizing proportion between Old/Young generation is important for performance
● e.g. if too many short-lived objects are created, they are moved to the old
generation
old
● An oversized young generation can also cause performance problems
–Space on old generation is reserved for emergencies (so that all objects
can be copied)
● Memory analysis with e.g. VisualVM, -verbose:gc

perm
– ThreadLocal variables in an application server
● Threads are reused but data is kept
● Need to delete ThreadLocal variables before thread is reused by application
server

– Static fields and Lists
● Best Approach: use only for data that never changes


VisualVM with VisualGC Plugin


Solution Approaches eden
► Memory
– Generation sizing (for generational GC) survivor
●
-XX:NewRatio=3 → 1:3 (Young:Old) → Young takes ¼ of what was specified survivor
with -Xmx
●
Sizing proportion between Old/Young generation is important for performance
●
e.g. if too many short-lived objects are created, they are moved to the old
generation old
●
An oversized young generation can also cause performance problems
– Space on old generation is reserved for emergencies (so that all objects
can be copied)
●
Memory analysis with e.g. VisualVM, -verbose:gc
perm
– ThreadLocal variables in an application server
●
Threads are reused but data is kept
●
Need to delete ThreadLocal variables before thread is reused by application
server

– Static fields and Lists
●
Best Approach: use only for data that never changes


Solution Approaches
► Remote boundaries
– Decrease number of remote calls → „The best call is the call that is not
done“
– Boundaries should be more coarse-grained e.g. by using wrapper classes
(of course that contain only the really required information)
– Depending on the communication parties (heterogeneous/homogeneous),
the right protocol should be used

► Logging
– carefully plan what to log and on which level
=> Log messages should have the ability to run fast in production
environment and at same time help in identifying any issue in QA and
TEST environment


Databases (from an application's point-of-view)
► More / Less data is retrieved than actually required

► Same data is retrieved over and over again (n+1 query problem)

► High normalization good for reducing redundancy, but bad for performance

► Inappropriate connection pool sizes

► Usage of O/R mappers
– can lead to unexpected behavior if used in a wrong way

– possibilities of JPA framework not known or not used efficiently


Solution Approaches
► Data Retrieval
– Read-Only queries (query.setHint(“eclipselink.read-only“, “true“) )

●
improves performance by avoiding copying and change tracking the objects
– Fetch Joins
– Batch Reads
– Other loading optimizations
●
Use projection queries where appropriate
●
Use pagination for large result sets (query.setMaxResults(), query.setFirstResults())
●
Use named queries (likely to be precompiled by provider, reusability)

► Updating Data
– Batch Update
●
allows a bunch of update operations to be performed as a single DB access
●
reduces round trips to the database
<property name="eclipselink.jdbc.batch-writing" value="Oracle-JDBC"/>


Fetch Joins - Example
Query query = em.createQuery(“SELECT po from PurchaseOrder po WHERE
po.status = 'ACTIVE' AND po.customer.address.city = 'Stuttgart'”);

List<PurchaseOrder> orders = query.getResultList();

for (PurchaseOrder order: orders) {
order.getCustomer().getName();
}

{returns N purchase orders} → 100 positions = 101 SQLs

Better:
SELECT po from PurchaseOrder po FETCH JOIN po.customer...

{returns N purchase orders} → 100 positions = 1 SQL

→ related objects will be joined into the query instead of being queried independently


Batch Reads - Example
Query query = em.createQuery(“SELECT po from PurchaseOrder po WHERE
po.status = 'ACTIVE' AND po.customer.address.city = 'Stuttgart'”);

query.setHint(“eclipselink.batch”, “po.customer”);

...

{returns N purchase orders} → 100 positions = 2 SQLs
(one additional for each relationship)

→ subsequent queries of related objects can be optimized in batches instead of
being retrieved one-by-one

→ Batch reading is more efficient than joining because it avoids reading
duplicate data.


Solution Approaches
► Data Retrieval
– Read-Only queries (query.setHint(“eclipselink.read-only“, “true“) )

● improves performance by avoiding copying and change tracking the objects
– Fetch Joins
– Batch Reads
– Other loading optimizations
● Use projection queries where appropriate
●
Use pagination for large result sets (query.setMaxResults(), query.setFirstResults())
● Use named queries (likely to be precompiled by provider, reusability)

► Updating Data
– Batch Update
●
allows a bunch of update operations to be performed as a single DB access
● reduces round trips to the database
<property name="eclipselink.jdbc.batch-writing" value="Oracle-JDBC"/>


► They are often out ouf our control

► Legacy Systems
– often very difficult to troubleshoot legacy systems

– running dinosaurs
– limited insight into those systems
► Service Providers
– No influence on them

– SLAs

How to proactively reduce risk of Performance Issues?


Pragmatic Solution Approach
► 1. From a general point-of-view
– Define someone that is responsible for Performance Management in the project

– Identify Performance Risks early
– Define Performance Objectives (measurable & realistic)
●
otherwise there is a risk that objectives are simply ignored because too
difficult to achieve
– Conduct Architectural Reviews (continually)
●
to find out whether the architecture is really capable of meeting performance
objectives
– Do Performance Tests (before application goes to production)
– Monitor your Application (especially in PreProduction & Production)
●
to find out how the application is really used (application usage pattterns)
●
to identify trends (important for capacity planning)
– Know your users


Pragmatic Solution Approach
► 2. From a technical point-of-view
– Know the used technologies

– Always look out for possible performance improvements in those technical
areas
● Important: analyze the effects of „improvements“ and „Best Practices“
– Pay back technical debt as soon as possible
– Add small performance tests and not just unit tests (and automate them)

Conclusion

Conclusion
► Investing time & money in performance really pays off

► There needs to be someone responsible for APM

► Performance issues can reside anywhere in an architecture
– Architectural reviews, performance tests, aware
developers/architects/testers can help in reducing the risk

► From the managements point-of-view it seems that performance engineering
seems to cause initially more costs than bringing value
– Problem: difficult to demonstrate success, but poorly performing
applications are clearly observable as failures
“Why do we have performance engineers
if we don't have performance problems?” by Connie U. Smith

Thank you for your Attention!

Please also have a look at the PERT Wiki space at
https://www.adesso.de/wiki/index.php/PERT

PERT@adesso.de
eduard.tudenhoefner@adesso.de
www.adesso.de

Performance? That's what version 2 is for!

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (10)

Similar to Performance? That's what version 2 is for!

Similar to Performance? That's what version 2 is for! (20)

Recently uploaded

Recently uploaded (20)

Performance? That's what version 2 is for!