Performance of Data Access
You need to consider performance when designing a mobile app. Use this topic as a reference when you design the functions and data structure if your mobile app will handle more than a few tens of data items in one action.
It is very important to be able to estimate API execution times if your mobile app will use external services and libraries like Kii Cloud.
This topic explains how to address a situation where a user transfers large amounts of data in one action. With Kii Cloud, you do not need to pay special attention to the number of users as far as the implementation does not contain any task that can be a bottleneck due to the number of users. Kii Cloud ensures the scalability to support increasing users.
API execution times
When designing a mobile app that uses Kii Cloud, it is important to understand that access to Kii Cloud takes longer than that to the local storage.
See the table below for expected processing times for writing simple JSON data to three types of storage.
| How to write | Expected processing time |
|---|---|
| Output a file to a local PC | Under a few milliseconds |
| Output a file to a network PC | Several tens of milliseconds |
| Execute a Kii Cloud API via a 4G network | More than a hundred and several tens of milliseconds |
One API execution to Kii Cloud often takes more than 100 times as long as writing to a local PC storage. In addition to the processing time for providing the cloud service, network latency that is caused while the device accesses the server via the Internet makes the total processing time longer.
Execution of a few APIs should complete within a second. However, if an API is executed 100 times, it would take 10 to 30 seconds.
If your mobile app will handle many KiiObjects, learn the characteristic of each API and then design the data structure and functions. The general characteristics of reading and writing on Kii Cloud are described below.
Writing data
If the number of data items is high, it leads to performance losses. This is because one API call adds or updates only one KiiObject. Batch writing is not available in Kii Cloud. The number of required API calls is the same as that of KiiObjects to add or update.
Reading data by specifying a KiiObject ID
If the number of data items is high, it leads to performance losses. This is because one API call gets only one KiiObject if its ID or URI is specified. The number of required API calls is the same as that of KiiObjects to get.
Reading data by a query
If a query is used, performance issues are not likely to occur in terms of data retrieval. This is because one query gets up to 200 KiiObjects.
However, design your query carefully. Complex queries can cause performance losses. For more information, see the learn more section at the end of this topic.
See the table below for actual measured times for the above three tasks that access Kii Cloud. 3,000 KiiObjects that have two key-value pairs were accessed from an Android device via a 4G network.
| Write | Read by an ID | Read by a query |
|---|---|---|
| Approximately 8 minutes 3,000 API calls |
Approximately 6 minutes 3,000 API calls |
Approximately 3.2 seconds 16 API calls |
The values in the table are reference values and not intended to warrant performance in any production environment. The processing time varies depending on various elements such as the network distance between the device and the server, network speed, amount of transferred data, processing on the server, server load, and so on.
Contact Kii in advance if you are planning to measure performance through tests such as a load test with multiple clients.
Kii Balance writes data items one by one by letting the user operates the user interface. It reads data items in a batch with a query when the data listing screen opens. From the above table, it can be said that the specification of Kii Balance is unlikely to cause performance issues even if the number of data items is increased.
Techniques to process large amounts of data
If the specification of your mobile app requires access to large amounts of data, you need to devise various ways to address it.
This section introduces the following two techniques.
Reducing the number of data items by nesting
In order to handle large amounts of data, you can store nested data in each KiiObject.
For example with Kii Balance, multiple income and expense entries can be stored together as a JSON array in one KiiObject. You can reduce the number of KiiObjects and API calls.
The maximum size of JSON format data stored as key-value pairs in a KiiObject is 65534 characters including internal fields used by Kii Cloud such as _id and _created. You can determine the number of entries to be nested in a KiiObject from data such as the maximum length of each input area defined in your mobile app.
For accessing an array of JSON objects, refer to the programming guides. For Android, see the sample code in Setting complex data and Getting complex data. For iOS, see the sample code in Setting complex data and Getting complex data.
Note that nested data in a KiiObject cannot be queried because only the first-level fields within the JSON expression are queried. To provide searchability, set a special query key in a first-level field and nest only data items that match the key.
Nesting within a KiiObject decreases program maintainability and data flexibility while it improves performance. Consider nesting only for areas that require performance tuning on the basis of the usage and expected amounts of data.
An example of performance improvement
See the table below for the effect of nesting. As with the previous table, this table indicates actual measured times. 3,000 entries are divided into 3 KiiObjects for the cases with nested data.
| Data is nested | Write | Read by an ID | Read by a query |
|---|---|---|---|
| No | Approximately 8 minutes 3,000 API calls |
Approximately 6 minutes 3,000 API calls |
Approximately 3.2 seconds 16 API calls |
| Yes | Approximately 1.2 seconds 3 API calls |
Approximately 0.6 seconds 3 API calls |
Approximately 0.4 seconds 1 API call |
As with the previous table, the values in the table are reference values and not intended to warrant performance in any production environment.
The performance of writing and reading by an ID is greatly improved and it is a few hundred times better than that of processing non-nested data. This is because those tasks handle KiiObjects one by one. The improvement in reading by a query is relatively small because one API call gets up to 200 KiiObjects.
Distributing loads
It is necessary to avoid load concentration because heavy loads on the servers can cause various problems.
You need to address server load concentration if you cannot avoid reading or writing large amounts of data or if certain events might cause access concentration. Be careful about the concentration of API calls especially when active users simultaneously access Kii Cloud. It can be triggered by a marketing notice or a release of new features through media or push notification.
Suppose one task in your mobile app involves 100 API calls. If 10,000 clients execute the task at the same time, 1,000,000 API calls are made in a short time.
Kii Cloud returns an error if there are accesses that greatly exceed the ordinary load to the server within a certain period of time for an application. The limit is high enough for ordinary changes in the operational load. However, if active users simultaneously send a request, it could cause an error.
If load concentration is expected, devise ways to distribute loads. For example, you can have the clients gradually read or write in the background, and use random numbers that are unique across devices to set different start times for a certain task.
What's Next?
Let us review how to keep data consistency by design.
Go to Data Consistency.