Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Advice needed (long, sorry)

Sorry Michael, I think I misunderstood you. So.. you are using load balancer not to balance between different mosquittos but to balance between differents http servers to get the adress of the endpoint mosquitto itself? Ummm sound interesting.

Then you:

- Request the HTTP server through the load balancer.
- The HTTP server responses givin information about the Mosquitto that has to be used (based on the selected criteria).
- The client app connect to that Mosquitto.

We should do:

- Choose (from the backend) the Mosquitto we want the user to connect to next time if it is not connected at this moment. And send notifications to that Mosquitto. How? Doing some predictive algorithm that does not matter now.
- the app will request the HTTP server through the load balancer.
- The HTTP server responses giving information about the Mosquitto that has to be used.
- The client app connect to that Mosquitto.

It could works!! We will explore this, of course. need to know how to handle failovers and things like that.

Thanks!!



2015-02-12 0:12 GMT+01:00 Laing, Michael <michael.laing@xxxxxxxxxxx>:
Our clients hit the load balancer initially (ELB on AWS in our case), but with an initial http request (mosquitto can serve these) to the which the node replies with its actual endpoint. The client 'sticks' to that endpoint for its session.

The node feeds the ELB with its load so the ELB can choose the least-loaded one.

ml

On Wed, Feb 11, 2015 at 5:50 PM, Manuel Domínguez Dorado <manolodd@xxxxxxxxx> wrote:

Hi, thank you.

we have not tried redis. We could try it. But we tried multiple Mosquittos behind haproxy loadbalancing connections to the less occuped broker (instead of roundrobin). There is a problem: as we need persistence (clear session = false), after a disconnection several messages were retained in the broker and the user not allways reconnect to the same broker and therefore the broker cumulates lots of messages that are not longer valid  and the client does not receive them after reconnecting. We tried using a brokers frontend line (5 brokers) bridging to a central one. Also, having only the frontend line. But persisted messages are a problem because of sessions, that are exclusive of a single mosquitto.

Maybe it would be good a hook to allow session migration between Mosquittos.

I've also do some proofs having only a Mosquitto with several listener and haproxy roundrobin on their ports. But we did not notice that things went better.

We'll read more about redis. Thank you so much.

Hi Manuel, I agree with Stefano - done a lot of detailed work 

Just though of an option - never tried it but maybe worth while looking into using Redis with more than one mosquitto instance - using HAPraox as load balancing you can run say 3-5 mosquttos with a redis layer behind mosquitto ....so in short HA --> Mosquitto --> Redis <-- other sub/pub on server side.....



On Wed, Feb 11, 2015 at 11:47 PM, Stefano Costa <stefano.costa@xxxxxxxxxxx> wrote:

> Il giorno 11/feb/2015, alle ore 22:15, Manuel Domínguez Dorado <manolodd@xxxxxxxxx> ha scritto:
>
>
> Could you give us some advice on how to improve these numbers at least to be able to reach our 100K users? We don't know, but maybe 20K concurrent connections are enough to support 100K users that are not connected at the same time.

Hi Manuel, it seems to me that you studied all details very well, good architecture as a starting point. But in order for people here to give useful advices I suspect that an important detail is missing: apart from "connected" and "existing" users, what's the messages rate you expect to have per user / per second (or minute, hour) under normal conditions and maximum?
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev


_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev




--
---
Manuel Domínguez Dorado
ingeniero ARROBA ManoloDominguez PUNTO com
http://www.ManoloDominguez.com

Back to the top