A few months ago I blogged about [AMD64/Linux 64 bit|JDK1.5 beta 64 bit](http://gregluck.com/blog/archives/2004/07/amd64_jdk150_an_1.html).
The project I am on has purchased four servers. The servers are Sun [40Z](http://www.sun.com/servers/entry/v40z/index.xml)s which consist of 4 AMD64 Opteron cpus. Fedora Core 2 64 bit and installs fine on them, as it should, because Redhat AS3 is supported and available pre-installed.
Running our application-specific benchmark, on the Sun 40Z we got 2700 JSP pages per second compared with 900 per second on the Quad Xeon 32 bit machines. That is 3 times the Xeon performance. On another benchmark we got 4,500 JSP pages per second!
Sun Microsystems Reborn
The client I am working at has been a loyal Compaq then HP user. However the Sun 40Z has recorded the some record [benchmarks](http://www.sun.com/servers/entry/v40z/benchmarks.html) which got the client interested. These benchmarks have been born out by our own application specific benchmark results.
I think Sun’s partnership with AMD is a great idea. The JDK 1.5.0 for AMD64 seems very fast and very stable. (We are running a week long stability stress test as I write). I think Ultra Sparc is washed up from a price-performance point of view. But AMD Opteron is 64 bit as well and rocks! I hope this leads to a rebirth of Sun.
I am also happy to finally be able to recommend some Sun hardware on price-performance alone.
So how do you reliably record performance of 4,500 pages per seconds? Not with JMeter, which will fall over after 100. With [jbenchmakr](jbenchmark.sf.net), a performance tool we rolled on our project, and one which is still a little raw, but which can reliably measure extreme performance.
So how do you do 4,500 JSPs per second? Well, with [ehcache](http://ehcache.sf.net), a high performance Java cache. I will be adding the JSP page filters to the project shortly, which use the BlockingCache constructs already there.
I [blogged](http://gregluck.com/blog/archives/2004/09/checkstyle_34.html) recently about the new features in [checkstyle 3.4](http://checkstyle.sourceforge.net/) and their application to an open source project of mine, [ehcache](ehcache.sf.net).
Applying the changes to ehcache was relatively straightforward. This week I applied them to a large project that has been going for 18 months. So far it has taken me all week to do so. Interestingly the same 5-10 classes kept coming up as requiring suppression of a CheckStyle check. We always knew those classes smelt but now the smell is overpowering.
[ehcache 1.0](http://ehcache.sf.net) has been released. Ehcache is a small, fast and simple in-process Java cache, available under an open source license.
Ehcache is now one year old. In that time it has moved it has been incorporated into many projects and commercial software offerings including Hibernate, Spring, Apache Cocoon, Apache Turbine, Confluence and many others.
It has both memory and disk stores. They are are scalable to hundreds of caches and gigabytes of storage. It is fully documented and has high test coverage.
Ehcache deliberately emphasizes simplicity, safety and scalability over features. As such it is a departure from other efforts which seek to implement [JSR107](http://www.jcp.org/en/jsr/detail?id=107).
Caching is a great way to speed up applications. Ehcache comes with extensive documentation on how to apply it to common problems such as Hibernate, web pages and search engines.
Ehcache can be used in J2SE and J2EE. It works with JDK1.2 through to JDK5.
When I went to the US in June for the Agile Development Conference, I was paranoid about putting on weight. I avoided all fast food, ate only at restaurants and was careful to eat small. It seemed to work. On previous trips to the US I have always put on weight. Two years ago I put on a whopping 5 kilograms in one week! (Perhaps I was in denial about my pre-trip weight).
What is it about the US that has this effect. Well a great book to read to find out is [fatland](http://www.amazon.com/exec/obidos/ASIN/0618380604/qid=1097229530/sr=2-1/ref=pd_ka_2_1/103-5380067-8995008)
The book argues that the late 70s ushered in two very low cost sources of empty kilojoules: Palm Oil and High Fructose Corn Syrup (“HFCS”). Palm Oil was a new import from South East Asia. Palm Oil is a saturated fat similar chemically to beef lard. HFCS is made from corn and is 10 times sweeter than sugar. Fructose also follows a different chemical pathway to sucrose. Long term use causes increased fat formation, high blood triglycerides, decreased glucose tolerance and too much insulin the blood.
It then argues that the food companies sought a way to take advantage of these changes. Coke and Pepsi changed from 100% sugar to 50% sugar and then 100% HFCS in their cola drinks. Research showed that over 4, humans lose the ability to take into account calories taken in in liquid form, not compensating for them when they ate solids. Other research showed that human satiety was flexible: they would eat more when confronted with wide variety and also when given more. Because of the high cost of labour but the low cost of these new sugars and fats, it was found that more margin per customer could be made by selling them more at an incrementally lower price. Along came value meals and supersize options. The growth in supersizing can be illustrated by the serving size of McDonalds fries. In 1960 200 calories, 1970s 320, 1990s 450, late 1990s 540 to the present 610 calories.
There is an old saying called the [nail rhyme](http://www.enchantedlearning.com/Nailrhyme.html) that starts off “For Want of a nail…” and ends “… the kingdom was lost”.
I attended a conference on the weekend. There was a session denigrating Struts and promoting Webwork. I didn’t go to the session because I have used and intensely dislike both web frameworks. The reasons why can be the topic for another blog. This was much to the disappointment of the speakers who aimed a jibe at me before realising I was absent.
Later that evening over several beers the most zealous of the presenters found me and sought to convert me to the new truth.
I said that “we used JSP, JSTL and our own home-grown set of classes for our framework and that it seemed to work very well. We roundtrip with a designer. The pages are very fast to edit and test. No problems.”
“But” he said, “you have to build a jar and deploy to your server after each edit before you view or test”. That was when the penny dropped. It occurred to me much of the effort to find alternatives to JSP was to avoid this problem.
There are two ways of avoiding the build-jar-deploy-unpack problem:
* use an exploded directory structure
* use a small shell script called weblinks.sh
Exploded Directory Structure
In this approach you configure the app server to use a directory rather than ears, wars and jars. We use Orion application server, and I have used that approach in the past.
Both the IDE and the app server are pointing to the same place. You press save. Then if you run a test against the page or call the page, the app server notes the new timestamp, parses, compiles and executes it. Easy.
But we are even lazier. What if you could leave your build script to create jars, wars and ears and still get instant deployment.
1. deploy the app as an ear.
2. let the app server expand it
4. Edit your JSPs, press save amd voila! Instant deployment.
The technique works equally well for a Java IDE, Dreamweaver or any other HTML or text editor.
As with the previous technique, when a file is saved the app server sees a new timestamp. Instant deployment.
Attached is a Unix/Linux/MacOSX shell script called [weblinks.sh](http://gregluck.com/blog/weblinks.sh) which does this.
Now back to my missionary friend. He objected to the shell script on the basis that it was “changing the operating system”. The last time I checked, if you have a shell account you can write scripts.
“But I run Windows”, he said. Another penny dropped. Just in case any of my readers was in any doubt I have developing on Linux for the last six years, which I mix up with a bit of development on my Mac. Shell scripts are easy on both. On Windows, I guess if the IDE does not do it it is not possible.
Well, the last time I checked, it was possible to write batch scripts in the miserable DOS. If you are running on NTFS on W2K or higher, then you can create symbolic links. See [here](http://shell-shocked.org/article.php?id=284) for a discussion of the command line tools and options for doing so.
For want of a symbolic link
For want of a symbolic link
the JSP was lost.
For want of a JSP
designer roundtripping was lost.
For want of a designer
usability was lost.
For want of usability
the project was cancelled.
For want of a project
the developer was sacked.