Best/Optimal configuration (In terms of software requirement versions) for a dhis2 2.30 on Ubuntu 16.04


(Philip Aleu) #1

Hello all,

The installation documentation at https://docs.dhis2.org/2.30/en/implementer/html/dhis2_implementation_guide_full.html#installation for version 2.30 specifies the software requirements needed for the installation of dhis2. It does not however tell what specific version for each would be optimal for performance. What we have documented is for example ‘PostgreSQL database version 9.4 or later’. Our implementation started out with dhis2 2.26 (PostgresSQL 9.5, Java8, tomcat servlet container version 7). We have since moved to 2.30 over the last 2 years. We are wondering what would best suite this kind of implementation in terms of software requirements for best/optimal performance. For example might we need to upgrade PostgresSQL to 10?. Just to add to this, is there support for latest LTS version of Ubuntu(18.04)?

Philip Aleu


[DHIS2 Android] The all-new DHIS2 Android App
(Calle Hedberg) #2

Philip,

I would in general recommend the following:

The latest postgresql version 10.x or 11.x (I’m using 11 - slighly better than 10.x IMHO). Note that there was a large performance improvement between 9.5 and 9.6 due to the introduction of efficient btree indexing. V 10 and even better 11 have support for table partitioning (mostly relevant for large databases, of course).

RAM requirements depends on db size and utilisation levels - ditto for the use of nginx and similar

PostGIS 2.5.1 or later - just remember to also CREATE that extension for each db.

Java 8 build 201 or later.

Tomcat 8.5.x (I have not tested Tomcat 9), just remember to include the relaxQueryParameter setting to disregard the use of square brackets if you use build 8.5.35 or later.

Ubuntu 18.04 LTS should be fine - HISP-SA is using 16.04 LTS now for several hundred DHIS2 databases, but I think the intention is to move them to 18.04 during the next few months.

Regards
Calle


(Philip Aleu) #3

Thank you @Calle_Hedberg. This is helpful, we usually want to keep on top of bugs and fixes and hence are keen to move. Sometimes we’re afraid of how far ahead we can go without stumbling into stability issues hence the need to first learn from experiences of fore runners. I strongly believe adding some of these things to the documentation will go along way in annihilating some of these fears. We’ve heard folks upgrade things on production and then having to downgrade after realizing things just weren’t smooth anymore - myself a victim in my early stages of implementation.