Managing Application Size as it Relates to Performance

Application Performance--how efficiently and effectively an application runs-- is hugely important to providing your users with an acceptable user experience. Many app builders only find out their apps are nonperformant after users report issues, but ideally a system has been thoroughly tested before it is launched to ensure it can handle the anticipated load and scale.

Application Performance is determined by several factors, including

• The number of cases on the device

• The size of cases on the devices

• The hardware (specifically amount of internal storage and RAM/ processor speed)

• The complexity of the application

Because of this, different applications will be able to tolerate different caseloads of different devices. That is why it is imperative that any project conduct performance testing of their own application on their own devices before launching a project.

Common Questions

Some frequent questions that arise when thinking through Application Performance issues in CommCare are:

• How many Cases are too many?

• How many Case Properties can I save?

• How many questions can I have in my Form?

• What can I do when my application starts to get slow?

These questions have many dimensions, and this page is intended to help you think through them. The acceptable number of cases varies depending on several factors including Case Size, Question Type, Device type, and desired Sync Time.

Case Size

Case Size refers to the amount of data and metadata associated with a particular case within the application. The size of a case can impact performance and storage, so it's helpful to understand what contributes to case size.

• Number of Case Properties: The more properties a case has, the larger its size.

• Data Types (e.g., text, integers, dates, multimedia): For example, text fields typically consume more space than integer fields.

• Case History: CommCare tracks changes to case properties over time. A detailed case history with many updates can increase the overall size of the case.

• Case Relationships: Parent-child relationships add metadata to the case, contributing to its size.

• Multimedia Attachments: If a case includes multimedia files (e.g., images, audio recordings), these files significantly increase the size of the case.

• Form Submissions: The number and complexity of form submissions linked to a case also affect its size. Each form submission can update case properties and add to the case history.

• App Complexity: CommCare allows for incredibly complex apps–employing multiple data types, advanced functions, repeat groups, lookup tables, and more. This can result in redundancies, complex hierarchies, and an increase in the number of data fields that need to be stored.

• Case sharing: This will not add to the Case Size, but may require more frequent syncing in order to maintain up-to-date information.

Device type (Web Apps vs Mobile)

Some projects use Web Apps only, some use Mobile only, and some use a combination of the two. The speed of syncing and app and its cases is dependent on:

• Internet speed

• Device speed

• Memory

You might find that because of the type of device that you would use Web Apps on, the syncing is faster. There is also a more continuous syncing with Web Apps (vs syncing everything at once) that will allow for faster (and larger) syncing with Web Apps. 

The sync time with the server is affected by the total number of cases on the phone or Web App. Therefore, the first sync will be slower. However, subsequent syncs will be faster and are less likely to time out. The server calculates the data to be sent to the phone or Web App during the first sync request and will cache the data for subsequent requests even if the first sync times out.

Maximum Desired Sync Time

This refers to how long of a sync time your users can reasonably handle. There is, of course, the chance that the device will time out if the sync is taking too long, but also there is the experience of the user to consider. Waiting 15 minutes for a sync to complete may not be something that they can accommodate in their daily workflow. You may decide to sync fewer cases in order to shorten the sync time.

Best Practice

• Reduce the number of Case Properties. All of the data you collect will be in your form, so only save the data necessary for identifying the case or for use in follow-up forms as Case Properties. 

• Archive or Close Old Cases. Only open cases will sync to the app, keeping the sync time lower.

• Upload Small Multimedia Files. Adjust your device’s camera to take smaller photos (<1 MB).

• Reduce Case Updates. If a form does not change the value of an existing Case Property, don’t update it. This will keep the case history concise.

• Carefully review your app to be sure that it is efficiently gathering the data you need, without redundancies. Organize your cases in such a way that users can sync all of the cases they will need to do their work before their next sync.

• Try putting your questions into question groups rather than lists.

• Wrap your queries in if statements so that the calculation is only performed when needed.

How many Cases are too many?

Coming back to one of the original questions, “How many cases are too many?” This will depend on all of the factors mentioned above, but generally speaking, in our experience we’ve found:

• Technically feasible: 10,000

• Best practice: 1,000

The only way to be certain that your app will be performant is to test this for yourself, on your own devices, at the anticipated load. A rough rule of thumb for an "average" case is that every 25 cases or so will add an additional second to the sync process.

How many Case Properties can I save?

There is no definitive answer, due to the variety in applications, but after about 500 you are definitely at risk of mobile performance issues. And if your app is more complex, then even 500 may be too many. It’s important to test.

In addition to mobile performance, remember that many other parts of the platform-- like data exports, data dictionary, and the form builder-- that all rely on case properties. These part of CommCareHQ will also begin to slow down and become unwieldy the more case properties you save. Eventually, these, too will start to break at high loads (500+).

How many questions can I have in my Form?

Again, there is no definitive answer, due to the question types that are available (e.g. Lookup Tables, Multimedia Capture) as well as the complexity of calculations that you can have on your forms. Similar to Case Properties, 500 is definitely the number where the risk of issues exists. It’s important to test as you build.

In addition to what the system can handle, it’s also important to think about what the Healthcare Worker and Client can handle in terms of form length. Because you are using cases, take advantage of the option to have multiple follow up forms. Many projects have told us that their users (and clients!) cannot handle more than 100-200 questions in a form at once. In this case, you will almost certainly hit human capacity issues before you hit technical capacity issues.

How to Test

Generally, we recommend testing your particular scenario with cases created using the Excel importer tool.