Wandering Thoughts archives

2013-03-25

Rethinking avoiding Apache

Somewhat recently I wrote about when I'd use a web server other than Apache (despite Apache's temptations). I've recently discovered that I need to change those opinions somewhat; Apache turns out to be much more usable than I expected in a constrained resources situation.

One of my recent hobbies has been testing DWiki in a low-memory virtual machine (as I mentioned once in passing). I did my primary testing using nginx because it had an SCGI gateway, but with that working I decided on a whim to see how Apache plus mod_wsgi would do in the same small VM. To be honest, I expected Apache to explode spectacularly under any sort of real concurrent connection load, driving the virtual machine into the ground in the process.

To my total surprise, this did not happen. Not at all. Instead a more or less stock Ubuntu 12.04 Apache plus mod_wsgi setup handily dealt with all of the load I could throw at it. In my limited testing it was actually slightly faster on average than my nginx setup, dealt better with really extreme numbers of concurrent connections, and still left the machine with free memory. It was also easier to manage than my nginx lashup, which needed a separate system to run and restart the SCGI-based WSGI server that nginx talked to.

Part of this seems to be that Ubuntu 12.04 has sensible (ie small) Apache configuration settings. Another part is that mod_wsgi totally isolates the WSGI serving into separate processes (although they are still Apache processes). But regardless of all of this the whole setup just works and does so in an environment where I had previously expected Apache to be completely unsuitable. I am metaphorically eating my hat right about now.

(If I ever do deploy DWiki into such an environment, Apache plus mod_wsgi is now going to be my first choice. Not for performance, I doubt there's any meaningful practical difference, but because it's easier to manage because everything is in one spot and mod_wsgi has good support for easy code reloads.)

Sidebar: a caution about my performance results

Siege, the load tester I was using, reports only the average request time (and the maximum and minimum); it doesn't provide any difference about the distribution. It's possible that the distribution of response times is worse with Apache and the average is masking this. To do real testing I'd need to find a more thorough HTTP load tester (well, one with better stats reporting).

web/RethinkingAvoidingApache written at 22:33:44; Add Comment

My (current) view of using branches in VCSes

In a comment on this entry, Aristotle Pagaltzis asked:

(Though I admit I wonder why you do have fred-1 and fred-2 [source directories] rather than branches in your VCS.)

The simple answer is that my favorite way of changing branches is with cd. This is especially the case if I'm developing things in parallel and may well wind up throwing one of them away; for good reasons VCSes make totally deleting a branch much harder than a plain 'rm -rf'. I'll admit that part of my preference is because I haven't yet gotten around to master branching in either git or Mercurial (partly because I frankly don't entirely like it or need it yet).

(Some people will say that you should keep even experimental stuff that didn't work out in your VCS in case you ever want to go back to it later. This may work for them but it doesn't work for me; I want my VCS to be neater than that.)

But even without that I think cd is much easier than going back and forth between branches in the same directory hierarchy, especially if you're developing on both branches. With today's VCSes, flipping back and forth between branches generally wants you to have actually committed your work to both of them and this itself leads to messy history (or to a lot of redoing commits or the equivalent, as you commit only so that you can flip branches, then annul and overwrite the commit the next time). I also personally think that it is a cleaner and more natural model for (multi-)branch development, with the only downside being more disk space being used.

(And disk space is generally cheap unless you're dealing with huge repos. The two largest repos I have handy are Mozilla and the Linux kernel; Mozilla is 2 GB and Linux is 1.2 GB. That's not going to break the bank on modern machines.)

I understand why VCSes have branch-switching commands (they can't not have them, to put it one way) and the benefits of having multiple branches in the same repo (including things like being able to do easy diffs between branches). But it just doesn't fit into the way that I prefer to interact with VCSes and I like to keep my life simple.

programming/MyVCSBranchingView written at 01:20:58; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.