Posted on by Jeff Knupp
As a single founder, I realize I am at a tremendous disadvantage when it comes to non-technical work. There are only so many hours in a day, and I have a full-time job. Work on linkrdr, therefore, must be prioritized. With so many interesting technical challenges to solve, a number of other useful activities fall by the wayside. Marketing is a big one. So how do I focus my efforts? By building my personal brand.
Posted on by Jeff Knupp
Caching is a subject near and dear to the heart of many performance-minded programmers. For those coming to web programming without other programming experience, caching may be a new topic. For programmers new to the web, using an external cache may be an approach not yet considered. In this post, I'll describe how, through the use of Django's caching support, I was able to reduce linkrdr's page load time from over 3.5 seconds to 0.01 seconds.
Posted on by Jeff Knupp
I was a bit under the weather this past weekend, but it turns out I wasn't the only thing to go viral. Below is a brief story of how linkrdr enjoyed it's first encounter with virality.
Before Saturday, linkrdr had about 10 users, who had figured out a way to sign up without me really providing one. Sometime Thursday evening, I believe, I slapped a 'Beta' sticker on the front page, cleaned some stuff up, and declared linkrdr open for business. Come the weekend, I was under the weather and not feeling like working on anything, so I didn't check any of my sites until Monday at 4pm. I cruised over to my Clicky dashboard and took a look at the stats for this blog. Then something caught my eye...
{% img http://66.228.46.113/static/img/linkrdr_growth.png linkrdr visits per day%}
Posted on by Jeff Knupp
In my previous post I outlined the method by which one goes about profiling a Django application. I used a view from linkrdr as an example. That view is responsible of aggregating, ranking, and sorting all of the links in a user's feeds (RSS, atom, Twitter, etc). The code from the post was an early, simplistic implementation of the view. I have, however, a much more robust scoring algorithm, written in Python, which I planned to used on the site.
You may have caught the word 'planned' in there. The algorithm turned out to be too slow. Rather, my Python implementation of the algorithm was slower than what I deemed acceptable. After thinking of various architectural changes that could be made to solve the problem, I settled on a somewhat radical solution for a Django developer: I implemented the view in C++.
I realize that not every Django developer knows C++, nor should they, but those that do should realize it's a viable tool available when Python is just too slow. Eventually, you may get to a point where you can't really optimize your Python code any more. In this case, profiling will show that most of your time is spent in Python library calls. Once you hit that point, you've either written a horribly inefficient algorithm or you've got a problem not suited for Python.
When I realized I had hit that point with my view code, I panicked. 'What more is there to do?' I wondered. Then I remembered a work project where I had written some C++ code that interfaced with Python. From a technical perspective, there was nothing stopping me from implementing some aspects of my Django app in C++ (besides the fact that it's excruciating to write in coming from Python). Since linkrdr is a single-person project, there are no teammates who need to grok the code. I'm free to implement it as I wish.
Posted on by Jeff Knupp
In this post, I'll discuss profiling Django applications through a case study in linkrdr's code. Through the use of profiling tools, I was able to reduce the number of database queries a view was using from 1300 to 2.
At some point in most Django projects, some part of the application becomes 'slow'. This doesn't have to be the case (more on that later), but it's often the result of changes made without performance in mind.
In the beginning, this is actually a good thing: focus on making it work first, then focus on making it fast. Of course, you don't want to code yourself into a corner by writing code that "works" but does so in a way that it will never be fast. Instead, you want to keep performance in the back of your mind while implementing a solution that makes sense.
Once you've proven your solution works through your automated tests (You are using automated tests, right?), the next step is to make sure its performance is acceptable. Note that I didn't say 'optimal'. Don't waste time making something faster than it needs to be. This should be common sense but, once the optimization bug bites, it's common for developers to go a bit off the deep end and keep trying to find optimizations long after it's necessary.