« September 2004 | Main | November 2004 »
October 27, 2004
AMD64 Redux: Sun 40Z on fire!
A few months ago I blogged about AMD64/Linux 64 bit|JDK1.5 beta 64 bit.
The project I am on has purchased four servers. The servers are Sun 40Zs 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.
Extreme Performance
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 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.
JBenchmark
So how do you reliably record performance of 4,500 pages per seconds? Not with JMeter, which will fall over after 100. With jbenchmakr, a performance tool we rolled on our project, and one which is still a little raw, but which can reliably measure extreme performance.
ehcache
So how do you do 4,500 JSPs per second? Well, with ehcache, a high performance Java cache. I will be adding the JSP page filters to the project shortly, which use the BlockingCache constructs already there.
Posted by gluck at 03:32 AM | Comments (0)
October 23, 2004
Adventures in CheckStyle
I blogged recently about the new features in checkstyle 3.4 and their application to an open source project of mine, ehcache.
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.
DeclarationOrder
The DeclarationOrder check has proven to be quite troublesome. Not surprisingly most of our classes were loosely in conformance with the Sun standard for Java source file organisation. The idea here is that it supports code standards and collective code ownership.
Jalopy
I tried out some tools for automating the rearrangement. First I tried jalopy. There is an IntelliJ plugin which seems to work fine. I then tried the ant plugin to convert the entire code base. With jalopy you can export a configuration and get the ant plugin to apply it. Try as I might I could not get it to do rearrangement. Jalopy has gone commercial now. The last open source version is 1 beta 10. The commercial version is 1.3. It looks like bugs are not being fixed in the open source version, which is a pity.
Jacobe
I then tried jacobe which supports a long list of formatting options. Unfortunately one of those is not declaration order.
Rearranger
Finally I tried another IntelliJ plugin - Rearranger. This tool mainly does what it says: rearranges files in accordance with your declaration order. You can load a default and then tweak it from there. Overall this tool worked very well. I opened each file needing rearrangement and then rearranged each one. I then tweaked the rules until I got it to agree with CheckStyle.
A few words of warning though. Firstly on one file Rearranger inexplicably deleted two methods. This was repeatable. Bring the original back, hit Rearranger and it would delete the methods again. A more serious problem was with some scrappy typesafe enum classes we had. In these and a few other classes we had constants which were public and some which were private with the public ones initialising from the private ones. According to CheckStyle the public ones should be declared first. Due to the Java restriction on forward references during initialization this was not possible without a compile time error. There was also a case where the rearrangement on one innocent looking class caused a ClassNotDefError in our EJB tier which eluded all debugger based efforts to locate it. I finally found it by rolling all the changes back and forth in a binary search. I am still not clear what the problem was,
Automating Code Beatification on Commit
We discussed whether to discard the checkstyle rules and allow a beautifier to do its work at CVS commit time. The problems I had with the initial rearrangement cost me almost a day. Far better to require the code to be in order, then get CheckStyle to check it then run all the tests.
Empty JavaDoc
CheckStyle has a JavaDocStyle check which can include a checkEmptyJavadoc property.
The empty check finds empty lines e.g.
/** * This is
* a JavaDoc comment with an empty line in the middle of it.
*/
This is not that useful. It does not find:
/** */
or multiline empty JavaDoc.
In addition it would be useful to find comments with say less than 5 characters in them. These comments are as good as empty.
I have written such a check called EmptyJavaDoc. I will submit it as a patch to CheckStyle.
Posted by gluck at 04:40 AM | Comments (0)
October 12, 2004
ehcache 1.0 released
ehcache 1.0 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.
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.
Posted by gluck at 09:52 PM | Comments (0)
October 09, 2004
Fatland
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 
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.
Accompanying this was a change to eat more meals out and do less exercise. Physical education had become curtailed in many schools. School districts were entering into lucrative 'pouring contracts' with softdrink manufacturers. Conditions often included unrestricted sales through the day and in-school advertising.
The health result of all this is still unfolding. About 25% of Americans are now obese, meaning they have a Body Mass Index ("BMI") of 30 or more. 60% are overweight, meaning a BMI of 26 or more. This in turn is associated with rapidly growing rates of diabetes, coronary artery disease, hypertension and stroke. This is leading to something of a windfall for drug companies who are seeing extra demand for drugs to treat these conditions. In time these diseases will drive up health costs and make insurance dearer. The US Surgeon General has warned that obesity is now a major threat to life in the US and may overtake smoking as a leading cause of preventative death. Australians and Britons tend to follow US trends. Lets hope we don't follow them on this one.
And what am I doing about this? Well I lost my appetite after reading Fatland. I am personally someone at risk of going this way. I have lost a few kilos in the last four weeks and now have a BMI of 27. Not obese but overweight. I also have two boys: one three and one almost two. A high correlation exists between children who are overweight in kindergarten and those overweight or obese in adults. So it is a family wide effort to all stay healthy. It makes it easier too to all me consistent.
And what is McDonalds doing now? In Australia this month they have started using Canola oil rather than beef tallow and Palm oil. And "low sugar" bread. I remember asking the manager of the Gladesville store what they cooked their fries in four years ago after reading in The Australian Newspaper that it was beef tallow, and being told it was vegetable oil. I think these changes are good. I was in the Milton store today to buy a coffee and saw that the supersize portioning is still in place. Fatland takes a rather cynical view that some of the pro health choices were only introduced to disarm the veto person.
Anyway I highly recommend this book.
Posted by gluck at 05:00 AM | Comments (0)
October 05, 2004
For want of a symbolic link...
There is an old saying called the nail rhyme 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.
Weblinks.sh
But we are even lazier. What if you could leave your build script to create jars, wars and ears and still get instant deployment.
Here's how:
- deploy the app as an ear.
- let the app server expand it
- delete each web resource (jsp, image, javascript file etc) and replace it with a symbolic link to your IDE's web source directory.
- 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 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 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.
Posted by gluck at 04:57 AM | Comments (2)