Performance Evaluation of XMPP on the Web

5,271 views

Published on

Our presentation for the report "Performance Evaluation of XMPP on the Web". 2012.
by Markku Laine, http://www.tinyurl.com/mplaine, and Kalle Säilä

Published in: Technology

Performance Evaluation of XMPP on the Web

  1. 1. Performance Evaluation ofXMPP on the WebMarkku Laine and Kalle SäiläDept. Media Technology, Aalto UniversityFinland T-106.4000 Laboratory Course in Software Techniques Mini Conference April 25, 2012
  2. 2. Presentation is about... Real-time communication techniques on the Web Extensible Messaging and Presence Protocol (XMPP) Network performance evaluation 2
  3. 3. Presentation Outline Introduction Experiments Results Conclusions and future work 3
  4. 4. Introduction 4
  5. 5. Extensible Messaging and PresenceProtocol (XMPP)•  XML-based, open-standard communications protocol for real-time applications –  XMPP is an application-level protocol•  Originally developed for simple chat applications (users, presence, and messages) under the name Jabber –  Now, over 300 XMPP Extension Protocols (XEPs) for a wide variety of application scenarios (e.g., publish-subscribe, peer-to- peer file transfer, and multi-user chat)•  Core standardized by the Internet Engineering Task Force (IETF)•  Widely used outside the Web 5
  6. 6. XMPP Communication•  Decentralized client-server architecture•  Two-way, full-duplex channel between the client and the server (two XML streams over a single TCP socket) 6
  7. 7. Three Different Techniques to use XMPPon the Web•  Jabber HTTP Polling (XEP-0025)•  XMPP over BOSH (XEP-0206)•  XMPP sub-protocol for WebSocket 7
  8. 8. Three Different Techniques to use XMPPon the Web•  Jabber HTTP Polling {identifier};{key},! <message to="{username}@{domain}">! (XEP-0025) <body>{payload}</body>! </message>! <body rid="{rid}” sid="{sid}” key="{key}" xmlns="http://jabber.org/protocol/httpbind">•  XMPP over BOSH <message to="{username}@{domain}"> <body>{payload}</body> (XEP-0206) </message> </body>!•  XMPP sub-protocol <message to="{username}@{domain}">! <body>{payload}</body>! for WebSocket </message>! 8
  9. 9. Experiments 9
  10. 10. Setup•  Server: Ejabberd XMPP server running on a MacBook Pro with a 64-bit OS X 10.6.8 operating system and a 2.53 GHz Intel Core 2 Duo CPU•  Client: Test clients running on an iMac with a 64-bit OS X 10.6.8 operating system and a 2.4 GHz Intel Core 2 Duo CPU –  Browser: Safari 5.1.5•  Network: 100/100 Mbit/s Local Area Network (LAN) –  Maximum Frame Payload Size: 15928 bytes (Jumbo Frame) •  In general, the Maximum Ethernet Frame Size is 1500 bytes 10
  11. 11. Network Overhead•  Goal: Find out how much example network traffic overhead <message to=”user@xmpp.org"> the techniques generate <body>hello world</body> </message> example POST /http-bind HTTP/1.1 Host: ksaila.local:5280 Content-Type: text/xml; charset=UTF-8 11
  12. 12. Round Trip Rate•  Goal: Find out the maximum rate in which the client can send messages to another client•  30 test runs per technique per payload (10, 100, and 1000 bytes payload) –  100 round trips per test run –  100 ms polling interval with Jabber HTTP Polling•  Tests were performed as a round trip from a client to the same client via the server (XMPP does not provide any ”message successfully delivered” information) –  The client was not allowed to send new messages before receiving the previous message 12
  13. 13. Message Receive Rate: Server to Client•  Goal: Find out the maximum rate in which a client can receive messages from other clients•  30 test runs per technique per payload (10, 100, and 1000 bytes payload) –  10000 messages per test run –  100 ms polling interval with Jabber HTTP Polling•  The messages were sent from a native XMPP client running on the server host machine (the traffic was monitored during the test runs to make sure that the send rate was way above the receive rate) 13
  14. 14. Results 14
  15. 15. Network Overhead 15
  16. 16. Frame Components 16
  17. 17. Frame Components 17
  18. 18. Total Network Overhead 18
  19. 19. Technique Network Overhead 19
  20. 20. Technique Network Overhead Polling vs. WebSocket: 7 times more overhead BOSH vs. WebSocket: 9 times more overhead 20
  21. 21. Round Trip Rate 21
  22. 22. Median Round Trip Rate 22
  23. 23. Bottlenecks•  Polling –  TCP connection renewal –  100 ms polling interval  max 9-10 round trips/second•  BOSH –  TCP connection renewal•  WebSocket –  Transmitted message payload size 23
  24. 24. Message Receive Rate: Server to Client 24
  25. 25. Median Message Receive Rate 25
  26. 26. Bottlenecks•  Polling –  Multiple messages sent within a single frame•  BOSH –  Multiple messages sent within a single frame –  Messages sent only after receiving a new request•  WebSocket –  Messages sent one per frame•  Transmitted message payload size•  Underlying network 26
  27. 27. Conclusions and Future Work 27
  28. 28. Conclusions•  HTTP ≠ real-time protocol•  XMPP = real-time protocol (outside the Web)•  Techniques to use XMPP on the Web 1)  Jabber HTTP Polling 2)  XMPP over BOSH 3)  XMPP sub-protocol for WebSocket•  Polling generates unnecessary network traffic•  Polling and BOSH can send multiple messages within a single frame•  WebSocket’s advantages are permanent TCP connection and extremely low overhead 28
  29. 29. Future Work•  Conduct an in-depth comparison of HTTP and XMPP•  Analyze real-world Web applications to obtain –  Use cases & requirements•  Expand experiments to cover –  10000 bytes message payload –  Different network environments (incl. wired and wireless) –  Secure connections –  Server CPU usage•  Automate test runs•  Evaluate in different real-world settings with real-world Web applications 29
  30. 30. Related Work•  Gutwin, C. et al. “Real-Time Groupware in the Browser: Testing the Performance of Web-Based Networking”. In Proceedings of CSCW’11, pages 167-176, 2011.•  Pohja, M. “Server Push for Web Applications via Instant Messaging”. In Journal of Web Engineering, Vol. 9, No. 3, pages 227-242, 2010.•  Griffin, K. and Flanagan, C. “Evaluation of Asynchronous Event Mechanisms for Browser-Based Real-Time Communication Integration”. In Proceedings of TDNEA’10, pages 461-466, 2010. 30
  31. 31. Thank you for your attention! Markku Laine Kalle Säilä M.Sc. (Tech.), Ph.D. student B.Sc. (Tech.), M.Sc. student markku.laine@aalto.fi kalle.saila@aalto.fi 31

×