Re: [jdev] Using chat room as resource pool -- need advice
On Fri, 2006-02-17 at 08:42 -0500, Matthew Wilson wrote: > Bruce, thanks for the feedback. I'm a big fan of your film career as well ;) Haha, I'll echo that! Big fan. "Then let's head down into that cellar and carve ourselves a witch." Ash -travis
Re: [jdev] Using chat room as resource pool -- need advice
Bruce, thanks for the feedback. I'm a big fan of your film career as well ;).
Re: [jdev] Using chat room as resource pool -- need advice
On Mon, 13 Feb 2006, Matthew Wilson wrote: We have a bunch of boxes (20 or so) that offer web-services to our server farm of several hundred boxes. Right now, if a box on a farm needs to connect to one of the web service boxes, it iterates through a list of all the web-service boxes, and tries to connect to each one, until it finds one that is free to handle the request. Yick. Your current selection method sucks. I'm thinking that a better model might be to create a MUC where each of the web-service boxes are persistently connected. They would use their presence attribute to indicate whether they are available or busy. I'd prefer that the clients and servers communicate through the room, rather than directly, so that I can just log the chat room and see all the transactions. I'd avoid the MUC (central dependency) and rely on Jabber servers on a few boxes to establish inter-server connections. A few questions: * Is this asinine? It depends on the application really. * Has anyone done anything like this? Yes. Code is even available[1]. Are there any hidden gotchas you discovered? Essentially, you are wanting to use Jabber as a method to select the 'most' available host. Now, whilst you can do this, and it will work, there are three gotchas: a) Jabber has high latency compared to dedicated methods: The time for each web server JID to report back its process state to the chat room/other JIDs may well be longer than the time to process the request; any such information may well be out of date. b) Jabber has high latency compared to dedicated methods: The time taken to receive the roster on each connection may well be longer than the client wishes to wait. If you do implement this, do not connect to Jabber each time you wish to find an appropriate server; maintain persistent connections and write the current 'best' choice to a known file or socket. c) Jabber is object based, not stream based: The fundamentals of Jabber are packets, and before any Jabber-processing does anything with the packet, it needs to have the full packet in its grubby little hands. Thus, sending the web request via Jabber and expecting to receive a timely reply is somewhat foolish. In the situation you have described, you would be better served by avoiding Jabber; put a web load balancer in front of your web farm. -- Bruce Campbell [1] I have proof of concept code available privately that sends received web requests via Jabber off to a master JID and waits for replies via Jabber, but the gotchas described above really kill the performance.
RE: [jdev] Using chat room as resource pool -- need advice
We actually have at least one customer that uses XMPP and presence for load balanced and redundant services, but they built their applications from the ground up with this in mind. However, as Hal said, use a load balancer made for HTTP. :) NLB in Windows does a great job. I'm sure there are equally free technologies for the *nix world as well. -JD Conley > Right. And if that is too expensive, you can use software load > balancing (such as Windows NLB /WLBS). I think using XMPP for this > would be unwise. > > On 2/13/06, Paul Clegg <[EMAIL PROTECTED]> wrote: > > >From your description, it seems that a hardware load balancer in front > of > > your web service farm would do this job easily and transparently. > > > > -Paul > > > > > > On 2/13/06, Matthew Wilson <[EMAIL PROTECTED]> wrote: > > > We have a bunch of boxes (20 or so) that offer web-services to our > > > server farm of several hundred boxes. Right now, if a box on a farm > > > needs to connect to one of the web service boxes, it iterates through > > > a list of all the web-service boxes, and tries to connect to each one, > > > until it finds one that is free to handle the request. > > > > > > I'm thinking that a better model might be to create a MUC where each > > > of the web-service boxes are persistently connected. They would use > > > their presence attribute to indicate whether they are available or > > > busy. > > > > > > When one of the farm boxes needs to make a request, it would connect > > > to the chat, get the presence info for all the web-service boxes, and > > > then choose one of the available servers to send a request to. > > > > > > In order to send the request, I figured the client could send a > > > message to the room and specify in the message which server process it > > > is sending the request to. > > > > > > At this point, the server would > > > * update its presence to busy; > > > * handle the request; > > > * put a message back into the chat room, with the request results; > > > * update its presence to available > > > > > > I'd prefer that the clients and servers communicate through the room, > > > rather than directly, so that I can just log the chat room and see all > > > the transactions. > > > > > > A few questions: > > > * Is this asinine? > > > * Has anyone done anything like this? Are there any hidden gotchas > > > you discovered? > > > * Is there any reason to mix in some jabber-RPC? > > > > > > All advice is appreciated. > > > > > > > > > > -- > Psi webmaster (http://psi-im.org) > im:[EMAIL PROTECTED] > http://halr9000.com
Re: [jdev] Using chat room as resource pool -- need advice
Right. And if that is too expensive, you can use software load balancing (such as Windows NLB /WLBS). I think using XMPP for this would be unwise. On 2/13/06, Paul Clegg <[EMAIL PROTECTED]> wrote: > >From your description, it seems that a hardware load balancer in front of > your web service farm would do this job easily and transparently. > > -Paul > > > On 2/13/06, Matthew Wilson <[EMAIL PROTECTED]> wrote: > > We have a bunch of boxes (20 or so) that offer web-services to our > > server farm of several hundred boxes. Right now, if a box on a farm > > needs to connect to one of the web service boxes, it iterates through > > a list of all the web-service boxes, and tries to connect to each one, > > until it finds one that is free to handle the request. > > > > I'm thinking that a better model might be to create a MUC where each > > of the web-service boxes are persistently connected. They would use > > their presence attribute to indicate whether they are available or > > busy. > > > > When one of the farm boxes needs to make a request, it would connect > > to the chat, get the presence info for all the web-service boxes, and > > then choose one of the available servers to send a request to. > > > > In order to send the request, I figured the client could send a > > message to the room and specify in the message which server process it > > is sending the request to. > > > > At this point, the server would > > * update its presence to busy; > > * handle the request; > > * put a message back into the chat room, with the request results; > > * update its presence to available > > > > I'd prefer that the clients and servers communicate through the room, > > rather than directly, so that I can just log the chat room and see all > > the transactions. > > > > A few questions: > > * Is this asinine? > > * Has anyone done anything like this? Are there any hidden gotchas > > you discovered? > > * Is there any reason to mix in some jabber-RPC? > > > > All advice is appreciated. > > > > -- Psi webmaster (http://psi-im.org) im:[EMAIL PROTECTED] http://halr9000.com
Re: [jdev] Using chat room as resource pool -- need advice
>From your description, it seems that a hardware load balancer in front of your web service farm would do this job easily and transparently.-PaulOn 2/13/06, Matthew Wilson <[EMAIL PROTECTED]> wrote: We have a bunch of boxes (20 or so) that offer web-services to ourserver farm of several hundred boxes. Right now, if a box on a farmneeds to connect to one of the web service boxes, it iterates througha list of all the web-service boxes, and tries to connect to each one, until it finds one that is free to handle the request.I'm thinking that a better model might be to create a MUC where eachof the web-service boxes are persistently connected. They would usetheir presence attribute to indicate whether they are available or busy.When one of the farm boxes needs to make a request, it would connectto the chat, get the presence info for all the web-service boxes, andthen choose one of the available servers to send a request to. In order to send the request, I figured the client could send amessage to the room and specify in the message which server process itis sending the request to.At this point, the server would * update its presence to busy; * handle the request; * put a message back into the chat room, with the request results; * update its presence to availableI'd prefer that the clients and servers communicate through the room,rather than directly, so that I can just log the chat room and see all the transactions.A few questions: * Is this asinine? * Has anyone done anything like this? Are there any hidden gotchasyou discovered? * Is there any reason to mix in some jabber-RPC? All advice is appreciated.
