Dominik,
thanks for your comments. I agree with you entirely.
I definitely think there is an interest in a highly scalable MQTT
client for load testing MQTT servers. I know several projects who
have written their own MQTT load testing clients.
One approach I have taken in the past is to network RSMBs together
with their bridges: one RSMB bridging to 500 others, each with 500
bridge connections to the MQTT server under test. That means you
can easily spread out the second-level RSMBs over several machines
if you need to, and I could build it very quickly. That approach
should work with Mosquitto too.
As I see it, the only potential risk of contributing your client is
confusion about which to use, which could be minimized by putting it
under "tools", "utilities" or a similar category. Personally, I
would be very happy to see the contribution.
Ian
On 09/04/2014 04:15 PM, Dominik
Obermaier wrote:
Ian,
I don't think Paho Clients are and should be highly scalable. I
personally are in favor of having rock-solid MQTT clients for
real-world productive usage. So from my point of view, 3) can be
dropped and be replaced with the mission goal of having
production-ready rock-solid clients.
We have written several load tests with different approaches and
the truth is, that we always had to write our own MQTT clients for
that. Speaking of Java clients, there is the fusesource-mqtt
client which is more scalable than the Paho Java implementation
but it has many concurrency bugs when using under load, so I
always recommend using Paho.
If there is interest for such a highly scalable and concurrent
implementation of a Java MQTT client with a nice fluent API, we
would consider bringing it to the Paho project. Beside the nice
fluent API, this MQTT client also has a "low-level" interface for
doing things like sending "raw" MQTT messages, which may be useful
for testing the behaviour of MQTT servers. So you can for instance
emulate faulty MQTT client behaviour with that. This client
unfortunately doesn't run on Android (afaik) and needs at least
Java 5. So I would not see a competing MQTT Java client to the
current Paho one but a complementary one for testing tool
implementations. Internally we're using this library heavily for
our HiveMQ integration and specification tests and for distributed
load tests.
Best,
Dominik
Ian Craggs wrote:
Hello all,
just scanning the web page, I noticed it describes three
attributes of Paho:
1) for constrained networks
2) devices and embedded platforms
3) highly scalable
where 3) is described as:
Paho focuses on highly scalable implementations that will
integrate with a wide range of middleware, programming and
messaging models.
I agree with the first two, but is it really true that Paho
implementations are or should be highly scalable? What does
this really mean? Several times I have heard of people wanting
to create load tests for their MQTT server, but as far as I am
aware none of the Paho libraries is specifically designed for that
purpose. While they may be capable of doing so, their design is
not likely to be optimal. When I am writing a client-side
library, the highest priority is usually making it small.
This claim might give rise to expectations which we can't
fulfil, unless anyone has a different interpretation? If so, I
think we need to explain.
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, Mosquitto
|
