[ejabberd] component scaling questions
arne at getorganyzd.com
Tue Dec 16 01:27:59 MSK 2008
Any reason why your new instances can't also be butler.buddycloud.com?
ejabberd will roundrobin requests to all components that are connected
as butler.buddycloud.com. The question is mostly whether you need some
kind of initial affinity. There are balancing rules that let you stick
requests by from or to jid for subsequent requests, but the initial
request will be delivered to a random component in the list.
On Dec 15, 2008, at 2:18 PM, Simon Tennant wrote:
> I posted on the jdev mailing list
> (http://www.jabberforum.org/showthread.php?t=1209) about how we name a
> component which we may potentially have very many of.
> I want to take our location service, butler.buddycloud.com, and
> potentially have butler001.buddycloud.com butler002.buddycloud.com etc
> all running in simultaneously and spreading the load amongst multiple
> compute hosts.
> Then using a disco request, clients would randomly pick a server to
> We are currently a single ejabberd server setup to cover
> Is there anything I should be aware of when thinking about this kind
> component distribution? We plan on, in the not too distant future,
> moving to a number of ejabberd servers all serving buddycloud.com.
> Would it then be a case of:
> server1 with butler001.buddycloud.com & butler002.buddycloud.com
> server2 with butler003.buddycloud.com & butler004.buddycloud.com
> What would happen if a client connects to server2 and issued a disco
> request? Would they see all "butlers" or just 003 and 004?
> Trying not to be painted into a scalability corner.
> Simon Tennant _____________________________________________
> fixed: .uk +44 20 7043 6756 .de +49 89 420 955 854
> mob: .uk +44 78 5335 6047 .de +49 17 8545 0880
> xmpp: simon at buddycloud.com
> ejabberd mailing list
> ejabberd at jabber.ru
More information about the ejabberd