I am working on setting up a new system for publishing content. I have a few different categories of content that I’m interested in creating. I’ll have to determine exactly what the taxonomy will be, but the broad categories will probably be computers, mountain biking, and more personal stuff including relationships and religion. The first step towards this new system is just to replace the technology behind this website.
This website is currently generated statically using a very old version of jekyll/octopress. Static site generation is really nice, but I think I’m going to want to add some more interactive features like small applications. Therefore, I decided to replace this static site generation approach with a Clojure application.
Since these posts currently are all written in markdown and then parsed and rendered into HTML before being served statically via nginx, I wanted to check to see how expensive it would be to parse and render the markdown into HTML on every page load. To evaluate, I used a couple of handy Clojure libraries – markdown-clj and criterium. Using markdown-clj
it was fairly trivial to replicate the functionality of the markdown processing of octopress. It is even has the ablility to parse the metadata at the top of the markdown files. For example, this is the metadata that I have at the top of this post:
1 2 3 4 5 6 7 |
|
To parse that metadata, I simply had to pass in the :parse-meta? true
option when parsing, like this:
1
|
|
Then the metadata is parsed nicely into a map for me:
1
|
|
You can see more detail in the source code on github.
Finally, I created an uberjar using lein uberjar
, uploaded it to the DigitalOcean machine I intend to use, and ran the benchmark using criterium:
1
|
|
Because of this issue, I also had to call flush
afterwards to get the output to display correctly. Again, you can see more detail on github.
Once I ran the benchmark, criterium gave me some useful results:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
I can see there that it takes about 20ms to parse a typical markdown file for one of my blog posts. That would mean that, ignoring other overhead for serving a webpage, I could serve about 50 pages per second. That seems more than acceptable for the amount of traffic I expect to receive on this blog.