Thanks Alex, I see, so if app0, app1 and app2 are on different machines and say the first request from the client hits app0, and app0 forks a process to handle the session with the client. I presume that the subsequent requests from the client would somehow be routed to app0 - correct? if so, how is that guaranteed?
Regards, Kashyap On Fri, Jun 7, 2019 at 8:32 AM Alexander Burger <a...@software-lab.de> wrote: > Hi Kashyap, > > > This is the definition of loadbalancing from > > https://www.nginx.com/resources/glossary/load-balancing/ > > OK, that's what I thought of. > > > > [image: image.png] > > Thanks for the nice picture :) > > > > This is not a static system. The argument being that the database could > > have different read and write throughputs and you can potentially server > a > > large number of reading clients by doing this kind of load balancing. > (app > > 0, 1 and 2 are identical instances). I hope this clarifies. > > There are several ways to implement such a setup. > > It is no problem to put app0, app1, app2 etc. on different machines, but I > think > these are not the bottlenecks, and also not the load balancing itself. > > It is how you structure and distribute the common database. > > One way would be putting the DB on its own, separate machine, and have the > apps > communicate with it via remote/2 etc. calls. If that DB is modified by the > apps > a lot, then it is surely the bottleneck and all the load balancing is > useless. > > Another way is to have the apps maintain parts of the data model in local, > private DBs, and synchronize only certain parts to the central DB, > resulting in > lower stress on it. But this depends on the model. > > Yet another way is to have each app hold a copy of the full DB, and mirror > everything to everybody else, but this requires rules about who is allowed > to > modify which at any given moment. I use this currently in an application > with > two central DBs and one remote DB per user permanently mirrored between the > central DB and all user DBs on mobile devices. Naturally this involves a > big > synchronization overhead, but works here quite well as there are only > about 40 > mobile DBs. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
