Joachim, > Am 27.06.2018 um 07:42 schrieb jtuc...@objektfabrik.de: > > Norbert, > > Am 26.06.18 um 21:41 schrieb Norbert Hartl: >> >> >> Am 26.06.2018 um 20:44 schrieb Andrei Stebakov <lisper...@gmail.com >> <mailto:lisper...@gmail.com>>: >> >>> What would be an example for load balancer for Pharo images? Can we run >>> multiple images on the same server or for the sake of balancing >>> configuration we can only run one image per server? >>> >> There are a lot of possibilities. You can start multiple images on different >> ports and use nginx with an upstream rule to load balance. I would recommend >> using docker for spawning multiple images on a host. Again with nginx as >> frontend load balancer. The point is that you can have at least twice as muh >> inages running then you have CPU cores. And of course a lot more. >> > > the last time I checked nginx, the load balancing and sticky session stuff > was not available in the free edition. So I guess you either pay for nginx > (which I think is good) or you know some free 3d party addons... > there is the upstream module which provides load balancing. But you are right I think sticky sessions is not part of it. The closest you get IIRC is IP based hashing.
> I wonder what exactly the benefit of Docker is in that game? On our servers > we run 10 images on 4 cores with HT (8 virtual cores) and very rareley have > real performance problems. We use Glorp, so there is a lot of SQL queriing > going on for quite basic things already. So my guess would be that your "2 > images per core" are conservative and leave air for even a third one, > depending on all the factors already discussed here. > Docker is pretty nice. You can have the exact same deployment artefact started multiple times. I used tools like daemontools, monit, etc. before but starting the image, assigning ports etc. you have to do yourself which is cumbersome and I don’t like any of those tools anymore. If you created your docker image you can start that multiple times because networking is virtualized all images can have the same port serving e.g. I think talking about performance these days is not easy. Modern machines are so fast that you need a lot of users before you experience any problems. The mention of „2 images per core“ I need to explain. A CPU core can execute only one thing at a time. Therefor 1 image per core would be enough. The second one is for that time slices where there are gaps in processing meaning the process is suspended, switched etc. It is just the rule of thumb that it is good to have one process waiting in the scheduling queue so it can step in as soon as there is free cycles. The „2 images per core“ have the assumption that you can put an arbitrary load on one image. So with this assumption a third image won’t give you anything because it cannot do anything the other two images cannot do. So according to the „hard“ facts it does not help having more than two images. On the other hand each image is single threaded and using more images lowers the probability that processes get blocked because they are executed within one image. On yet another hand if you use a database a lot of the time for a process is waiting for the response of the database so other processes can be executed. And and and…. So in the end you have to try it. > What's not to underestimate is all the stuff around monitoring and restarting > images when things go wrong, but that's another story... > Docker has a restart policy so restarting shouldn’t be an issue with it. Monitoring is always hard. I use prometheus with grafana but that is quite a bit to set up. But in the end you get graphs and you can define alerts for system value thresholds. If the topic gets accepted Marcus and me will tell about these things at ESUG. Norbert > Joachim > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de > <mailto:jtuc...@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de > <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >
