Commcare production readiness-Things to consider

Hi all,

We are hosting commcare internally in one of our project implementations. We are hosting commcare on cherrrypy server. Approximately 300 caregivers/Healthworkers would be using the application.
We would like to get some advice on production deployment related stuff like
1.High Availability- Is it possible to run multiple instance of commcare to support HA
2. Backup- Is it enough to backup Couchdb and PostgreSQL?
3.Configuring cache- should we do any configuration related to cache for performance boost.

Also let us know if we need to consider any areas for production readiness, that I have missed to mention.

Thanks!
Balaji G

Hi Balaji,

Great questions. My thoughts in order of your questions.

1: HA. Nothing prevents you from following the standard django scaling
recommendations of multiple instances. Have a central DB machine and 1-2-3
worker machines behind a load balancer of some type is a basic scaling
configuration. So long as you define the sessions in a way such that the
web worker machines can access (via DB on the central machine, or a shared
memcached session management) you should be ok.

2: Yes

3: Caching on the ORM level for django will yield some benefits, but our
django models are fewer and far between. So while tools like johnny-cache
will give ORM performance benefits, it may not be all that a big benefit.
For Couch related queries, there’s not much by way of caching done at the
moment, given that couch for our current needs is fast and powerful enough
for aggregate reports and single document views. Caching across multiple
app servers is going to be a very complicated matter when dealing with
document update conflicts. Unless you feel really burdened by speed
issues, I wouldn’t attempt couch caching unless absolutely necessary - and
this is highly dependednt on the types of data you want to view.

Finally, my question for you is what’s the reasoning behind wanting to
scale out your deployment now? Are you finding that your server load is
exceeding what you have setup now? I ask because our prior deployments of
CommCareHQ have not yet needed this level of N-Tier architecture just yet
for the size of deployment you are describing. I’m interested to see in
what sort of numbers and calculations you are using to reach your decision
and projected load.

Thanks, hope this helps.

Dan

··· On Sun, Jul 1, 2012 at 12:08 PM, Balaji rags wrote:

Hi all,

We are hosting commcare internally in one of our project implementations.
We are hosting commcare on cherrrypy server. Approximately 300
caregivers/Healthworkers would be using the application.
We would like to get some advice on production deployment related stuff
like
1.High Availability- Is it possible to run multiple instance of commcare
to support HA
2. Backup- Is it enough to backup Couchdb and PostgreSQL?
3.Configuring cache- should we do any configuration related to cache for
performance boost.

Also let us know if we need to consider any areas for production
readiness, that I have missed to mention.

Thanks!
Balaji G

Hi Dan,

Thanks for your reply.

The reason behind my question of HA was that even though the no of
mobile users were 300+, I was curious to know how we handle server
fail-over case(Like if the one server goes down for some reason,the
other instance can process the request) in prior deployment of commcare
. That being the case,I wanted to know if it is really required for
our production deployment considering the no of users we have. If
your views are that a single instance is sufficient to handle 300+
user,then i don’t see any reason for HA right now.

Regards,
Balaji G

··· On Monday, July 2, 2012 12:38:47 AM UTC+5:30, Daniel Myung wrote: > > Hi Balaji, > > Great questions. My thoughts in order of your questions. > > 1: HA. Nothing prevents you from following the standard django scaling > recommendations of multiple instances. Have a central DB machine and 1-2-3 > worker machines behind a load balancer of some type is a basic scaling > configuration. So long as you define the sessions in a way such that the > web worker machines can access (via DB on the central machine, or a shared > memcached session management) you should be ok. > > 2: Yes > > 3: Caching on the ORM level for django will yield some benefits, but our > django models are fewer and far between. So while tools like johnny-cache > will give ORM performance benefits, it may not be all that a big benefit. > For Couch related queries, there's not much by way of caching done at the > moment, given that couch for our current needs is fast and powerful enough > for aggregate reports and single document views. Caching across multiple > app servers is going to be a very complicated matter when dealing with > document update conflicts. Unless you feel really burdened by speed > issues, I wouldn't attempt couch caching unless absolutely necessary - and > this is highly dependednt on the types of data you want to view. > > Finally, my question for you is what's the reasoning behind wanting to > scale out your deployment now? Are you finding that your server load is > exceeding what you have setup now? I ask because our prior deployments of > CommCareHQ have not yet needed this level of N-Tier architecture just yet > for the size of deployment you are describing. I'm interested to see in > what sort of numbers and calculations you are using to reach your decision > and projected load. > > Thanks, hope this helps. > > Dan > > On Sun, Jul 1, 2012 at 12:08 PM, Balaji rags wrote: > >> Hi all, >> >> We are hosting commcare internally in one of our project implementations. >> We are hosting commcare on cherrrypy server. Approximately 300 >> caregivers/Healthworkers would be using the application. >> We would like to get some advice on production deployment related stuff >> like >> 1.High Availability- Is it possible to run multiple instance of commcare >> to support HA >> 2. Backup- Is it enough to backup Couchdb and PostgreSQL? >> 3.Configuring cache- should we do any configuration related to cache for >> performance boost. >> >> Also let us know if we need to consider any areas for production >> readiness, that I have missed to mention. >> >> Thanks! >> Balaji G >> > >