Customer Reviews

Server-Side Programming Techniques (Java(TM) Performance and Scalability, Volume 1)

5 star:		(6)
4 star:		(6)
3 star:		(2)
2 star:		(3)
1 star:		(2)

 

 

I was very skeptical when I picked up this book, because most authors on Java performance don't seem to have actually tested their theories. Dov Bulka, however, has included charts demonstrating actual performance gains. He's also shown how some kinds of purported optimizations _don't_ have a measurable effect, which is an excellent way of knowing what to avoid.

The author never compromises software engineering or program correctness in the pursuit of performance. His suggestions are practical and applicable to a wide variety of programs. The book is also well-written, clear, and a joy to read.

As the subtitle says, it's primarily about server-side processing. It's not going to tell you how to scroll tables faster, nor is it going to tell you to use a quicksort instead of a bubble sort. Still, every Java programmer should know how this author goes about working with Java performance, because it's a great framework for making improvements.

The book claims to be volume 1. I'm really looking forward to volume 2.

Books on how to write code in Java are ten-a-penny now. Until a new version of java comes out, we don't really need anymore. What we do need though, are more books like this.

If anyone using Java across a network, using either servlets or EJBs, there is a dearth of information. There are a couple of excellent goods on how to get going but little opportunity to broaden the scope once the basics of these technologies have been covered.

This book is a very welcome addition to the Java Server-side bibliography. The information on optimisation and increasing efficiency of communication contains a lot I haven't come across elsewhere.

For anyone who already has a copy of (for example) 'Inside Servlets' or 'Mastering EJBs', this is an extremely useful volume for consolidating the skills gained from them.

Java has an often justified reputation for being slow but often it is the result of its not being applied in the best way. The demonstrations of how to optimise code (and to quantify those benefits) make this book an invaluble weapon for advanced and serious developers.

It's only worth spending an hour or so browsing.

Most tricks are well known to experienced Java developers, such as using StringBuffer instead of String. And the book is too rambling. You can easily cut the pages in half. Often chunks of code is repeated with just a method name change, e.g. from println() to print().

Although it's claimed to be "Server-Side", it's really weak in that area. Sections on RMI and serialization are trivial and not to the point. The chapter on Servlet is not convincing.

Since Java is now a widely used server side programming language, especially for web-based development, I thought this book would discuss strategies and patterns used for writing scalable Java based servers. However, most of the book talks about tricks on how to speed up simple routines for gains in milliseconds. It has no particular applicability to server side development. The author went as far as rewriting standard Java utility libraries for performance gain. I like the Java programming language because it is simple (rapid development) and easy to read (communication). If performance is that important, where I had to rewrite standard libraries, I would use C++ for the job instead. This book spends only a few pages on true server side development relevant topics such as connection pooling and n-tier development. Also, there is nothing on J2EE stuff which includes critical tools and framework for Java server side development (EJB, JMS, ...). Overall, this book really does not have much to do with server side development. I suggest you to save your money. I am returning my copy.

This is one of those books that reiterates what a good programmer allready knows. If you are looking for easy reading and reinforcement on ways to code for performance than pick it up. It is NOT a waste of money.

This book covers the basics of improving the performance of server side java programs by writing different java statements. I like the fact that it had just the answers, not excessive amounts of padding. I especially liked the chapter on taking an existing, well written java program that was a web server, and optimising it in several stages. The stages were consistent with the optimisations discussed in the preceding chapters which helped put it those chapters into context nicely. The optimisations turned a good web server written in Java into a much faster one, which was good to see.

I describe this as a "basic" book on optimisation because the chapter on RMI was rather light, presumably because of the 80:20 rule wereby the biggest gains can be had with the simplest of coding changes. Going into more detail would have made the book thicker so perhaps it was best it was left as it was. There is perhaps an opportunity for someone to write an "advanced" version at some later stage.

I'd recommend this book to someone who is an experienced java programmer who wants to make their java programs run quicker. I certainly found it useful in my own java programs.

I'm glad to see a book that focuses exclusively on Java(TM) performance, and I am especially pleased to see a book that quantifies the test results. I doubt that anyone will be able to employ every optimization that the author presents, but there should indeed be something for everyone in this book.

What really sold me on this book was the case study. It's good to know that applying these techniques to real code can have the desired effect.

It would really be great if the author would make some of the test code available, so that we could verify the performance features of the new generation of VMs, like Hotspot and JRockit. Until then, his advice to write good code, then profile it to find the 20% that needs to be refactored seems be be pretty sensible.

Amidst all the hype and hoopla surrounding Java these last few years, there has been one constant criticism that has always been raised, namely performance. No matter how cool and cutting edge the technology, at some point the code must execute correctly and at an acceptable rate of speed. These problems are to many the last acceptable reason for not adopting the language for their development projects. As the author so effectively points out, some basic knowledge of what is going on behind the scenes can make an enormous difference in the speed of execution. Sometimes, simple changes can double the speed of the program and there are many such examples of improvements even better than that in the book. What I really liked were the simple bar charts clearly describing the performance consequences of the changes.
The trend in the development of programming languages over the last several years has been to optimize the speed of code development by encapsulating complex computations inside simple method calls. While this is certainly sensible, at times the gain in programmer productivity is at the expense of program efficiency. In pointing this out and suggesting remedies, the author demonstrates his good sense, although I do have some slight disagreements with some of the positions. No one can possibly disagree with the 80/20 rule where 20 percent of the code is executed 80 percent of the time so that you should concentrate optimization efforts on that section of the code. However, his contention that the remainder should be ignored should have been qualified. There is a substantial range in the amount of time the various sections of the remaining 80 percent of the code are executed. Given this, as well as the fact that some optimizations yield a factor of 10 or more increase in speed, it is very possible for the optimization of some of those sections to be cost effective.
The other point is that optimizing should wait until the code is created and proven inefficient before it is done. This is certainly reasonable, as increases in efficiency are often bought at the expense of code generalization. My slight point of difference is that the methods of optimization should be learned and considered throughout the development cycle. For once an inefficient system is built, it can prove very difficult to make the required optimizations. That point is most clearly demonstrated in the presented example of the simple optimization of having a web server compute a new date periodically. This date is then used until the designated time unit expires rather than compute a new one for every request. A common problem with web sites is that improperly constructed ones do not scale well, which has led to many well-publicized failures. If optimizations like this are understood and incorporated into the basic design, then the performance under unanticipated stresses could remain tolerable.
I have long had a reputation as an optimizing fanatic, sometimes obsessing out those last few CPU cycles. That alone would make me like this book. However, the examples are so solid in their demonstration of what is going on "underneath the hood" of the Java compiler that I am in the process of extracting and modifying them to create exercises for my Java classes. Sometimes, circumstances require that we lower the level of our view of the code to what is underneath the wrappers. When you feel the need for speed, reach for this book.

It actually contains less content than you would think as it's full of redundant source code listings and "chart junk" charts that take half a page to display two numbers. This is a programming techniques book, not a design or architecture book, don't look for discussions of patterns here. On the other hand, I bought and read the book and wasn't disappointed. The material covered is interesting and Dov does have the figures to back up the recommendations. Also, the results are sometimes surprising. Overall worth reading, if only to make you think more carefully before you choose a Vector over and array, or when you're deciding whether you'd like a Hashtable or a HashMap.

Outdated, so pretty big percentage of tips in the book are not really true currently.