best practises to support multi-tenancy ?

36 views
Skip to first unread message

Pascal Weemaels

unread,
Mar 22, 2014, 9:20:23 AM3/22/14
to openwfe...@googlegroups.com
Hello,

we have been using ruote for almost two years now, and still big fans of it !

In our current setup, we have a dedicated engine (postgres storage) for our each of our client projects, i.e. each project has its own engine table and its own pool of ruby worker processes. 
But as the number of client projects increases, this becomes to expensive.

So we want to share workers between different, independent projects. (each project has a set of process definitions and a set of storage- and block participants). We managed to implement this by prefixing both process definitions and participants with the project name. Works, but not optimal.

Is there a better way? Using multiple engine-id's looks the way to go, but it is not clear to me if a single worker can serve multiple engines? 

Thank you and kind regards,
Pascal

Hartog De Mik

unread,
Mar 26, 2014, 3:18:11 AM3/26/14
to openwfe...@googlegroups.com
In postgres you can use schemas to provide multi-tenancy. Not sure if that would help...


--
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
---
You received this message because you are subscribed to the Google Groups "ruote" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwferu-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pascal Weemaels

unread,
Mar 27, 2014, 2:45:24 AM3/27/14
to openwfe...@googlegroups.com
that is in fact what we were doing. but in such a setup, we need at least 1 ruby worker process per schema. that doesn't scale well. we end up with a bunch of ruby workers, all sitting idle most of their time.

I guess what we really want, is 'ruote as a service', so we don't need to manage workers at all.  ;)
Reply all
Reply to author
Forward
0 new messages