Friday, December 9, 2011

Updating schemas in App Engine [post price increase]

Since Google's App Engine got significantly more expensive, it has become more difficult to update all entities for a model while staying under the free quota.  

There are many reasons to update all the entities for a model: including
  • Updating a model's schema.
    • Adding new fields to exisiting entities.
    • Removing obsolete non indexed properties from exisiting entities.
  •  Adding an index for an existing property that was previously not indexed
Previously, a developer could use mapreduce operations to update their model's schema.  Mapreduce was great, it would iterate through my all my entities of a given type in under a minute (about 5000 entities or so).  Since mapreduce ran in minutes and developers never paid for datastore writes or reads under the old pricing scheme this update method cost almost nothing.

Under the new pricing scheme developers pay for datastore writes and reads.  To write an entity to the datastore the cost depends on the number of indexes on that entity:

New Entity Put (per entity, regardless of entity size)2 Writes + 2 Writes per indexed property value + 1 Write per composite index value
Existing Entity Put (per entity)1 Write + 4 Writes per modified indexed property value + 2 Writes per modified composite index value

Therefore, writing just one entity might result in 20 or more write operations.  Now considering the free limit for datastore writes is just 50,000 operations, we can reach the limit of writes in a day by writing just 2,500 entities that require 20 write operations each.  If developers try to use map reduce on any data set the daily quota can be exceeded in just one mapreduce step.  What used to be a completely free operation now could cost some money.

Image Source


Ideally it would be nice to have a method to search for all entities that do not have a given property or are not indexed, but unfortunately that cannot be done in App Engine.

To work around this problem, I have added a property "meta_version" to all of my models.  Initially meta_version is set to 1 for all my entities.  Now if I need to update my model's schema, over several days, I can run a search for entities with their meta_version set to 1 and bump the version to 2.  Since meta_version is indexed, I can run a search for those entities and just update 100 entities at a time.  In this way I can stay under the free quota.



For example after adding the field to your model:
class MyModel(db.Model):   
    # Add this field to all models with a large number of entities.
    meta_version = db.StringProperty(default='1')

Add a view which iterates through the entities a few at a time:

def update_my_model(request, num_entities = 100):
    entity_list = MyModel.all().filter('meta_version =', '1').fetch(num_entities)
    for entity in entity_list:
        entity.meta_version = '2'
    db.put(entity_list)

Now you can slowly evolve your model's schema or index old unindexed properties while staying under your free quota!  Of course the final irony is that in order to add the meta_version field to all entities you have to update all of those entities without using this method.

Saturday, January 15, 2011

Speeding Up Pages in App Engine - Part 3 [django specific]

In past blogs, we've looked at two techniques for speeding up pages. These ideas boil down to:

The next step is to look at the actual python code serving the requests and speeding it up.

Some background:
MindWell uses Django to serve the requests.  For those unfamiliar, Django is a great project that uses the MVC (Model View Controller) architecture.  In Django you create templates containing the html of the page.  Normally, these templates are great because they offer code reuse and performance is not a problem.  However, on one page I found a performance bottle-neck, so I resolved the issue by skipping the template system altogether.  Sometimes it is good to be different:

In MindWell there is a calendar that shows appointment dates and to the user similar to Google Calender.  Mindwell uses FullCalendar which has the ability to take JSON objects and render them on the calendar.  In MindWell there might be 100-300 appointments in one stream of JSON objects.  

Here is one such JSON object:
[
{
"title":"ClientLastName, ClientFirstName",
"start":"2011-01-11T11:00:00",
"end":"2011-01-11T11:45:00",
"allDay":false,
"url":"/Mindwell/2011/01/11/11/00/436/calendar_dos/",
"note":"",
"className":"scheduleClient",
"description":"Session Type:None
Session Result:Scheduled
DSM Code:None
Type of Payment:None
Amount Due:None
Amount Paid:None
Note:None
DOS Date and Time:2011-01-11 11:00:00
DOS Repeat:No
Repeat End Date:None
"
},
...

When I profiled the performance of the template rendering the JSON data, I found it was too slow.  Instead of rendering the objects using a template, I rendered them directly in python.  

Below is the code that renders the feed.  Normally in Django, we return the rendering of a template. Here, however, we create an HttpResponse and text directly, then set the mimetype to json.
#click this link for the code itself
def calendar_feed(request):
    if CheckUserNotAllowed():
        return CheckUserNotAllowed()
    start = request.GET.get('start', None)
    end = request.GET.get('end', None)
    if not start:
        return HttpResponse('')
    if not end:
        return HttpResponse('')
    cal_feed = CalendarFeed(request, 
        datetime.datetime.fromtimestamp(int(start)),
        datetime.datetime.fromtimestamp(int(end)))
    return HttpResponse(
        cal_feed.GetFeed(), mimetype='application/json')


The code that turns each object into a JSON object is shown below.  Note that I still call escape to prevent various Javascript and other attacks.  I want to use the <br/> tag in my JSON object so I put the <br/> tag back in.


#click this link for the code itself
def escape_json(text):
  """ 
  escape html using django (replace single slash with double for
  javascript and finally put back in our<br/>
  """
    return escape(text).replace('\\', 
        '\\\\').replace('&lt;br/&gt;', '<br/>')
        
def Javascript_Object_DOS( dos):
    """ 
    Converts a DOS to JSON.
    """
        return """
{
"title":"%s",
"start":"%s",
"end":"%s",
"allDay":false,
"url":"%s",
"note":"%s",
"className":"%s",
"description":"%s"
},
            """ %(
                escape_json(unicode(dos)), 
                dos.get_starttime().isoformat('T'),
                dos.get_endtime().isoformat('T'), 
                dos.get_calendar_absolute_url(),
                escape_json(dos.get_note()), 
                dos.get_class_name(), 
                escape_json(dos.get_hover_tip())
            )


By replacing the Django template system, I was able to reduce the rendering time of the JSON data by ~30%.  The rendering times in some of the bigger streams were reduced from ~650ms to ~400ms.

The bottom line is this.  While Django's template system is good, there is some overhead associated with using Django's templates. In some cases, it may be worth skipping the templates for your slower or high traffic pages.