Knocking Out the “Heavyweight” Label of XMPP- The Need for Commercial Deployment

Published: Wed 07 Aug 2013
A blog entry by Michael Holdmann

Contributed by:

Michael Holdmann
EVP | Strategy | Alliance
Coversant, Inc.

Michael Holdmann's Blog

I am a vocal advocate of Open Source, being a founding member with my last company of the Open Source for America Foundation and creating a secure desktop environment using portable applications technology.

Regarding XMPP server offerings, commercial platform deployment is necessary for true scalability. There are deployments using open source platforms (XMPP server software) that achieve 8,000 concurrent connections[i] and others touting 7,000 users per cluster.

With commercial platforms, benchmarks of 240,000 concurrent connections, 120,000 messages per second, (single 2x4core, 16gb and 10gb nic) sending 1k messages (not 1-byte messages that IBM likes to test for MessageSight benchmark). The challenges faced by the developers to enable XMPP to compete with pub/sub only protocols (with all the added benefits of security, advanced presence processing, SOA 2.0 and ESB functionality) and solutions that were deployed are overviewed in this post (Table 2).

White papers, other than the one I co-wrote, will be coming from a standards body that is adding XMPP into its protocol stack. The test included one commercial server against two open source servers, the results are below (Table 1). A second paper to be released overviewing a project of a cable operators attempt to create a scalable XMPP RDM platform for 2.5 million set-top boxes, unable to achieve until discovering a commercial XMPP platform, the project will be completed on 25 servers. There is a current HVAC RDM network that consists of 200,000+ buildings with 125-1500 devices per building that is running on an XMPP backbone (~ 10 servers) communicating Backnet, MODBUS, OBIX and Lonworks device data back to the NOC with all control commands being sent back to the devices bidirectionally over the same tunnel.

My stance has nothing to do with OS or other open source software, just the XMPP server. I do not believe in bloat, software or hardware, which is why I have such passion for XMPP. XMPP allows the collapse networking, security, access control, SOA 2.0, ESB and communications into one platform all because of a protocol and puts full control in the hands of the developer.

Comparisons- XMPP Transport of Binary

Performance was evaluated by setting up an Industrial Automation Standards Body UA and then calling the Read service for 100 integer values. The XMPP server was running on a cloud based Windows Server 2008 R2 accessed via a 2 Mbps Internet connection. The Industrial Automation Standards Body client and server were running on the same machine. The security policy is Basic128Rsa15 in all cases.

Table 1

ProductStanza TypeAverage Per Call (ms)Max Per Call (ms)Min Per Call (ms)
Binary (cloud) 1n/a8935470
Binary (local)2n/a251
OpenFireMessage336950342268
OpenFireIQFailedFailedFailed
Commercial ServerMessage159374143
Commercial ServerIQ197213188
Ejabberd3Message202125581617
Ejabberd3IQ398563913332

1 Industrial Automation Standards Body server was running on the same machine as the XMPP server.

2 Industrial Automation Standards Body server was running on the same machine as the Industrial Automation Standards Body client.

Ejabberd was running on a VM running on the same machine as the Industrial Automation Standards Body client and server.

The binary (Cloud) test only required one hop to get to the server. The XMPP tests required two hops to get from the Industrial Automation Standards Body client to the XMPP server and then on to the Industrial Automation Standards Body server. This means that the basic network I/O of the Commercial Server is comparable to Industrial Automation Standards Body UA and the performance numbers are likely limited by the network and/or the International Industrial Automation Standards Body implementation.

Challenges and Solutions

Table 2

Challenge

Solution

Telcom-Grade System Scalability
  • Difficult to exceed 10k concurrent on single server
  • Very difficult to exceed 50k concurrent on single server
  • Hard to test >50k concurrent presentities
  • Hard to retain enterprise class easy installation
Extreme System Scalability
  • Single server scalability tested at >250k concurrent
  • Clustering scalability expected to reach telecom scales (10 million users with < 100 servers)
  • Highly scalable command and control “bot” network for telecom scale tests
Thread and CPU Architecture and Tuning
  • Managing thread pools and locking models
  • Tune, profile, and test at high scales
  • Tune for single, multi-core, and multiple processors
  • Tune for x86, x64, and IA64
Advanced Internal Architecture
  • Proprietary thread pool and locking model
  • Extremely efficient pattern for concurrent I/O
  • Extensive testing, tuning, and profiling
  • Designed and optimized for x86, x64, and IA64
  • Optimized for single and multi-core AMD/Intel CPUs
Socket and Memory Management
  • Break 50k socket barrier
  • Highly scalable cross-platform asynchronous I/O
  • Garbage collection tuning
  • Optimize memory use to increase sockets
Tuned Memory Profiles
  • Low heap fragmentation and compaction
  • Highly tuned load anticipating algorithms
Active/Active Clustering
  • Hard to avoid condensers, load balancers, or COTS clustering tools to maintain low TCO and footprint for greater distribution options
Distributed Active/Active Clustering
  • Use of DNS for clustering
  • Full load balancing and high availability
  • Built-in client redirection
  • Server-to-server mesh network over HTTP, HTTPS, TCP, and Named Pipes
  • No need for condensers, load balancers, or COTS clustering tools
Reduce Footprint and Components
  • Reduce footprint of presence engine
  • Reduce external dependencies
  • Distributed management of configuration
  • Delivery to tiny core presence engine
Low Profile Presence Engine
  • Single presence engine service (no dependencies)
  • Ultra low footprint single class presence engine
  • Add or remove capabilities (they are extensions)
  • Numerous integration options to reduce installation size, customize, or integrate
Distributing Integrations
  • Custom distributed presence engine administration
  • Distributed product development platform
  • Deployment options with customization
  • High performance in process integrations
  • Distributed out-of-process integrations
  • Pervasive presence
Robust Distributed Integration
  • High performance in process integration and distributed out-of-process integration using server extension SDK
  • Distributed management with administration SDK
  • Presentity solutions with several presentity SDKs
Distributing Single Domains
  • Geographically distributed servers for one domain
  • Synchronization of presence information
Clustering Across Geographies
  • Presentities directed to local server
  • Distributed presence caching
Managing Numerous Domains
  • Managing thousands of servers with different domains
  • Isolating management and integration
Virtual Presence Engines
  • Multiple virtual presence engines per presence engine
  • Independently configurable and manageable
  • Isolated management and integration
  • Tested up to 1000 virtual servers on one server
Distributed Integration
  • Time to market of cross platform integration SDKs
  • Maintainability of multiple code bases
  • Handling development with multiple technologies
8 SDKs for Distributed Integration
  • Five presentity SDKs target nearly all platforms
  • Two server side SDKs for server side integration
  • One new client framework for multi-modal plans
  • Advanced distributed trace for distributed development
  • Distributed exceptions for distributed development
  • Development on .NET providing cross language support
  • Development for Mono providing cross platform support

In 2010, Gartner predicted that XMPP would be the standard of communication over the internet by 2015 based on the projected onslaught of devices.[ii] The advanced and unmatched functionality of the protocol that makes it the proper choice of the IoT and M2M is also the reason for the main use being Chat between humans and under deployment of the protocol for machine communications, the “heaviness” of the protocol. With proper development/optimization of the core engine that runs XMPP, the myths can be dispelled and XMPP can take its place as not the protocol of IoT, rather the protocol for “federation” of all the different protocols (data or communications) of IoT. XMPP achieves decreased infrastructure, collapsing SOA, ESB, Communications; reduction in appliances, (load balancing, routers and switches); OPex (heat, space, power); increased security allowing Layer 7 control and forward lowering TCO and achieving a smaller carbon footprint.

This is the real objective of IoT, “Create a more efficient world with less”.


[i] Peter Offringa, VP of engineering at Zoosk. Zoosk - The Engineering Behind Real Time Communications

[ii] Smith, David Mario. Take Four Steps to Prepare for XMPP Becoming a Universal Standard, Gartner, 28 November 2010.