I finally decided to add tags to our (my) blog; for example: programming. And I realized I wanted to use that project as a way
to learn the rust programming language. (So not really a blosxom
plugin for Blosxom.) I don't expect this to be of interest
to anyone other than me but... (If you are interested, here's zip file of the small
source tree — cargo build and you should have 6 small programs.)
With a config.txt file like this simple example (in my case in the same directory as blosxom) you can call the command line programs to read and write simple text files for tags. Entry files (use the filename of the blog post entry file) have topic tags in them. Topic files (use the topic name as the filename) have entry filenames in them. So your tags directory ends up with a bunch of small files.
We'll see how the performance with this goes (it's very early days yet -- but see below). I wanted to not impact the normal blog entries and I'm hoping those small files will be quick to load and update as needed. And I can claim to being a junior Rustacean now :)
A few minor updates needed to the main blosxom and wikieditish perl programs to call those command line tools and updates to the templates to show the tags, seem to have it all working. (If you are interested in those changes, I can pass those along as well.)
And I have some notes here on the blog itself :)
The tag binaries are not meant to be available by URL to the world; they are incorporated into the main blosxom and wikieditish plugin scripts. So I have an Apache forbid rule for that directory; it won't allow URL access. Also, maybe more important, the topics query string is easy to manipulate so in both blosxom and (perhaps less importantly since it's password protected) in wikieditish, cleanse the topic tags to only allow the character sets you expect for file names (letters, numbers and underscore in my case).
There is no free lunch, we know. I ran a little Apache Bench test (summary, full results) to get a quick peek. There is about a 12% increase in total test time (10 concurrent, 100 requests), 11% decrease in requests per second and 7% decrease in transfer rate between the old (non-taggy) and new (tag-enabled) blog home page. So just the logic to grab and display the tags per "normal" entry.
I also looked at a tag query page and that showed about a 14% increase in total test time (10 concurrent, 100 requests), 12% decrease in requests per second and 19% decrease in transfer rate when compared the the default page.
But in terms of noticable times (which seems reasonable for a web site with virtually no traffic), that means the tagless test took 3.262 seconds (again, 10 concurrent, 100 requests) vs. 3.657 seconds with tags vs. 3.707 for the tag query. It's hard to notice a half second. Final comparison, the very simple kayakero.net homepage testing (same -c 10 -n 100) completed in 0.106 seconds.
Powered by:
