On 26 May 17:32, M. Murray wrote: > FWIW we are investigating the possibility of running multiple instances of > Tryton on a single server or server farm to serve multiple facilities > within one geographic region. For larger facilities, they get their own > physical server with tryton and postgresql installed. However, for smaller > facilities, and to enable a faster rollout to these facilities, we are > investigating alternatives to installing physical servers everywhere. > > The issues I would like to discuss are related to the following questions. > All the questions assume that I want to run 60 tryton instances each with > approximately 7000 party.party records and we're using a customised GNU > Health. > > > 1. As seen above, I use the number of party.party records as a kind of > gauge for the size of the database. Is there another metric that one may > suggest? Are there any inherent dangers in using this?
Storing the data is not the most costing thing to do. Indeed, it is more the number of transaction per second that matters. > 2. In the case of a Tryton server farm, which ways have members of the > community used that worked well? > - One user per instance, all instances in one OS container? or > - One VM container per instance each vm container has its own > PostgreSQL + Tryton installation? > - One VM per instance all talking to a central Postgres > - Something else? I can only explain the demo setup of Tryton which is from my experience the closer. The goal is to run an instance of each series for demo purpose. So the solution was under one single demo user, we have a virtualenv (python way) for each series where trytond is installed. Each series use a different database user (to prevent showing other database at login). And there is only one instance of PostgreSQL running on the server. Using VM doesn't sound like a good solution for me because you just add an extra layer. If you really want to have a better privilege separation between each instance, you could use chrooted environment or something like Docker. Also running PostgreSQL on VM requires some fine tuning to get it works at full power. Also having 60 databases on one single instance of PostgreSQL is still manageable but there is a limit to that number (I don't know exactly how much). > 3. Are there any recommendations on sizing a server to determine how > many instances can run on a given server? Essentially an instance to > server > ratio. It really depends on the usage. I guess the best is to try to put as much as possible until performence issue appears. > 4. Apart from trytond, postgres, logs, attachments, json-data, are there > other things to consider for a sing tryton server instance? To consider for what? > Some justification and so, it doesn't seem like I'm only asking. > > 1. I figure since party.party represents the subject of the interaction > most times. If *P* is the number of party.party records, I figure the > growth rate of the database is *tkP.* Where t is time and *k* represents > the average number of "transactions" per party. In the health context this > could be evaluations. > > 2. I'm thinking that it would be better to just run multiple trytond > instances on the bare server. No VM separation/containment. I wouldn't even > want to install trytond multiple times. Each different user, one per > instance, would all run the globally installed trytond. The main issue with such setup is the upgrade. You will be forced to upgrade all the instances at once. And generally it is something you want to do gradually. > 3. I have nothing here. I have 5 instances on a 4GB RAM VM and it's > painful. Help and experience requested here. Hard to answer without better explaination of the situation. > 4. Seriously, with the setup I described in my #2, creating a new instance > would be (1) create the user, (2) unzip the trytond-user-skel.tar.gz, (3) > update config and run. With virtualenv, you could just copy it and rebase it. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
