vert.x - asynchronous event-driven web applications on the JVM

16,357 views

Published on

vert.x presentation at SBB Developer Day 2012 in Bern, Switzerland

Published in: Technology
1 Comment
39 Likes
Statistics
Notes
No Downloads
Views
Total views
16,357
On SlideShare
0
From Embeds
0
Number of Embeds
1,523
Actions
Shares
0
Downloads
2
Comments
1
Likes
39
Embeds 0
No embeds

No notes for slide
  • http://www.mmoasteroids.comhttp://wordsquared.com/https://npmjs.org/https://github.com/popular/starredVertx module repositoryDEMO 1http://localhost:8080/my-webapp/demohttp://localhost:8080/my-webapp/demo?n=45&blockingsiege -c100 -b -r100 "http://localhost:8080/my-webapp/demo?blocking”DEMO 2siege -c100 -b -r100 "http://localhost:8081/?longrunning"
  • First WWW page: August 1991XMLHTTP Request: 1996 (iframe, asynchronous content loading)AJAX as a term: 2005XMLHttpRequest spec by W3C in 2006
  • Google TalkVs. Real Time Computing- Receiver not known / ensuredpush vs. pullusers receive information when publishedno need for active requiring informationthick clients in the browserdata is exchanged, not finished web page
  • Herausforderung an unsere Internet-InfrastrukturVielmehrlanglebigeconnecctions connection / peristente connectionsMobile und grundsätzlicheVernetzungInternet of ThingsEs hat sichgezeigt, dass 10’000 connections so eine “magisce” Grenzeist, die eszuknackengibt.
  • This can involve a combination of operating system constraints and web server software limitations.While there are some specialized web servers that can handle more than ten thousand client connections, most web servers currently handle at most ten thousand clients simultaneously.http://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-supportSo under 32-bit Windows, for example, where each process has a user address space of 2GB, giving each thread a 128K stack size, you'd expect an absolute maximum of 16384 threads (=2*1024*1024 / 128). In practice, I find I can start up about 13,000 under XP.
  • Long running requestsBlocking threads
  • In a lot of typical server applications threads are mostly waiting on IO.
  • Reactor Pattern: 1995threads are one of the bottlenecks for scaling
  • ÜberleitungzuNode.jsTwisted: Apple Calendar, NASA, Twilio …Node: LinkedIn, Walmart, Microsoft, Yammer, Browserling.MS: Azure Mobile Services uses Node in the Backend http://www.windowsazure.com/en-us/develop/mobile/
  • Node is simple. The learning-curve is not steep (if you accept JavaScript)Node embraces JavaScript (Devs, JSON, Browser-Platforms, Mobile)JavaScript is Event-Driven, non-blocking and single-threaded in the Client Node mixes runtime platform with application framework.-> This fits the cloud model
  • Event basierteprogrammier-model schlägvolldurch. KeineAbstraktion!Reading & Debugging (vs. sequential code)
  • JavaScript:Huge amount of Web-DevelopersJavaScript fits Event-Based Architecture (Single threaded Event-Loop in Browser), existing concepts and libraries can be reusedEvent-Based API is known by those developersSimple, easy to learnPerformant und skalierteinigermassenNode jumped into the space of real-time web applications. Mostly PHP Devs … on the edge of Web & Enterprise Übergang z vertx
  • 15’
  • Web-Server non blockingsiege -c100 -b -r100 "http://localhost:8081/?longrunning" Running_ From IDE, from commandline
  • Not really a framework, rather comparable with Tomcat or Jetty than with JSF or EJB
  • Verticles have their own classloaderMessages are passed by value
  • DEMO: Blocking WebServer
  • Most new functionality should be provided as modules
  • DEMO: Instances
  • BlockingScalingMessage Passing
  • 30’Event bus enables easy creation of real-time web applicationsMobile applications, gamesClint side library very small, can be used with any JS libraries
  • Distributed System very easy, same programming concepts
  • Building abstractionsAllowing long lived connections on a higher abstraction level than event-based APIs.
  • Loosely coupled Microservices
  • Vs. Real Time Computing- Receiver not known / ensured
  • vert.x - asynchronous event-driven web applications on the JVM

    1. 1. asynchronous event-driven web- applications on the JVM SBB Developer Day 2012 Jonas Bandi CompuGroup Medical @jbandi jonas.bandi@gmail.com
    2. 2. Agenda• Background / Motivation• Vert.x Platform• Demos
    3. 3. The Evolution of the WebStatic Form-driven AJAX-drivenPages applications applications
    4. 4. Static Form-driven AJAX-driven Real-timePages applications applications applications http://www.mmoasteroids.com/
    5. 5. The Real Time Web
    6. 6. http://wordsquared.com/
    7. 7. www.cloud9ide.com
    8. 8. The C10k Problem Its time for web servers to handle ten thousand clients simultaneously, dont you think? After all, the web is a big place now. (Dan Kegel, 2003)"Real-time will become the default. It wont be this newfangled tech that only Google and Facebook and Twitter can afford to build.” (ArsTechnica, 2012) http://en.wikipedia.org/wiki/C10k_problem http://www.kegel.com/c10k.htm http://arstechnica.com/business/2012/05/say-hello-to-the-real-real-time-web
    9. 9. ConnectionClient Request 1 Request 2 Request 3 Thread 1 Thread 2 Thread 1Server
    10. 10. Waiting … route process formatrequest results response query db or Write to web service log fileScaling:Problems: Context Switching, Stack Memory, Concurrency
    11. 11. Demo(Tomcat blocking on 100 concurrent longrunning requests)siege -c100 -b -r100 "http://localhost:8080/my-webapp/demo?blocking"
    12. 12. Addressing the Problem• event-driven / asynchronous architecture – Many long lived connections are a feature of modern applications – OS threads are a precious resource – Blocked OS threads are bad!• => Service many connections with a small number of threads• Reactor Pattern (Douglas C. Schmidt, 1995) – Event Loop• different programming model => on which abstraction? http://en.wikipedia.org/wiki/Reactor_pattern
    13. 13. Different Programming ModelClients delegate long Workers running jobs & IO Event Loop (single request thread, non blocking) callback response
    14. 14. ScalingThreads: Problems: Context Switching, Stack Memory, ConcurrencyEvent Loop: Async IO APIs (OS)
    15. 15. Established Solutions• Nginx• Jetty Infrastructure• Apache AWF• EventMachine (Ruby) Application• Tornado, Twisted (Python) Frameworks• Node.js (JavaScript)
    16. 16. Success of Node• Written in JavaScript, based on V8• Huge community & ecosystem• DIRTy Applications: Data Intensive Real Time• Mostly IO• Shuffling data from one pipe to another
    17. 17. Meet
    18. 18. Demo (vert.x not blocking on 100concurrent longrunning requests) siege -c100 -b -r100 "http://localhost:8081/?longrunning"
    19. 19. What is vert.x?• General purpose application platform on the JVM• Provides primarily asynchronous APIs• Polyglot: Java, JavaScript/CoffeeScript, Groovy, Ruby, Python• Simple but not Simplistic• Popular for “modern” web applications• Similarities with Node.js & Akka• New approach to problems traditionally served by classic application servers
    20. 20. The Vert.x Project• Open-source (on Github, ASL 2.0)• Age: ~1.5 years• Sponsor: VMWare• Based on: Netty, Hazelcast, SockJS sockjs Rhino
    21. 21. Core APIs• TCP/SSL clients and servers• HTTP/HTTPS clients and servers – including WebSockets• Event bus• File system• 100% asynchronous
    22. 22. Verticle 3 Background Workers Verticle 3 Verticle 3Architecture Verticle 3 Verticle 3 Vertx Instance Event Bus Module JVM Verticle 2 Verticle 2 Event Loop Verticle 2 Verticle 1 Verticle 1
    23. 23. Scaling• Scale by creating more Verticle instances• Use message passing to communicate• Fine-tune “pools” of verticles• For TCP and HTTP servers Vert.x does automatic load-balancing
    24. 24. Event Loops are no Silver Bullet• Don’t block the event loop!• Long running calculations• Blocking APIs (i.e. JDBC)• Most traditional Java libraries have blocking APIs• => Hybrid Threading Model – Worker Verticles can block – Communication by message passing (Event Bus) – Leverage ecosystem of Java libraries
    25. 25. Concurrency Model• A verticle instance is always single-threaded• Very different approach from “Java-Style” multi-threaded concurrency – No more synchronized, volatile or locking – Avoid many classic race conditions
    26. 26. Event Bus Demo Vertx Instance Event Loop Background Workers Worker Worker Worker Worker WorkerServer Server Event Bus JVM
    27. 27. Distributed Event Bus• Connect multiple Vert.x JVM instances• Applications are loosely coupled components distributed across the network• Event bus extends to client side JavaScript• Use the same API on the client• Distributed event space spans client and server nodes• Ideal for modern “real-time” web applications
    28. 28. Distributed Event Bus DemoVertx Instance Vertx Instance TelnetEvent Loop Event Loop Workers Browser (JavaScript) WebSocket TCP Server HTTP & Worker Worker Server Event Bus JVM JVM
    29. 29. Web Application Demo Vertx Instance Module Module ModuleBrowser vertx. vertx. vertx. web-server aut-mgr mongo- Mongo DB persistor(WebSocket) Event Bus JVM
    30. 30. The Future• Scala & Closure support• Management, including GUI console• Developer experience – IDE integration, testing• Promises API?• Direct-style API using continuations?
    31. 31. Summary • Polyglot – use the language(s) you want • Simple concurrency – wave goodbye to most race conditions • Leverage existing Java library ecosystem • Powerful distributed event bus which spans client and server • Powerful module systemVert.x is the platform for a new generation of polyglot web and enterprise applications.
    32. 32. Vert.x vs. Node.JS Polyglot vs. JavaScript JVM vs. V8huge ecosystem of big ecosystem of vs. Java libraries node modules small community vs. big community
    33. 33. The big picture• Alternative approaches (Java): – Servlet 3.0 – NIO connections
    34. 34. Who is using it? game-gorilla.com gvmtool.net Helsinki Trip Planner
    35. 35. Would I use it now?• Maybe -> where the distributed architecture really fits• Might get interesting in the future…• I don’t buy the polyglot story…• I don’t fully buy the concurrency story …
    36. 36. Discussions?

    ×