The document emphasizes the importance of performance in Java applications, highlighting the impact of milliseconds on user experience and sales. It advocates for continuous performance testing and monitoring, collaboration between development and operations teams, and adherence to coding best practices. The conclusion stresses proactive performance management and debunks common performance myths.

1. Java Performance
What Developers Must Know
Diego Lemos

2. We care about performance...
(credit: http://www.morguefile.com/)
...when things go bad.

3. Panic Driven Actions
●
Add more hardware
●
Work on ugly code
●
Long Meetings (?!)
●
Blame somebody

4. Milliseconds Matter
●
Amazon:
–
●
Increase 100ms in load time decreased sales by 1%
Google:
–
From loading a 10-result page in 0.4 seconds to a 30result page loading in 0.9 seconds decreased traffic and
ad revenues by 20%

5. Measure Don’t Guess
●
Support decisions by measurements
●
Tune what matters
(credit: http://xkcd.com)

6. Generic Application Stack
Application
Profiling
JVM
Heap Analysis
Operating System
Monitor System
Hardware

7. Tools
●
vmstat, iostat, netstat
●
JMeter, Gatling
●
HPjmeter
●
VisualVM, jconsole

8. Demo :

9. Any problem here?
Java heap space

10. And here?
Everything is OK!

11. What happened here?
"catalina-exec-8190-104" - Thread t@135
java.lang.Thread.State: BLOCKED
at com.google.code.morphia.Morphia.mapPackage(Morphia.java:72)

12. Performance Best Practices
●
●
●
●
Test one build a day for performance issues
(continuous integration)
Monitoring (production env.) for compliance
Keep users at the center of performance
tuning efforts
Devs + Ops

13. Performance Tests on CI

14. Follow Coding Best Practices
●
KISS
–
●
complex code is hard to optimize
Loose coupling
–
–
●
Optimize without fear of breaking anything else
Avoid contamination (external applications)
Let your objects die young

15. Performance myths
●
Tune by default (early tuning)
●
Optimize by precaution (over-engineer)
●
The architecture cannot change
●
Hardware will solve the problem

16. Conclusion
●
Think performance before problems come
●
Devs + ops working together
●
Monitor your application

17. More on this
●
http://java.dzone.com/kirk-dominating-consumer
●
https://github.com/dlresende/spring-petclinic
●
http://jmeter.apache.org/usermanual/glossary.html
●
http://www.oracle.com/technetwork/java/javase/gc-tunin
●
http://munchweb.com/effect-of-website-speed
●
http://www.javaworld.com/article/2073905/build-ci-sdlc