[RnD] Test number of Records Synced/min-sec limits with Android FHIR SDK using Room Database

[f-odhiambo]

Describe the issue to be researched

We need to determine how many records, including binary files (pre-authentication) and patient-related data (post-authentication), can be synchronized at any given time when using the Android FHIR SDK. This involves testing the app's performance under normal internet speeds, assessing how different data types affect the sync process, and identifying any bottlenecks.

Background:
The Android FHIR SDK allows for the integration of FHIR resources into Android apps using Room as a local database. Syncing various types of data, such as binary files (pre-authentication) and sensitive patient data (post-authentication), introduces potential variations in performance and security needs. Understanding these limitations and how data types impact sync efficiency is crucial.

Describe the goal of the research

The primary goal is to establish how many records can be synced under normal internet speeds, with an additional focus on both pre-authentication binary data and post-authentication patient data. We aim to:

1. Determine the maximum number of records (binary files and patient data) that can be synced without significant delays.
2. Compare sync performance between binary files and patient-related data.
3. Measure resource usage (e.g., memory, CPU) when handling different data types and batch sizes.
4. Identify optimizations for handling pre- and post-authentication data during sync operations.

Artifacts to be produced:

• Detailed test results, including batch sizes of binary files and patient-related data, sync duration, and resource usage.
• A comparison of pre-authentication (binary) vs. post-authentication (patient) sync performance.
• A summary report with findings, optimizations, and recommendations.
• Code adjustments and test scripts used for performance monitoring.

---

Describe the methodology

1. Utilize an Android app integrating the FHIR SDK and Room database, with the capability to sync binary files (pre-authentication) and patient data (post-authentication).
2. Test syncing different batch sizes of binary files and patient data under typical internet speeds (e.g., 100, 500, 1000 records).
3. Monitor sync performance, including sync duration, memory usage, CPU load, and any errors or timeouts encountered.
4. Record performance differences between binary and patient data syncing.
5. Analyze how authentication (pre vs. post) impacts performance and security during sync operations.

Additional resources:

• Android FHIR SDK and Room documentation.
• Information security guidelines for handling binary files and patient data.
• Internal teams or forums that have experience with FHIR SDK and Room integration in Android apps.

---

Acceptance Criteria

Needs to be refined

1. Internet Speed: Testing should simulate a typical internet speed of 8 Mbps. Else provide test scenario internet speeds
2. Record Sync Time: A batch of 1000 resources (combination of binary and patient data) should be successfully synced within 30 seconds if the server is optimized for batching and efficient processing.
3. Resource Types: Both binary files (pre-authentication) and patient-related data (post-authentication) must sync within this time frame under the same network conditions.
4. Performance Metrics: The sync process should not lead to excessive memory or CPU usage, ensuring the app remains responsive and functional during syncing operations.
5. Error Handling: Any failed syncs should be appropriately logged and handled, ensuring retry mechanisms or error resolutions are in place.

Contacts:

• [Name of Android FHIR SDK technical lead] for technical clarifications.
• [Security lead or individual responsible for handling sensitive patient data] for questions related to data handling.

The decision will be based on performance thresholds observed during testing for both pre-and post-authentication data, along with potential optimizations to improve overall sync performance.

[f-odhiambo]

Some ref

1. How much time to sync pre-auth configs - sec/mins
2. How much time for a bundle of records - 50, 100, 1000 - patient-related data - sec/mins
3. How much memory is consumed for - 50, 100, 1000 records - patient-related data - megabytes

We can talk to @Mstjamush about how to create mock records on the Server side and also attach a practitioner who will sync these records. We can create some (3) practitioners who will represent having created 50, 100, and 1000 records to test

[f-odhiambo]

We can also document the tools used away from what is provided by the emulator and Android Studio

[f-odhiambo]

Am also not sure how we can mimic various internet speeds and how it affects the initial sync load times - TBD

[qiarie]

Am also not sure how we can mimic various internet speeds and how it affects the initial sync load times - TBD

To test different connection speeds, we can test on an emulator and on a physical device.

With an emulator, it's readily possible to limit the device speed. With a physical device, there are tools available which may require device rooting to work properly.

[qiarie]

Actions:

• [ ] 1. Create test users
• [ ] 2. Generate fake test data per user
• [ ] 3. Run tests against the users for different batch sizes
• [ ] 4. Record times taken
• [ ] 5. Record memory requirements while running the different tests

[qiarie]

Look out for any processing in the SDK or OpenSRP that may be inefficient and which introduce [unnecessary] overheads