Back at the tail end of 2007, I began developing an open source Course CMS for Courses on the web. For technologies, I choose the Python language with the Django MVC framework as an initial code base deployed to an Apache server–the reason being that Django released under the BSD do as you please license had reached .96 Beta maturity and was showing strong potential as a MVC web framework that could one day outperform both Rails and Symphony and other popular frameworks. Also it looked like it would be fairly fun to work with.
Well 2008 came and passed, and I was left with a patched up version of Django .98 and a small streamlined product that could be connected into the University network and serve the same functionality as an existing product–well maybe. There were still core issues with the Django framework and I was convinced my time would better be spent elsewhere while I waited for things to catch up. I put the source on Google Code and left it for a rainy day. Well 2009 came, went and now today we are staring at the face of the Django 1.3 release where 1.2 brought an exciting new CSFR protection that was easy to convert existing projects and also felt worth doing.
Finally the product had come from concept to prototype to something worth testing upon. I began a search of the latest popular Django apps out there and discovered django-registration which would allow opening up registration to the public whereas before it was always imagined we’d stick to an LDAP creator function. While good, the django-registration app is still incomplete, but definitely deserving attention for anyone starting a Django project looking for a registration with activation example. Then I discovered the hottest Django thing yet: the Django Debug Tool Bar which, as an installable app, is easy to plug into a deployment of your project and will demo the full power of a modern Java Script marvel.
The Django Debug ToolBar lets you view the processing time for each request, as well as how much of that time is taken up in SQL queries, what those queries are, and how much time was spent in each query. Using this tool I was able to find bugs in my code that showed linear dependencies of queries existing in the template layer (because yes, Django templates can create queries when the Context dictionary doesn’t have all the data.) After seeing this tool’s Panel views, I was able to identify this issue type and then fix it using Django’s built in select_related on some of the QuerySet statements where the SQL gets generated. This tool combined with firebug, View Cookie, and Opera’s quick page markup validation has allowed me to highly optimize my GoogleCode project django-classcomm. In some cases page views reduced load time from ~250ms to ~125ms!
I would like to thank you for the efforts you have put in writing this website.
I am hoping to check out the same high-grade blog posts from you later on as well.
In truth, your creative writing abilities has inspired me to
get my own, personal website now 😉
Thanks for finally talking about >Optimizing SQL Queriws
in Django with very little code | matt.geekshack.net <Liked it!