Home > gsoc > Profiling, Testing and Documentation

Profiling, Testing and Documentation

Performance and Profiling:


    • Template caching:
              return render('base/csubjects.html', cache_type='memory',

      This keeps the template output in memory cache for a period of 60 sec. This has resulted in a huge performance gain.
      Also, cache_expire time can be more than 60 sec. in our case.

    • Turn off debug in .ini and dont use –reload when starting the server
    • Turn off Mako’s template checking:
      Another important flag on TemplateLookup is filesystem_checks. This defaults to True, and says that each time a template is returned by the get_template() method, the revision time of the original template file is checked against the last time the template was loaded, and if the file is newer will reload its contents and recompile the template. On a production system, setting filesystem_checks to False can afford a small to moderate performance increase (depending on the type of filesystem used).

Profiling using repoze.profile:

  • Integrated repoze.profile with ArchiverUI to see which portion of the code is taking the longest. Right now, it seems that hide_quoting component can be further optimized.
  • Functional Testing with Nose:
    Added some tests to check basic responses of different pages of ArchiverUI. For example, make sure the response is 404 if any invalid url is passed and response contains correct page for every valid url.
  • Made a few modifications to code more readable and started adding docstrings
Integrating with Mailman:
Currently, ArchiverUI just requires a sqlite db file containing tables for articles and conversations. I have kept one more table in db containing information about all the mailing lists.

class Mlist():
    """Class to represent an mlist table in a sqlite database"""
    __storm_table__ = "mlist"
    id = Int(primary = True)
    list_name = Unicode() 

    # Path to the archives database corresponding to the list_name mlist
    db_path = Unicode()
Now, these thing need to be done:

  • whenever a new  list is created, update mlist table
  • whenever a message is archived, update the database file corresponding to that mlist.

  • Generalize for more than one mailing list
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: