Hi, Im looking for large scale deployments to use in a talk.

[Simen Sommerfeldt]

I´m giving an MQTT evangelism talk on internetofthingsday.com this Thursday.

It would give my talk more punch if I can mention other large-scale deployments than Facebook. 

I will of course credit all sources and share the presentation on slideshare.  

[Thomas]

Facebook messenger allegedly uses MQTT. have a google around.

[Laing, Michael]

Hmmm - we are in the early stages of adding MQTT to the NYTimes fabrik.

The current fabrik supports the capabilities of MQTT for endpoints, but using our own semantics and code.

We run a meshed, autoscaling AMQP backbone using RabbitMQ in multiple AWS regions and zones. The persistence layer is Cassandra. The retail layer is over WebSocket/SockJS. We only have millions of users and many millions of messages - so not facebook scale...

MQTT provides a standard paradigm that may relieve us of some technical debt and extend our service to more endpoints - and make it easier to add some new capabilities to the fabrik.

We may also add some extensions, e.g. TTL, to fully support and extend the current fabrik functionality.

Not even near production - shooting for mid-2015. Hope the boss agrees... :)

Michael Laing

Systems Architect

NYTimes

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Joel J. Bender]

Following up with what Michael Laing wrote:

> Hmmm - we are in the early stages of adding MQTT to the NYTimes fabrik.

We are also in the early stages of adding MQTT to our campus-wide building automation supervisory system (about 12,000 devices and a little less than a million points).

> MQTT provides a standard paradigm that may relieve us of some technical debt and extend our service to more endpoints - and make it easier to add some new capabilities to the fabrik.

Exactly the same here (more specifically MQTT-SS), we need to provide a communications platform that makes it easier to build fault detention and diagnostic software, as well as a micro scale smart grid.

> The current fabrik supports the capabilities of MQTT for endpoints, but using our own semantics and code.

It would be nice if there was a standard for the data portion of messages, and until there is a better consensus, we'll be using BACnet binary encoding.

> We run a meshed, autoscaling AMQP backbone using RabbitMQ in multiple AWS regions and zones. The persistence layer is Cassandra.

Good to know I'm not completely off my rocker for going in the same direction, thank you! Our persistence layer will be Redis, we already have an existing database for trend data.

> The retail layer is over WebSocket/SockJS. We only have millions of users and many millions of messages - so not facebook scale...

We have no users, and not so many messages yet :-).

> Not even near production - shooting for mid-2015. Hope the boss agrees... :)

Ibid.



Joel Bender
Building Automation and Control Systems Integration
Cornell University

[Simen Sommerfeldt]

I have posted my presentation here: http://www.slideshare.net/simensommerfeldt/supercharge-your-iot-project-with-mqtt-and-nodered. Vimeo recording to come. Thanks for the input

[Shih YuLun]

Nice sharing!

I am excited to see there's someone use MQTT as inter-process communication like what I did.

Simen Sommerfeldt於 2014年11月6日星期四UTC+8下午11時15分48秒寫道：

[Stefano Costa]

On 06/11/2014 16:15, Simen Sommerfeldt wrote:
> I have posted my presentation here:
> http://www.slideshare.net/simensommerfeldt/supercharge-your-iot-project-with-mqtt-and-nodered.
> Vimeo recording to come. Thanks for the input
>

Thanks a lot Simen! Great presentation.

[RoyHB]

My company is operating a node.js based application (an AIS Switch) that accepts message inputs from external tcp/ip servers (or clients), filters them by various criteria, archives some of them in a database and sends them out to different external tcp/ip clients or servers.

We're currently processing about 25.000,000 input messages per day and more output messages (since some inputs route to more than one output).

All IPC uses mqtt to route messages between various input / filter / output modules.  We use the node-mqtt client module.

The particular application is receiving marine AIS messages from satellite and terrestrial feeds and routing them to message consumers, who register their interest based on position and other criteria.

This all (touch wood) runs very reliably without any human intervention for weeks or months at a time.  The broker has only ever been restarted when the server is rebooted for some unrelated reason.

The previous generation of the system also used mqtt but was implemented in Python rather than node.
We're using a single Mosquitto broker.   For a period we tried the HiveMQ broker and it also proved quite reliable and has a few features that could be useful to some applications.  We reverted to Mosquitto because we formed a subjective view that Hive (running as a Java app) consumed slightly more CPU per message which added up with our message volume and we didn't need the extra features that Hivemq provides.

Our system runs using about 34-45% cpu and < 1 GB of memory on a AWS EC2 dual xeon virtual server running Ubuntu 14.

Cheers;

Roy Barkas
Australia

[Simen Sommerfeldt]

Thanks! 

[Simen Sommerfeldt]

Here's the video from the presentation: Link to vimeo