The Humor Archives
So I have finally got around to updating my oldest (surviving) website The Humor Archives. This website has been around in some shape or form for 10 years and has up until two days ago been running on the same back end code; written in Perl with a hand rolled database (yes, I wrote my own database for it).
So what did I use to rewrite the site? Well to understand my decisions we have to look first at the none functional requirements of the site. It must be able to run on a single processor Pentium III with 384Mb of main memory, not only that but the sites operation must not negatively impact the other 20 or so sites running on the same box! Further the redevelopment must not take me more that a week of evenings to complete. As a final requirement all the sites URL must remain the same (I’ll come back to this).
OK, these requirements seem fairly doable but what volume of traffic do we have to serve? To be honest it’s not a super high traffic website; the figures break down like this: daily visitors: 6-7,000; page requests: 70-80,000. These are averages and so as a quick thumb in the air guess I would say about 30 maybe 40 concurrent user sessions at peak.
So with these requirements I obviously choose Java as the base technology, firstly because I know it well but more importantly Java provides me with a means of limiting the impact of this site on the overall performance the physical machine. By limiting heap size and various other jvm teaks I can get the most out of the box by pooling and reusing resources. The pooling and reuse starts at Sun J2SE 1.5’s super cool garbage collection and general optimisation and works up through Apache Commons DBHP to Hibernate’s EH Cache and beyond - it all works transparently and it works well.
First of all I started with a proof of concept using Tapestry (3.0.1), which I have to say I really liked, the component model is fantastic and something that I hope other frameworks will learn from. However there were a number of things I wasn’t completely happy with. Firstly I found the configuration files to be overly complex and under-ly documented, secondly I didn’t like loosing control of some of the lower level concerns such as session management, creation and so forth. For my site to be truely efficient I aimed to have it truely stateless but a number of Tapestry components were using sessions. Secondly I was having to seriously hack the framework to get ‘friendly urls’ or rather the same urls as the old site. Getting the old urls to work was as simple as configuring and installing urlrewrite the problem was getting tapestry to generate within links the old urls. Tapestry for very noble reasons manages all url creation which is a good thing in most cases but not for mine. I understand that Tapestry 3.1 will bring in more support of ‘friendly urls’ but that is currently in Alpha.
I took a look at Spring after my adventure with Tapestry but found the documentation to be lacking and so abandoned that fairly quickly - I also wasn’t liking the monolithic configuration file it seems to favour. So in the interests of timeliness I converted the tapestry site to Struts (you gotta love the ASF). I did think about using JSF but had already spent two evenings farting around with Tapestry and Spring and wanted to get something up and running ASAP.
So to conclude (about time it has take almost as long to write this blog as it did to write the site) these are the technologies in use (roughly from the bottom of the stack to the top):
- Fedora Core 3 - Linux (2.6 Kernel)
- PostgreSQL 7 database
- Sun’s J2SE 5
- Tomcat
- Apache Commons DBCP connection pool
- Hibernate O/R persistance and query layer
- Struts
- UrlRewrite
Oh and I also managed to use CSS for all positioning which was sweet.