Performance Evaluation of XMPP on the Web
•
10 likes•6,138 views
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ä
Report
Share
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Performance Evaluation of XMPP on the Web
Similar to Performance Evaluation of XMPP on the Web (20)
More from Markku Laine
More from Markku Laine (10)
Recently uploaded
Recently uploaded (20)
Performance Evaluation of XMPP on the Web
- 1. Performance Evaluation of XMPP on the Web Markku Laine and Kalle Säilä Dept. Media Technology, Aalto University Finland T-106.4000 Laboratory Course in Software Techniques Mini Conference April 25, 2012
- 2. Presentation is about... Real-time communication techniques on the Web Extensible Messaging and Presence Protocol (XMPP) Network performance evaluation 2
- 3. Presentation Outline Introduction Experiments Results Conclusions and future work 3
- 4. Introduction 4
- 5. Extensible Messaging and Presence Protocol (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. 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. Three Different Techniques to use XMPP on the Web • Jabber HTTP Polling (XEP-0025) • XMPP over BOSH (XEP-0206) • XMPP sub-protocol for WebSocket 7
- 8. Three Different Techniques to use XMPP on 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. Experiments 9
- 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. 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. 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. 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. Results 14
- 15. Network Overhead 15
- 16. Frame Components 16
- 17. Frame Components 17
- 18. Total Network Overhead 18
- 19. Technique Network Overhead 19
- 20. Technique Network Overhead Polling vs. WebSocket: 7 times more overhead BOSH vs. WebSocket: 9 times more overhead 20
- 21. Round Trip Rate 21
- 22. Median Round Trip Rate 22
- 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. Message Receive Rate: Server to Client 24
- 25. Median Message Receive Rate 25
- 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. Conclusions and Future Work 27
- 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. 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. 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. 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