Tracker performance at scale¶

This document describes approaches to optimizing performance for large-scale DHIS2 tracker implementations.

Executive summary¶

Server

• Appropriate software versions are used:
• JDK11
• PostgreSQL 12 or 13
• DHIS2 version 2.35 or later, latest available patch
• Server monitoring is set up. Recommended: munin, glowroot
• Server is appropriately sized. For covax, at least:
• 32 CPU cores
• 32GB RAM
• SSD/fast disk
• Fast and stable internet and internal network connectivity
• In shared hosting environment, verify that the server has the specified resources in practice
• Use dedicated server for database/postgresql if possible

Tracker/Tracker Analytics

• Minimize the use of program indicators in dashboards, as this has cause performance issues.
• Alternative: serving tracker analytics through the aggregate data model, using strategies described in this document.
• Limit access to dashboards that use program indicators, particularly those dashboards that load by default as the 'landing page' upon logging into DHIS2.
• Alternative: Set up a text only/information landing dashboard that excludes tracker analytics to minimize impact. Limit dashboards based on program indicators only to those users/users groups who need them for analytical purposes (e.g. not for general data entry users)
• Enable analytics cache
• Do not use continuous analytics
• Tracker: Disable the "Display front page list" check in the program details.
• Apply custom database indexes for frequently searched TEI attributes.
• Ensure that system generated attributes don't use RANDOM pattern

Android

• Ensure admins responsible for Android deployments are familiar with:
• The use of the Android Settings App and the various sync strategies that can improve performance.
• Specific configuration for users which will use Android is highly recommended.
• Distribution of the Android App mechanisms and management of version updates.

Implementation Strategies

• Ensure there is an aggregate configuration available for reporting (e.g. daily reporting based on tally sheets) that can be used routinely, or as a back-up in the case of lag time in Tracker data entry during high-volume periods (e.g. COVAC Aggregate Package)
• Use the latest COVID-19 Immunization/EIR tracker package and related aggregate datasets (for serving the dashboard) as a reference; though we do not recommend 'updating' a package that has already been substantially customized for the country.

Pozadí¶

Audience¶

Primárním publikem sekce jsou správci systému, kteří podporují Ministerstvo zdravotnictví s jejich národními plány dodávek vakcíny COVID-19. Zatímco však dodání vakcíny COVID-19 je konkrétním případem použití, který je zde uveden, velká část pokynů je obecně relevantní pro rozsáhlé implementace trasovače.

Účel¶

• Sdílení „nejlepších dostupných informací“, pokynů, tipů a nástrojů v reálném čase/pocházejících z nových věcí k optimalizaci implementací DHIS2 pro očekávaný rozsah vakcín proti COVID-19. Tyto informace jsou často získávány prostřednictvím komunity v praxi.
• This is not intended to prescriptive guidance, but rather a series of recommendations that may evolve in real-time as we learn from real-world implementations; and update/improve the global products
• Naším cílem je usnadnit sdílení informací mezi implementacemi zemí, které mohou čelit podobným problémům a mohou mít prospěch ze společných řešení

Guidance for implementers¶

General Guidance¶

• Substantial performance improvements were introduced from V 2.35. We strongly recommend upgrading tracker instances to the latest patch version of 2.35 or 2.36, where performance improvements have also been added in the point releases.
• We strongly recommend to set up a server monitoring tool to identify when and why your server is struggling
  • Some recommendations include https://glowroot.org and https://munin-monitoring.org
  • Zde je návod na instalaci glowroot na DHIS2

Analytics Performance¶

Vzhledem k tomu, že požadavky jednotlivých zemí na frekvenci analytických dat „v reálném čase“ pro rozhodování se mohou lišit a včasné údaje jsou klíčové, doporučujeme vyhnout se provádění analýz během náročných období zadávání dat. Během generování analytických tabulek jsme zaznamenali výrazné skoky v celkové době odezvy. Zdá se, že ty mají největší dopad, když mnoho uživatelů přistupuje k řídicím panelům, které obsahují ukazatele programu počítající za běhu.

Dashboard Performance¶

Níže jsou uvedeny kroky, které lze provést ke zlepšení výkonu ovládacího panelu.

• Users should not have dashboards with tracker-based analytics as the landing page after logging in. a. Add a dashboard without analytics as the default/first dashboard that users land on after logging in. (i.e. ensure it is the first alphabetically. For example "**NOTICE** or **INFO**) b. This dashboard could be populated with text items to communicate key information, updates, standard operating procedures, etc. c. The dashboard should be shared with Public access

• Limit sharing dashboards only to only those analytics users who need to use data for decision making; restricting from data-entry users. This can be achieved with User Groups, combined with a Landing Dashboard for non-analytics users as above.

• Tracker analytics requests, in particular for certain program indicator configurations, can be slow and create performance problems. When extracting such data: a. Do it outside peak hours for vaccinators, to avoid any slowdowns hindering their work b. Work with smaller data sets at the time. For example, it may be necessary to get figures for a subset of organisation units at the time (e.g. by region). c. Rather than several people downloading the same data (e.g. for the national level) from DHIS2, download once and share via for example excel.

• Ensure caching is enabled in the dhis2 configuration, so that repeated requests for the same analytics resources are served from the cache and database queries are skipped. a. System settings -> analytics -> cache strategy. Recommended value: at least CACHE_6AM_TOMORROW. Set cacheability to "private" to avoid nginx cache.

• Vypněte nepřetržitou analýzu. Pokud vypnete průběžnou analýzu, vaše analýzy se budou aktualizovat až po spuštění analytických tabulek.

• Jako poslední možnost/neohledné opatření pro špatně fungující ovládací panely můžete také: a. Odebrat přístup k analýze sledování pro nekritické uživatele. b. Nastavit výchozí přistávací aplikaci prostřednictvím systémových nastavení na aplikace pro zachycení nebo zadávání dat. To znamená, že všichni uživatelé budou nejprve přesměrováni na tyto aplikace. To může být rušivé pro uživatele, kteří nezadávají data, ale minimalizuje to provoz na ovládacích panelech.

• Consider serving Tracker analytics from the COVID-19 EIR Tracker through the aggregate data model as described in the Implementation Section. In short: a. Mapping PIs to aggregate data elements b. Pushing data values to aggregate data model (via a script) at a predetermined frequency c. Dashboards shared more widely based on the aggregate data model via indicators can be 100 times more performant (dashboard items load in 0.02-0.1 seconds vs 10-200 seconds on testing instance). In addition, they give greater analytical power through the use of dimensions (e.g. to represent and slice/dice CatCombos).

Assessing Analytics/Program Indicator Performance¶

Analýza ovládacích panelů původně zahrnutých v balíčku COVID-19 EIR Tracker Package (poznámka: tyto ovládací panely pro sledování byly nyní z balíčku odstraněny a nedoporučujeme je) odhalila:

• Ovládací panely jsou výrazně zpomaleny dlouhými dotazy na programové indikátory typu zápis.

• Míry výpadků je dobré znát, ale jejich načítání trvá dlouho, dokonce i v naší testovací databázi. Domníváme se, že je nepravděpodobné, že by četnost odchodů vyžadovala každodenní monitorování, ale spíše může být analyzována týdně nebo dokonce měsíčně na vyšší úrovni prostřednictvím modulu COVAC Core Module (souhrnné datové sady a monitorovací panel pro pokrytí atd.)

Jiné „těžké“ vizualizace by měly být odstraněny z rutinních monitorovacích řídicích panelů, které jsou sdíleny s uživateli nižší úrovně a povedou ke snížení výkonu. Ty lze přesunout na ovládací panely, které se zobrazují méně často, do sestavy HTML nebo jiného nástroje pro vytváření sestav:

A. Mapy na nižších úrovních nebo požaduje zbytečné organizační jednotky

b. Zprávy událostí s více než 100 řádky událostí nebo 50 řádky pro registraci

C. Vizualizace vyžadující dlouhé periody longitudinálních dat, např. posledních 12 měsíců

d. Libovolná vizualizace s indikátory programu typu registrace, jako je míra opuštění

E. V testech programových indikátorů z balíčku COVAC trvaly nejdelší odezvu programové indikátory „typu zápisu“. Kromě toho mají horší škálovatelnost, protože poskytování dat při vyžádání dalších období, organizačních jednotek nebo TEI trvá déle.

Tracker Performance¶

• TEA, které generují jedinečná systémová ID pomocí vzoru SEQUENTIAL() jsou mnohem výkonnější než ty, které používají vzor "RANDOM()". Doporučujeme vyhnout se vzoru RANDOM, protože:

  • It's open for race conditions;
  • It will have a huge downward trend in performance the longer it\'s been used; and
  • Používá tabulku rezervovaných hodnot v databázi ke sledování toho, které hodnoty již byly distribuovány. Je známo, že tato tabulka představuje problém při importu trackeru.
  • Poznámka pro implementace, které používají Android: vyhrazení hodnot pro zařízení pro použití offline může ovlivnit uživatelské vnímání SEKVENČNÍHO generování, jak je zdokumentováno zde: https://docs.dhis2.org/en/full/implement/android-implementation.html#implementation_guide_dhis2_config_reserved_id

• V dřívějších verzích registru vakcín COVID-19 některé pracovní seznamy způsobovaly problémy s výkonem. Ty byly odstraněny z balíčků v balíčku COVID IER V 1.1.2. Pokud zjistíte, že trasovač vykazuje pomalé načítání, může to souviset s pracovními seznamy a velkým počtem TEI v jedné organizační jednotce. Řešením je deaktivace zaškrtnutí "Zobrazit seznam úvodní stránky" v detailech programu (to má nevýhodu také v deaktivaci pracovních seznamů)

• Vyhledávání atributů TEI (zejména nejedinečných, jako je jméno, příjmení, telefonní číslo) lze výrazně zlepšit přidáním dílčích indexů trigramů pro tento konkrétní atribut sledované entity. To bylo provedeno v Nigérii a Rwandě a zlepšení výkonu bylo obrovské. Toto je teprve nutné přidat do jádra, takže implementace je zatím budou muset vytvářet ručně. Pro přidávání indexů trigramů a jejich skládání s primitivními typy sloupců je třeba vytvořit dvě rozšíření. Rozšíření jsou již součástí výchozí instalace posgresql. Rozšíření:

create extension pg_trgm;
create extension btree_gin;

Příklad indexu pro trackedentityattributeid 1234 (např.: PhoneNumber). Musí se opakovat pro každý atribut, který se často používá při vyhledávání (jméno, příjmení atd.)

create index concurrently in_gin_teavalue_1234 ON trackedentityattributevalue 
using gin (trackedentityinstanceid,lower(value) gin_trgm_ops) 
where trackedentityattributeid = 1234;

• Podobně pomohou indexy trigramů, pokud systém vyhledává na základě hodnot dat událostí. Nigérie měla svůj QR kód pro dokončená očkování jako hodnotu dat události, kterou intenzivně vyhledávala (např.: qr kód cestujících zkontrolovaný před nástupem na palubu). V závislosti na vzorcích vyhledávání pro konfiguraci konkrétní implementace lze tento index trigramu také použít. Ne všechny implementace to budou potřebovat. Za předpokladu, že výše uvedená rozšíření jsou již vytvořena, příklad vytvoření indexu pro datový prvek (uid=​​LavUrktwH5D, qrCode), připojený k programové fázi. Dataelementid=233047 a programmetageid=64527 v tomto příkladu.

create index concurrently in_gin_psi_edv_64527_233047 on > programstageinstance 
using gin (lower(eventdatavalues #>> '{LavUrktwH5D, value}') gin_trgm_ops);

• Používání vlastních aplikací může mít pozitivní nebo negativní dopad na výkon. Aplikace mohou představovat způsob, jak vytvořit cílenější funkcionalitu, která zabrání dalším kliknutím a voláním API. Jsou také zdrojem opatrnosti a viděli jsme, že některé vlastní aplikace používají funkce API, které zbytečně zatěžují systém. Parametry pro přeskočení stránkování, počítání počtu výsledků při stránkování, použití operátoru LIKE k porovnání, kdy je vhodnější EQ (rovná se), jsou některé z významných viníků, které způsobují určitý stres. Pokud je použit operátor LIKE s jedinečnými atributy, měl by být pro něj vytvořen trigram index, jak je uvedeno výše. Vždy je třeba se vyhnout přeskočení stránek. Při použití stránkování je třeba se vždy vyvarovat totalPages, protože to umožňuje dotazu DB získat plný počet záznamů, aby je spočítal, namísto pouhého načtení dané stránky. Je-li to možné, měl by být u atributů, které lze prohledávat, uplatněn minimální limit vyhledávacího řetězce na 3 znaky. Nigérie měla vlastní aplikaci, která vynucovala minimální limit vyhledávání 3 znaků na straně aplikace a která pomohla zmírnit několik těžkých dotazů. Indexy trigramů použije optimalizátor dotazů pouze v případě, že hledaný řetězec má alespoň 3 znaky.

Poznámka

Volání prováděné vlastními aplikacemi vyžadují zvláštní pozornost, protože volání mohou být konstruovány způsobem, který nebyl dobře testován a nebyl prokázán jako výkonný. Zde uvedený seznam běžných viníků výkonu není vyčerpávající. Je důležité mít zavedené monitorování a dohlížet na volání uskutečněné z vlastních aplikací, integračního middlewaru a externích skriptů.

• Aplikace Tracker Capture aktualizuje hodnoty dat událostí jednotlivě. Ve vysoce souběžném prostředí to může způsobit zamykání a čekání na úrovni řádků databáze. Srí Lanka vytvořila aplikaci Custom Tracker Capture s použitím základní aplikace Tracker Capture jako základní linie. Ve vlastní aplikaci změnili tok tak, aby se všechny hodnoty dat událostí aktualizovaly společně v jediném rozhraní API po kliknutí uživatele na „Uložit a dokončit“. V původní základní aplikaci bylo tlačítko „Dokončit“. Pokud podpůrné skupiny/administrátoři/implementátoři HISP mají potřebné dovednosti, mohou se možná poohlédnout po tom, jak udělat totéž.

User Management¶

• Nedoporučujeme sdílet přihlašovací údaje mezi více zařízeními. To mělo za následek některé scénáře, kdy jsou uživatelé neúmyslně odhlášeni.
  • Alternativy: jeden uživatel na zařízení (např. uživatel následuje zařízení, tj. personál pro zadávání dat očkovacího místa; hesla lze pro větší bezpečnost každý den recyklovat)
• Optimalizace uživatelů pro Android (popsáno v sekci Android)
• Omezení zbytečného přístupu k ovládacím panelům založeným na sledování, jak je popsáno výše

Guidance for Android Deployments¶

DHIS2 Configuration recommendations¶

Tato podčást pokrývá konkrétní doporučení, kterých lze dosáhnout přímou úpravou konfigurace serveru DHIS2.

User access¶

Vzhledem k povaze Androidu, který je schopen pracovat offline, se aplikace pokusí stáhnout co nejvíce informací v případě, že zařízení přejde do režimu offline. Chcete-li snížit množství přenesených dat:

• Nastavte organizační jednotky, programy a datové sady, ke kterým budou mít uživatelé přístup; tím se výrazně sníží množství přenášených dat a zatížení serveru

• Přečtěte si doporučení, jak vytvořit uživatele

Auto-generated Values¶

Kvůli offline povaze bude Android stahovat i vyhrazené hodnoty. Aplikace se pokusí vyhodnotit množství zbývajících hodnot a načíst další ze serveru, kdykoli dojde k synchronizaci.

In implementations where users will be offline for long periods of time this value might need to be increased (explained in the section below). If the auto-generated values defined include the usage of dates in any of its forms (days, months, years) the system administrator should pay special attention while defining them and using the Android App. Also note, reserving values to devices for offline use with the SEQUENTIAL() pattern (e.g. for a TEI attribute 'System Generated ID') will take each of these values sequentially as they are reserved in the devices, which can be confusing for some users. This behavior is expected as documented here.

Další informace o tomto tématu naleznete v officiální dokumentaci and in this post in the CoP.

Android Settings WebApp¶

Nastavení pro Android WebApp je aplikace, kterou lze nainstalovat na jakýkoli z nejnovějších serverů DHIS2 a umožňuje správci systému definovat některá nastavení, která načte každý mobil.

Reserved Values¶

V části výše bylo stručně vysvětleno použití automaticky generovaných hodnot. Pomocí aplikace Nastavení pro Android může správce systému definovat, kolik z těchto hodnot načte každý mobilní uživatel. Pokud budou vaši mobilní uživatelé po velmi dlouhou dobu v režimu offline, může být dobré tuto hodnotu zvýšit, avšak nastavení velkého počtu zde může vést k vyčerpání hodnot a zvýšení objemu přenesených dat v počátečním synchronizace.

As an example, imagine we have an implementation with mobile devices which will be going offline for a full week and then come back to a central location for the synchronization of data. Each user might see up to 50 patients per day and therefore during a week up to 350 patients. Setting the Reserved values downloaded per TEI attribute to at least 350 would ensure the users can work properly offline without risking exhausting the values.

Metadata Sync¶

Pokud je velmi nepravděpodobné, že bude váš program změněn, nastavení hodnoty dlouhého období pro toto nastavení sníží počet připojení k serveru. Je dobré najít rovnováhu mezi tím, jak důležité by bylo mít zařízení bez plně aktualizovaných metadat a zátěží, kterou může server zaznamenat vzhledem k počtu zařízení.

Jako příklad si představte, že máme implementaci s 10.000 zařízeními, která jsou nastavena na synchronizaci každý 1 den. To znamená, že server by měl být připraven zpracovat 10.000 aktualizací metadat každý den. I když tyto požadavky povedou k prázdné odpovědi, pokud nebyly provedeny žádné změny, může být chytřejší nastavit tuto hodnotu na 1 týden nebo dokonce ručně (se správným způsobem komunikace s uživateli v terénu), pokud nebudou provedeny žádné změny v balíček nebo změny pravděpodobně nebudou kritické.

Můžete dokonce zakázat automatickou synchronizaci metadat a spolehnout se na manuální synchronizace spouštěné vašimi uživateli, pokud je to pro vaši implementaci možnost.

Data Sync¶

Synchronizace dat probíhá na stejném principu jako u metadat a měla by být upravena podle implementace. Můžeme například najít implementace, kdy uživatelé jdou do terénu, kde budou pracovat offline, proto by mělo být důležité poskytnout těmto uživatelům všechna data potřebná pro jejich práci. Nebo mohou existovat implementace, kdy uživatelé budou s největší pravděpodobností registrovat pacienty v terénu a přenášet data ze zařízení na server.

Podívejte se na následující příklady:

• In an implementation where users will be working pretty much offline and they need to have as much data as possible on their device, the data sync could be set to Manual if the users are instructed to perform this before leaving to the field. Or daily if this process should be automated.

• In an implementation where users are going to the field, and they are likely to be robbed, or a fear of devices being lost is present it might be interesting to set the data sync to the minimum (30 minutes) so the data is pushed to the server as soon as possible. Users could also be instructed to use granular sync every time they add or modify a patient but this might be more cumbersome.

Můžete také zakázat automatickou synchronizaci dat a spolehnout se na manuální synchronizace spouštěné vašimi uživateli, ale to představuje větší riziko, že data budou zaznamenána a nebudou synchronizována, pokud uživatelé nebudou systematičtí.

Download Settings¶

These settings allow the users to define the amount of TEIs that will be downloaded when performing the data sync. It should probably be combined with the Data Sync setting explained above. It is important to understand how these settings work to define a targeted and valid approach. The official documentation, synchronization settings, explains in detail what to expect when setting this up. The connectivity capabilities of the implementations should also play a big role while defining these, as in implementations with very good connectivity reducing this value to the maximum would decrease the load of the server during the data sync without having a big impact in the users (they will always be able to find the patients online). However, this could lead to a server overload while performing very broad searches. The way mobile users will connect to the server (i.e. using mobile data packages instead of wifi) also plays a role as downloading many patients that might not be used will incur in expending mobile data for no reason.

Podívejte se na následující příklady:

• V implementaci, kdy uživatelé budou především přidávat pacienty do systému (tj. registrovat pacienty s COVID), není potřeba mít na zařízení mnoho pacientů. Nastavení nízké hodnoty download TEI by tedy snížilo zatížení serveru při synchronizaci dat a snížilo množství přenesených dat (je třeba vzít v úvahu při připojení s mobilními daty)

• V implementaci, kde budou uživatelé navštěvovat pacienty offline bez možnosti online vyhledávání, může správce systému chtít umožnit uživatelům stáhnout si co nejvíce TEI, aby si s sebou vzali všechna data pacientů, která budou potřebovat.

• V implementaci s velmi dobrou konektivitou by se uživatelská administrace mohla rozhodnout snížit nastavení stahování, aby zařízení měla co nejméně TEI a zcela spoléhala na online vyhledávání. Vzhledem k tomu, že uživatelé budou hledat podle jedinečného ID (tj. národního ID čísla), což je pro server nenáročný úkol, nastavení se zdá být dostatečné. Pokud však uživatelé nebudou moci vyhledávat pacienty podle jedinečného ID a budou používat příjmení, server by mohl trpět přetížením při vyhledávání, a proto by mohlo být zajímavější umožnit uživatelům stáhnout si více pacientů a spoléhat se na offline režim.

Application Updates¶

Aplikace DHIS2 pro Android je publikována prostřednictvím dvou kanálů: Obchod Google Play a Github. Vydání vydáváme každých 6 měsíců a vydání oprav tak často, jak je potřeba. Pokud implementace používají jako zdroj zřizování obchod Google Play, mohly by těžit z automatických aktualizací, to však nemusí být žádoucí v některých scénářích, kdy implementace chtějí otestovat novější verzi, než ji zpřístupní svým uživatelům. Doporučujeme deaktivovat automatické aktualizace, aby mohli administrátoři / testeři aplikaci důkladně otestovat, než o to požádá své uživatele.

Chcete-li zakázat automatické aktualizace, po instalaci aplikace prostřednictvím Google Play postupujte následovně:

• Vyberte nabídku se 3 tečkami v pravém rohu obrazovky. Ve výchozím nastavení bude vybrána možnost „Povolit automatickou aktualizaci“.
• Zrušte výběr tohoto tlačítka. Tím zajistíte, že se aplikace pro Android automaticky neaktualizuje, když je k dispozici aktualizace.
• Po dokončení by nemělo být zaškrtnuto políčko „Povolit automatickou aktualizaci“.

Správci systému by nyní mohli těžit z kontroly nových verzí a poté dát uživatelům vědět, kdy by měli svou aplikaci aktualizovat, a to tak, že přejdou do Obchodu Play a kliknou na tlačítko Aktualizovat, které se zobrazí pokaždé, když bude nové vydání.

Další informace o plánech zavádění a testování naleznete v oficiálních průvodcích.

Device and management recommendations¶

V této části stručně popíšeme některá doporučení týkající se samotných zařízení a jejich správy.

Android device specifications¶

Je velmi těžké dát obecná doporučení, které zařízení použít. Implementace by měly otestovat svou konečnou konfiguraci na sadě zařízení, aby porozuměly uživatelské zkušenosti.

Pokud bude například implementace vyžadovat, aby uživatelé chodili do terénu a pracovali offline s velkým počtem TEI, měli by se zaměřit na zařízení vyšší třídy, protože aplikace pro Android bude náročnější na zdroje. Pokud jsou však implementace velmi omezeny rozpočtem a budou mít tisíce uživatelů, ale budou pracovat s mnohem menším množstvím TEI a dat, mohou preferovat použití některých zařízení střední třídy.

Další informace o tomto procesu lze nalézt v oficiální příručce.

Mobile Device Management¶

V mobilních implementacích důrazně doporučujeme používat správu mobilních zařízení (MDM). Mít MDM poskytne několik výhod, které mohou usnadnit implementaci a podporu. Obvykle však mají vyšší náklady.

Implementace se mohou rozhodnout pro MDM připravené k použití nebo nasadit řešení ve vlastní infrastruktuře. To druhé může být lepším řešením z hlediska rozpočtu, ale bude vyžadovat vysoké technické dovednosti, jako je správa systému a správa databáze.

Tato [oficiální příručka]{.ul} pokrývá několik MDM, které byly testovány, a uvádí jejich hlavní výhody a nevýhody.

Mobile recommendations checklist¶

Server hosting, administration and monitoring¶

Existují dva základní požadavky související s hostingem serveru:

• Pro správu serveru by měl být někdo – nejlépe dva – lidé s požadovaným školením a zkušenostmi.
• Měla by existovat politika ochrany soukromí/bezpečnosti, která by pokrývala uchovávání velké části údajů o obyvatelstvu

Server specifications¶

Jak je uvedeno v dokumentaci na serveru specifikace, „DHIS2 se lineárně škáluje na množství paměti RAM a počtu jader CPU, takže čím více si můžete dovolit, tím lépe bude aplikace fungovat." Implementace Covax, obecně zaměřené na celkovou dospělou populaci země, budou rozsáhlé i v menších zemích. Přesné požadavky se budou lišit v závislosti na očekávaném počtu uživatelů a TEI, ale 32 GB RAM a 32 CPU lze považovat za výchozí bod pro všechny implementace kromě nejmenších. Všechny implementace by měly být připraveny na upgrade hardwaru, aby podporovaly měnící se měřítko a rostoucí data.

Výkon SSD/disku je také rozhodující pro celkový výkon a výrazně ovlivňuje klíčové aktivity, jako je vyhledávání TEI a analýzy. Dokumentace naznačuje, že "Minimální rychlost čtení je 150 Mb/s, 200 Mb/s je dobrá, 350 Mb/s nebo lepší je ideální." Skutečný výkon disku lze také posoudit pohledem na latenci disku. Tyto údaje můžete vidět na munin, jednoduché jednorázové hodnocení lze provést pomocí dd:

dd if=/dev/zero of=/root/testfile bs=512 count=1000 oflag=dsync

U dobrého disku by tento příkaz měl skončit ve zlomku sekundy (\<0,5s). Cokoli nad 5 sekund bude pravděpodobně příliš pomalé na dosažení přijatelné úrovně výkonu.

Server architecture and infrastructure¶

The application (tomcat) and database (postgresql) could be hosted on the same server, but ideally the database should be set up on a dedicated server.

Fast and stable internet is always required, but when the database is set up on a separate server, it is also important to ensure that there is a fast and stable internal network connection between the two.

Zvláštní pozornost je třeba věnovat, když je server hostován ve sdíleném virtualizovaném prostředí. V těchto případech může poskytovatel hostingu přehnaně poskytovat zdroje (např. CPU, disky), což znamená, že server ve skutečnosti nemá zdroje, které se zdá mít. To také znamená, že výkon kolísá v závislosti na zatížení jiných systémů. V některých případech musely země vyjednávat s poskytovatelem hostingu, aby zajistily, že používaný server není přetížen, nebo se musely přesunout na fyzický server.

Instalace a konfigurace¶

Je důležité zajistit, aby byly k optimalizaci výkonu použity správné verze softwaru:

• JDK11
• PostgreSQL verze 12 nebo 13
• DHIS2 verze 2.35 nebo novější, nejnovější dostupná opravná verze

Tomcat je třeba nakonfigurovat s dostatkem paměti. To bude záviset na celkové dostupné paměti serveru a na tom, zda je sdílena s postgresql nebo zda databáze běží na samostatném serveru. S účtem superuživatele DHIS2 můžete ověřit konfiguraci paměti tomcat otevřením „O DHIS2“ a pohledem na pole „Informace o paměti“:

Pro dobrý výkon je také kriticky důležité správně nakonfigurovat postgresql. Pokyny k tomu jsou k dispozici v dokumentaci k serveru.

Server monitoring¶

Důrazně doporučujeme nastavit nástroj pro monitorování serveru, abyste zjistili, kdy a proč má váš server potíže. Měly by být sledovány klíčové metriky výkonu, např. RAM, CPU, výkon disku na všech uzlech a specifická měření pro aplikaci na proxy, databázi a tomcat. Některá doporučení zahrnují https://glowroot.org a https://munin-monitoring.org. Na podporu tohoto byl napsán návod pro instalaci glowroot na DHIS2.

Mezi další možnosti, které mohou vyžadovat více konfigurace, ale umožňují významné přizpůsobení, patří prometheus/grafana a ELK stack.

Implementation Strategies¶

Na základě zkušeností ze Srí Lanky, Indonésie, Nigérie, Rwandy a dalších mohou vizualizace založené na sledovací analýze v rozsáhlých nasazeních vakcín proti COVID-19 vést k velmi těžkým dotazům na počet TEI, takže systém je téměř nepoužitelný. Ostré strategie zmírnění přijaté ve Rwandě (vypnutí všech aplikací Analytics), zatímco Srí Lanka se vrátila k dotazům SQL.

Tyto problémy lze částečně vyřešit pomocí výše uvedených pokynů pro optimalizaci výkonu. Uvědomujeme si také, že:

• Nepředvídatelnost výkonu Trackeru v bezprecedentním měřítku, vzhledem k mnoha různým faktorům, které hrají roli při implementaci, konfiguraci a přizpůsobení v jednotlivých zemích
• Kapacity, zdroje a struktury pro správu serverů se v jednotlivých zemích velmi liší

Mezitím se ukázalo, že denní souhrnné hlášení prostřednictvím DHIS2 je vysoce účinné ve velkém měřítku v kampani proti spalničkám a zarděnkám v Bangladéši v roce 2020. Existence agregované konfigurace může usnadnit denní hlášení o zásobách a podaných dávkách (např. ze sčítacích listů), což jsou údaje, které jsou do značné míry dostačující pro účely "denního monitorování v reálném čase" celé kampaně prostřednictvím informačních panelů. V Ugandě byla agregovaná implementace použita vedle trackeru COVID EIR, aby bylo možné denně monitorovat a kontrolovat úplnost údajů v obdobích vysokého objemu, kdy nebylo možné udržet zadávání údajů do trackeru (nedostatek zařízení atd.).

Na základě zpětné vazby jsme pochopili, že většina implementací vyžaduje alespoň denní monitorování během fází kampaně dodávky vakcíny COVID-19, ale definice „v reálném čase“ je proměnlivá. Může nastat denní doba, kdy operační střediska kampaní sledují denní výkon a je třeba je vzít v úvahu při implementaci a plánování analýz v zemi.

Use of Aggregate Data Model with Tracker Deployments¶

Doporučujeme začlenit modely souhrnných dat do implementací vakcíny COVID-19 pro dvě samostatné funkce.

Parallel aggregate reporting: daily stock & tally sheets of vaccine doses administered at vaccination site level¶

Doporučení zajistit, aby země měly souhrnný balíček COVAC souběžně s registrem Trackerů, je staré. Zde uvádíme několik důvodů, proč si myslíte, že by země měla být připravena s agregovanou konfigurací pro vytváření přehledů spolu s nasazením sledování:

• V kontextu mnoha zemí to bude nutné pro zajištění úplnosti dat pro účely monitorování kampaně: např. pokud celá populace nemůže být pokryta registrem sledovačů z mnoha důvodů

• V některých kontextech lze tento mechanismus hlášení (např. na základě denních záznamů) použít během období s velkým objemem v kampani, kdy může zadávání dat na úrovni jednotlivce zaostávat (nedostatek zařízení, problémy s připojením, nedostatek zaměstnanců pro zadávání dat atd.).

• Denní hlášení z záznamů se také často používá pro srovnání kvality dat s daty Tracker a pomáhá zemi vyhodnotit nasazení Trackeru a rozhodnout o zdrojích dat/datových tocích.

COVAC 'Core' Aggregate Package obsahuje konfiguraci, která to podporuje (v souladu s pokyny WHO pro monitorování, nástroji WHO pro AFRO pro podávání zpráv a eJRF):

• Denní datová sada: COVIDVAC – Očkování (např. podané dávky, podle cílových skupin)

• Denní datová sada: hlášení zásob na úrovni webu (např. použité lahvičky, fyzický stav zásob atd.)

• Roční datový soubor (může být také měsíční/čtvrtletní v závislosti na plánu země): stanovení populačních cílů, které mohou být rozčleněny podle prioritních skupin atd.

• Monitorovací panel COVAC, který obsahuje míru pokrytí, podávané dávky, klíčové údaje o zásobách, míru opuštění atd. Tento monitorovací panel je obecně přizpůsoben pro vyšší úroveň monitorování celkového národního plánu dodávek vakcíny proti COVID; ne všechny součásti tohoto dashboardu jsou určeny pro „real-time“/denní monitorování.

Converting tracker data to aggregate data model → for the purpose of analysis (e.g. serving performant dashboards)¶

Vzhledem k potenciálu problémů s výkonem u ovládacích panelů poskytujících data založená na sledování (např. těžké programové indikátory počítající za běhu pokaždé, když je ovládací panel načten), doporučujeme, aby bylo možné obsluhovat ovládací panel denně/téměř v reálném čase pomocí agregovaného datového modelu. . V našich testech se ukázalo, že je to mnohem výkonnější a stále dokáže poskytovat uživatelům analytických služeb klíčové metriky. Další výhodou pro analýzu je strukturování dat do dimenzí (komba kategorií) pro otáčení a dělení.

Abyste mohli poskytovat analýzy COVID-19 ze zdrojových dat trasovače (např. registru vakcín COVID), budete potřebovat:

1. Soubor souhrnných dat (ve stejné instanci jako program Tracker nebo v jiné instanci) a soubor DE a COC pro příjem dat agregovaných z trackeru

2. Ovládací panel, který nahradí ovládací panel založený na trackeru pro sledování kampaní; ovládací panel by měl být založen výhradně na indikátorech a/nebo datových prvcích založených na souhrnné doméně.

3. Sada programových indikátorů, které dokážou agregovat data sledování a přenést je do cílových agregovaných DE/COC, s atributy namapovanými na cílová agregovaná metadata

4. Skript, který posune trasovací data (např. hodnoty indikátorů programu) za cíl agregovaných DE. Příklad skriptu je ve vývoji a bude brzy sdílen.

Obecný pokyny pro tracker-to-aggregate data jsou k dispozici a bude nadále aktualizován.

List of Known Software Issues¶

COVAC: problémy s výkonem