performance evaluation of xmpp on the web
DESCRIPTION
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äTRANSCRIPT
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
Presentation is about...
Real-time communication techniques on the Web Extensible Messaging and Presence Protocol (XMPP) Network performance evaluation
2
Presentation Outline
Introduction Experiments Results Conclusions and future work
3
Introduction
4
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
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
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
Three Different Techniques to use XMPP on the Web
8
{identifier};{key},!<message to="{username}@{domain}">! <body>{payload}</body>!</message>!
<message to="{username}@{domain}">! <body>{payload}</body>!</message>!
<body rid="{rid}” sid="{sid}” key="{key}" xmlns="http://jabber.org/protocol/httpbind"> <message to="{username}@{domain}"> <body>{payload}</body> </message> </body>!
• Jabber HTTP Polling (XEP-0025)
• XMPP over BOSH (XEP-0206)
• XMPP sub-protocol for WebSocket
Experiments
9
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
Network Overhead
• Goal: Find out how much network traffic overhead the techniques generate
11
<message to=”[email protected]"> <body>hello world</body> </message>
POST /http-bind HTTP/1.1 Host: ksaila.local:5280 Content-Type: text/xml; charset=UTF-8
example
example
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
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
Results
14
Network Overhead
15
Frame Components
16
Frame Components
17
Total Network Overhead
18
Technique Network Overhead
19
Technique Network Overhead
20
Polling vs. WebSocket: 7 times more overhead
BOSH vs. WebSocket: 9 times more overhead
Round Trip Rate
21
Median Round Trip Rate
22
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
Message Receive Rate: Server to Client
24
Median Message Receive Rate
25
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
Conclusions and Future Work
27
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
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
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
Thank you for your attention!
31
Kalle Säilä B.Sc. (Tech.), M.Sc. student
Markku Laine M.Sc. (Tech.), Ph.D. student