Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
What Makes Play Framework
Fast?
Will Sargent
Training & Consulting
What is “Fast?”
Applications written using Play Framework
will do more with the same hardware.
How?
In the Beginning (1990s)
• When Java was invented
• A computer had one CPU, with one core
• Concurrency, but no parallelis...
CPUs in 1999
• CPUs are the engine
• Execute work when they have data
• Sleep when they don’t have data
• Best case scenar...
Computers Then
Reactive Applications 7
Imagine a CPU core as a paper shredder
Reactive Applications 8
If you have to get more paper (IO), the shredder
idles
Reactive Applications 9
Worst case - Single Threaded Model
Reactive Applications 10
Threads
• Threads keep data in memory until the CPU can execute it
• The more threads you have, the more memory you need
•...
More people (threads) == happy shredder
Reactive Applications 12
Computers Now
Reactive Applications 13
Multicore CPUs makes threading vital
• Xeon E5-2699v3 has 18 cores on a single CPU, may have 2 CPUs
• 36 cores available
•...
Parallelism: Doing multiple things
Reactive Applications 15
Tomcat is a Servlet Container
• Servlets
• were invented in 1997
• Thread per Request model (will explain in next slide)
•...
Thread per Request Model
• A thread is created or retrieved from a pool for every HTTP request.
• The thread is bound to t...
Thread per Request Model
• Let’s keep going with the analogy:
• The CPU is a paper shredder – if it’s not being fed pages,...
Thread Per Request == one book for one
thread
Reactive Applications 19
If a request is slow, means one fewer
thread!
Reactive Applications 20
No pages!
ThreadLocal means state tied to thread!
Reactive Applications 21
Session B
Session A
New advances in Java
• NIO – non blocking IO
• Released in JDK 1.4 (2002)
• NIO.2 came out in JDK 1.7 (2011)
• STILL not u...
Play is an Async, Non-Blocking HTTP server
• Asynchronous
• “Not guaranteed to happen in the order you run it”
• “Shred th...
Work Stealing in Action – no idle threads!
Reactive Applications 24
Why is Play Faster?
• Responsive
• Uses Futures and Thread Pools to let CPU go at full throttle
• Uses NIO.2 through Netty...
Why is Play Faster?
• Elastic
• Start as many Play instances as you need, scales with your hardware
• Stop and restart Pla...
How do I package a Play application?
• $ activator package:packageBin
• Produces a Debian package
• $ activator rpm:packag...
How do I run Play in production?
• The distribution includes a shell script, under ./bin/yourapp
• Running the app generat...
What about Play in Tomcat using
Play2WAR?
Reactive Applications 29
Why not Tomcat?
• Servlet containers like Tomcat have architectural problems at their
core.
• Wasteful of CPU
• Thread per...
More interesting stuff…
HOW TO VIDEO
Managing Library
Dependencies with
Play, sbt & Activator
WATCH NOW
HAVE QUESTIONS?
Ge...
EXPERT TRAINING
Delivered on-site for Akka, Spark, Scala and Play
Help is just a click away. Get in touch
with Typesafe ab...
©Typesafe 2014 – All Rights Reserved
Upcoming SlideShare
Loading in …5
×

Why Play Framework is fast

52,640 views

Published on

Typesafe trainer and consultant Will Sargent describes just how Play Framework is so "fast" for Java and Scala production apps.

More Play, Akka, Scala and Apache Spark webinars, presentations, and videos:

http://typesafe.com/resources/videos

Published in: Software

Why Play Framework is fast

  1. 1. What Makes Play Framework Fast? Will Sargent Training & Consulting
  2. 2. What is “Fast?”
  3. 3. Applications written using Play Framework will do more with the same hardware.
  4. 4. How?
  5. 5. In the Beginning (1990s) • When Java was invented • A computer had one CPU, with one core • Concurrency, but no parallelism (literally cannot run 2 threads at once) • Most concurrent access was based around synchronized locks.... • ...and people expected much less from the World Wide Web. Reactive Applications 5
  6. 6. CPUs in 1999 • CPUs are the engine • Execute work when they have data • Sleep when they don’t have data • Best case scenario • You give data to the CPU just as it needs it • Your CPU will run close to 100% and never sleep... • ...execute all the work as fast as possible • ...and then drop down to 0% once it’s done. • Even in 1999, the problem was feeding a CPU enough data • IO (disk / network) is too slow, not enough data to feed CPU Reactive Applications 6
  7. 7. Computers Then Reactive Applications 7
  8. 8. Imagine a CPU core as a paper shredder Reactive Applications 8
  9. 9. If you have to get more paper (IO), the shredder idles Reactive Applications 9
  10. 10. Worst case - Single Threaded Model Reactive Applications 10
  11. 11. Threads • Threads keep data in memory until the CPU can execute it • The more threads you have, the more memory you need • But if the CPU is idle, then you may as well process it. • Still works even when you have only one CPU! Reactive Applications 11
  12. 12. More people (threads) == happy shredder Reactive Applications 12
  13. 13. Computers Now Reactive Applications 13
  14. 14. Multicore CPUs makes threading vital • Xeon E5-2699v3 has 18 cores on a single CPU, may have 2 CPUs • 36 cores available • Multiple cores mean that requests can be processed in parallel • Imagine each core as a paper shredder • Some documents are larger and need more shredding (balancing work) • Ensure everyone gets access to a shredder eventually (fairness) • Ensure that no-one gets stuck or behaves badly • Ensure that everyone gets served in a timely manner (responsive) Reactive Applications 14
  15. 15. Parallelism: Doing multiple things Reactive Applications 15
  16. 16. Tomcat is a Servlet Container • Servlets • were invented in 1997 • Thread per Request model (will explain in next slide) • Pretty good at the time • Single CPU means nothing runs in parallel • Enough threads, enough memory, and you can keep feeding the CPU Reactive Applications 16
  17. 17. Thread per Request Model • A thread is created or retrieved from a pool for every HTTP request. • The thread is bound to the request for the request’s lifetime. • Advantages • Useful for ThreadLocal (putting extra data into thread from request) • Disadvantages • 1 to 1 requirement between a thread and a request! • If the request is kept open, the thread has to wait until it closes or gives data! • This means cannot use Comet, AJAX, SSE, Websocket, etc. • Servlet 3.x attempts async model, but no Websocket support Reactive Applications 17
  18. 18. Thread per Request Model • Let’s keep going with the analogy: • The CPU is a paper shredder – if it’s not being fed pages, it’s idle. • Work/data is a set of pages to be shredded. • A thread ferries around pages until it has access to the shredder. • A request is someone holding a book, and offering a few pages at a time. • In thread per request, the person ferrying pages can only get pages from one person, and has to wait otherwise. Reactive Applications 18
  19. 19. Thread Per Request == one book for one thread Reactive Applications 19
  20. 20. If a request is slow, means one fewer thread! Reactive Applications 20 No pages!
  21. 21. ThreadLocal means state tied to thread! Reactive Applications 21 Session B Session A
  22. 22. New advances in Java • NIO – non blocking IO • Released in JDK 1.4 (2002) • NIO.2 came out in JDK 1.7 (2011) • STILL not used in many applications for backwards compatibility • java.util.concurrent • Released in JDK 1.5 (2004) • High performance thread pools and ExecutionContext • But came out after most J2EE app servers were already architected. Reactive Applications 22
  23. 23. Play is an Async, Non-Blocking HTTP server • Asynchronous • “Not guaranteed to happen in the order you run it” • “Shred these five documents, I don’t care in which order it happens.” • Can be parallel if you have multiple cores (i.e. five shredders) • Non-blocking • “If you’re waiting on something, give up the core until you have data” • “Don’t hog the shredder if you’re out of paper.” • Play uses a fork join execution context with work stealing • Does not bind a thread to a request – happy threads! • “If you need paper, you can get it from anyone who has paper” • Async + Non-Blocking = Responsive Reactive Applications 23
  24. 24. Work Stealing in Action – no idle threads! Reactive Applications 24
  25. 25. Why is Play Faster? • Responsive • Uses Futures and Thread Pools to let CPU go at full throttle • Uses NIO.2 through Netty to avoid blocking on network IO • Stateless (no HTTP session), short lived objects for better GC • No ThreadLocal anywhere • Typically under 500 MB footprint • Resilient • Operations Friendly • Deploys as a standalone RPM / Debian / tar.gz bundle • Bounce server in seconds, no Java EE overhead • Behaves like any other Unix process Reactive Applications 25
  26. 26. Why is Play Faster? • Elastic • Start as many Play instances as you need, scales with your hardware • Stop and restart Play servers as you feel like (it’s all stateless) • Typesafe ConductR will do the grunt work for you • Message Driven • Play integrates seamlessly with Akka • WebSocket / Ajax / Server Sent Events are handled through Actors • Backend communication through Akka or Play WS (REST API) • Experimental integration with Akka Streams coming in 2.4 • Responsive + Resilient + Elastic + Message Driven = Reactive Reactive Applications 26
  27. 27. How do I package a Play application? • $ activator package:packageBin • Produces a Debian package • $ activator rpm:packageBin • Produces an RPM package • $ activator universal:packageZipTarball • Produces a gzipped tarball • $ activator docker:publishLocal • Produces a docker image • https://www.playframework.com/documentation/2.3.x/ProductionDist Reactive Applications 27
  28. 28. How do I run Play in production? • The distribution includes a shell script, under ./bin/yourapp • Running the app generates a file with the process id: • ./bin/yourapp -Dpidfile.path=/var/run/play.pid • Stopping the app is done by killing the process: • kill $(cat /var/run/play.pid) • Play needs Java to be installed on the server, preferably Oracle JDK 1.8. • You should run Play as a reverse proxy behind an http server, like nginx. • Use several nginx instances behind a load balancer, like haproxy. • https://www.playframework.com/documentation/2.3.x/ProductionCon figuration Reactive Applications 28
  29. 29. What about Play in Tomcat using Play2WAR? Reactive Applications 29
  30. 30. Why not Tomcat? • Servlet containers like Tomcat have architectural problems at their core. • Wasteful of CPU • Thread per request model (until 3.x) ties a thread directly to request • Even in 3.x, slower than native according to the Play2WAR documentation. • Wasteful of memory • Not stateless, b/c servlet API has httpRequest.getSession • Historically many “web” library used ThreadLocal & stateful patterns • Not always obvious when libraries use ThreadLocal under the hood. Reactive Applications 30
  31. 31. More interesting stuff… HOW TO VIDEO Managing Library Dependencies with Play, sbt & Activator WATCH NOW HAVE QUESTIONS? Get in touch with Typesafe today! CONTACT US SUCCESS STORY How LinkedIn Uses Play Framework READ NOW
  32. 32. EXPERT TRAINING Delivered on-site for Akka, Spark, Scala and Play Help is just a click away. Get in touch with Typesafe about our training courses. • Intro Workshop to Apache Spark • Fast Track & Advanced Scala • Fast Track to Akka with Java or Scala • Fast Track to Play with Java or Scala • Advanced Akka with Java or Scala Ask us about local trainings available by 24 Typesafe partners in 14 countries around the world. CONTACT US Learn more about on-site training
  33. 33. ©Typesafe 2014 – All Rights Reserved

×