Jello framework

Writing a high performance scalable web application requires close attention to details. Jello improves the performance of your application by caching query requests results. Even so, you can still easily fall into performance traps if you don't know where to look for them.

Jello cache

Performance traps

Jello will make the best effort trying cache REST queries and keep the results cached as long as they are still valid. In order to achieve this, the built-in cache mechanism takes into account the dependencies between different entities and the data access privileges defined for each entity. Based on the data model, it might cache queries from different users separately or not cache other queries at all. The cache manager keeps track of changes in the database like adding, updating, and deleting of instances and will invalidate cached queries accordingly.

Jello cache implementation uses the underline Google App Engine Memcache API.

Cache Settings

By default, Jello cache is active for the production server and off for the developer server, cached query results will remain valid as long as possible, and the entire cache will be reset upon deployment of a new application version. To override this behavior, you can add the following to app.yaml (or to web.xml). (See also the application configuration file):

    servlet: jello.JelloServlet
    name: Jello
      # Default is 'true' false	
      # Default is 'true'
      jello.cache.flushOnDeploy: false	
      # Default is -1 (as long as possible)
      jello.cache.validTimeSeconds: 3600					


Jello cache's underlying implementation uses the GAE Memcache Java API. Refer to GAE documentation for more information about the Memcache configuration and quotes.

The following actions are available both from the JAVA API and the REST API


jello.cache.MemCache {

   public static Boolean isActive();

   public static String setActive(Boolean flag);

   public static String flush();

   public static String setValidTimeSeconds(Integer seconds);






Cache Info API

Use $debugLevel 3 and up to include cache information in the REST result

custom control file

Subset requests

Avoid full requests for entities with lots of instances. Use $top query option whenever possible.

$skip performance hit

Skipping records causes a performance hit since all the records up to the skipping position are still retrieved internally. If possible, try to utilize the query $cursor support instead.

$inlinecount performance hit

This option will force a full scan of the entity's records even for subset requests. Try to add $filter whenever applicable.

Save bandwidth by reducing the response size

Limiting the number of records retrieved is one thing, but one can go even further and optimize the size of each returned record.
Use $select wherever applicable to include only the necessary information in the response.

Use asynchronous action for long execution tasks

Sometimes, it is desired to execute an action asynchronously, especially if you know this action's execution time might exceed App Engine 60 seconds limit. See Asynchronous actions for more details.

Last updated December 30, 2015.