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
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
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
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
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