Anthony Panozzo's Blog

I have been interested in seeing how well my blog would do under heavy load. In the back of my mind I was worried about an article getting really popular and taking my blog down, so I decided to see how much load my server could take before it happened. Obviously being too popular is a good problem to have. This experiment was partly just to give myself fewer excuses to create awesome posts. In case you were interested in the same thing, here is what I did.

But please, use your own blog or website to experiment.:)

Select a load-testing tool

I wanted to survive a fairly heavy load, so I was looking for around three responses per second from the server (which amounts to about 10k requests served per hour.) Anything more and I guess I'll have to turn people away. ;)

I looked at some load-testing tools that were available for Ubuntu (my home machine), and siege seemed to be the easiest to install and use. Installing was as simple as:

sudo apt-get install siege

Siege comes with a man page and some basic examples. There are a lot of neat options, but I didn't want to spend too much time on load-testing. One of the best things about this tool is that it tells you that it's "preparing users for battle" and laying siege to the server, which is just fun.

Here are some threads that I've been reading or interested in from the last year or so. I typically find links tweet-worthy, not blog-worthy unless I have significant original thoughts to contribute. If you don't think one link is valuable, the next one will likely be better. Many of these won't be safe for work (although what does that really mean?) I'm not saying that I agree with them. Just think that they are interesting or resounded with me when I read them. This is more than you can probably consume in a day, so feel free to Control-D. I considered breaking it up, but whatever. Consider it your Google Reader for a week. Here goes.

A ton of resources on lean software engineering (I have not specifically investigated these sublinks, but seems like a recent, solid, quality page. I'm pretty sure every other article on this post I've read fully.)

Of course, my favorite article since college: How to Create Wealth

One of my favorite blogs with an interesting topic and high signal post here. Perhaps a bit verbose.

From the same blog, this article parallels some thoughts that I have had recently on children and creating products. Perhaps more about this another time or in person.

And one more for good measure: how to train yourself to spot opportunities

I recently had a chance to use the Git interface to Subversion (git-svn), and it's the best way that I've found to work with Subversion (SVN). Using git-svn is better than using plain SVN. The primary reasons I feel this way are that it provides a convenient staging environment and superior local branching capabilities.

The staging environment provided by Git means that I have a local version control system that no one else can see. This allows me to take continually check things in without worrying about mucking up the general repository. I like this because I can make changes quickly and check in whenever I make progress and things mostly run correctly. This is great because I hate it when things are improving and then I make some boneheaded change to a bunch of files and can't figure out how to get back to a working state.

When I'm ready to check into the shared repository (in SVN), I can do this as a separate operation. What's nice is that I can squash, modify, and reorder local commits so that my development history is clean of the rabbit trails that inevitably pop up. Theoretically, the staging environment allows me to not need to run full test suites before locally committing to ensure that I don't break the build. This was not really a gain that I utilized though.

The second advantage was quick local branching capability. This allowed me to have several streams of development going that were mostly independent of each other. This was invaluable for quick bug fixes, and helped when work was blocked due to a client member being unreachable. Another great advantage was the ability to have my master branch be clean and always be ready for a demo. Git branches differ significantly from SVN branches, in that they are much faster to work with, require less space, and, perhaps most importantly, Git offers better merging capabilities.

I have been doing a lot of writing lately and was interested in automatic versioning so I could see the results of writing over time and how things change. I think that it would be really interesting to see a visualization of a book being written from scratch. Normally you only see the end product; tracking changes over time would allow others to see the sausage being made. This could be useful for teachers to help their students improve their process, for writers to analyze their craft, or for aspiring writers to see how books really get written.

Here's a demo of what I envisioned using a recent blog post that I wrote using the following method.

The system uses git for version history. I also used a Vim hook that checks in the current file on buffer writes:

cabbr autocommit call Autocommit()
fun! Autocommit()
  au BufWritePost * silent !git add <afile>
  au BufWritePost * silent !git commit <afile> -m 'Generated commit'
endfu

This is about the finest grain of editing that I can imagine being useful and that was practical to do. Anything lower-level and you're probably looking at the document as the cursor is moving around. Commits are nearly instantaneous, and you can amend commits to explain complicated changes. Git branching seems to work well with this system. Hence, you can have multiple streams of writing. If you're working with other people, you could be writing a new chapter when you get some feedback on the last chapter which you would like to add. Simply create a branch from the time that you sent the document out, and you should be able to see exactly what the reviewer saw. In addition, authors of collaborative works can use the push/pull functionality to manage copies, which is probably better than emailing documents around. See this page on collaborative writing for more ideas.

Well, it's been a year since I started this blog, and I have been pleasantly surprised by the personal changes that I have seen, as well as other people's responses to my writing.

I appreciated feedback that people gave me over the course of the year, whether through comments or discussions. This helped me realize that I can provide value through writing and that people are actually interested in reading what I am thinking about.