JSONStore performance

Network

• IBM MobileFirst™ Platform Foundation provides APIs for getting information about the network, for example, WL.Device.getNetworkInfo (JavaScript). Ideally, getting and sending data from and to a MobileFirst adapter should be done when the application is using a WiFi network.
• Check network connectivity before you perform operations, such as sending all dirty documents to a MobileFirst adapter.
• The amount of data that is sent over the network to a client heavily affects performance. Send only the data that is required by the application, instead of copying everything inside your backend database.
• If you are using a MobileFirst adapter, consider setting the compressResponse flag to true. That way, responses are compressed, which generally uses less bandwidth and has a faster transfer time than without compression.

Memory

• When you use the JavaScript API, JSONStore documents are serialized and deserialized as Strings between the Native (Objective-C, Java™, or C#) Layer and the JavaScript Layer. One way to mitigate possible memory issues is by using limit and offset when you use the find API. That way, you limit the amount of memory that is allocated for the results and can implement things like pagination (show X number of results per page).
• Instead of using long key names that are eventually serialized and deserialized as Strings, consider mapping those long key names into smaller ones (for example:myVeryVeryVerLongKeyName to k or key). Ideally, you map them to short key names when you send them from the adapter to the client, and map them to the original long key names when you send data back to the backend.
• Consider splitting the data inside a store into various collections. Have small documents over various collections instead of monolithic documents in a single collection. This consideration depends on how closely related the data is and the use cases for said data.
• When you use the add API with an array of objects, it is possible to run into memory issues. To mitigate this issue, call these methods with fewer JSON objects at a time.
• JavaScript and Java have garbage collectors, while Objective-C has Automatic Reference Counting. Allow it to work, but do not depend on it entirely. Try to null references that are no longer used and use profiling tools to check that memory usage is going down when you expect it to go down.

CPU

• The amount of search fields and extra search fields that are used affect performance when you call the add method, which does the indexing. Only index the values that are used in queries for the find method.
• By default, JSONStore tracks local changes to its documents. This behavior can be disabled, thus saving a few cycles, by setting the markDirty flag to false when you use the add, remove, and replace APIs.
• Enabling security adds some overhead to the init or open APIs and other operations that work with documents inside the collection. Consider whether security is genuinely required. For example, the open API is much slower with encryption because it must generate the encryption keys that are used for encryption and decryption.
• The replace and remove APIs depend on the collection size as they must go through the whole collection to replace or remove all occurrences. Because it must go through each record, it must decrypt every one of them, which makes it much slower when encryption is used. This performance hit is more noticeable on large collections.
• The count API is relatively expensive. However, you can keep a variable that keeps the count for that collection. Update it every time that you store or remove things from the collection.
• The find APIs (find, findAll, and findById) are affected by encryption, since they must decrypt every document to see whether it is a match or not. For find by query, if a limit is passed, it is potentially faster as it stops when it reaches the limit of results. JSONStore does not need to decrypt the rest of the documents to figure out if any other search results remain.

More information

For more information about JSONStore performance, see the JSONStore performance blog post.