Jayson Falkner's Blog

Performance Archives

Blarg #7: How long does it takes to compress a response using a GZIP filter?

                 System.out.println("GZIP supported, compressing.");
                 long ini = System.currentTimeMillis();
                 GZIPResponseWrapper wrappedResponse = new
 GZIPResponseWrapper(response);
                 chain.doFilter(req, wrappedResponse);
                 wrappedResponse.finishResponse();
                 System.out.println("Compressed in " +
 (System.currentTimeMillis()-ini) + " ms");

Hi Ronald,

Awesome. I'm glad you found my book, and I hope you enjoy it.

The trick here is to split the request and compression in to two separate things. Buffer the response, then compress the buffer and time only the compression. You can more or less do this easily by editing the code in the com.jspbook.GZIPResponseStream class, e.g. here is the existing code in the close() method of GZIPResponseStream.

ByteArrayOutputStream baos = (ByteArrayOutputStream)bufferedOutput;
// prepare a gzip stream
ByteArrayOutputStream compressedContent = new ByteArrayOutputStream();
GZIPOutputStream gzipstream = new GZIPOutputStream(compressedContent);
byte[] bytes = baos.toByteArray();
gzipstream.write(bytes);
gzipstream.finish();
// get the compressed content
byte[] compressedBytes = compressedContent.toByteArray();

You can see the response gets put in to a byte array, then the byte array is compressed and the results are saved to another byte array. You could put a time check in as follows (very similar to what you were doing).

ByteArrayOutputStream baos = (ByteArrayOutputStream)bufferedOutput;
// prepare a gzip stream
ByteArrayOutputStream compressedContent = new ByteArrayOutputStream();
long ini = System.currentTimeMillis(); // <------- starting timing here
GZIPOutputStream gzipstream = new GZIPOutputStream(compressedContent);
byte[] bytes = baos.toByteArray();
gzipstream.write(bytes);
gzipstream.finish();
// get the compressed content
byte[] compressedBytes = compressedContent.toByteArray();
System.out.println("Compressed in " + (System.currentTimeMillis()-ini) +
" ms"); // <-------------- stop timing here

And the result is you are only counting how long the compression took. Although fair warning needs to be given. The current GZIPResponseStream class tries to buffer content, as shown above (it allows you to set the content-length header properly), but when compressing really big files the filter streams content back to the client as not to use up all of your web application's memory. The above timing example won't work if you are testing it on files larger than the buffer -- the default buffer is 50k, you may need to increase it for your benchmark.

In general, the resources it takes to compress content aren't an issue. However, if you find that compression takes up too much processing power, remember you can combine compression with caching to try and reduce the overhead.

Cheers, Jayson Falkner jayson@jspinsider.com

A few links

• The Book
• The source-code to the example compression filter.
• A tutorial on why the above source-code is helpful, how you can use it, and how you should use it.

Blarg #5: Are you aware that the source-code for www.jspbook.com isn't available?

Hi Jayson,
Are you aware that the source-code for www.jspbook.com isn't available on-line? How can I get a copy?

I get asked the above question almost daily, and people are fairly asking it. The short answer is http://www.jspbook.com/jspbook_site.war. And if www.jspbook.com is replaced with www.jspinsider.com, the answer is http://www.jspinsider.com/showsource.jsp.

The reason I posted this on java.net is because I think it will help others find the code without needing the middle man (me), and I realized maybe other JSP/Servlet developers would like something in addition to the source-code.

Let me explain. As a JSP/Servlet developer all of the code I write I try to make freely available for others to use as they wish. The goal is to promote the use of helpful Servlet/JSP/Java code. I think it is silly to expect others to learn when all they have is the API documentation. I wrote a book with this in mind, and one of the book's examples is building a real website (http://www.jspbook.com), which also funtions as the book support site. Although sadly, roughly a person a day can't figure out where the link is to the source-code for the site, and that I assume is the reason for all the e-mail I get with the above two lines. Hopefull this post will help reduce the average to at least a person per week.

About the other bit. I recently realized that putting source-code on-line by itself isn't overly helpful to people who don't buy the book that goes with it. I've decided to try and write up some nice, free on-line guides to why the source-code I provide is helpful. The idea is that I can demonstrate some code, say a compression filter, give you the source-code, and leave you feeling good because you've got something cool that you can hack away at as you please. Give me some ideas; what would you like?

Please direct suggestions to the feedback for this blarg, and I'll take the most popular ideas and make something of them in the weeks to come.

Blarg #4: Good Web Application Cache and Compression Support

Here is a write up I did about probably the best solution to providing cache and compression support for your web application. If you don't know what a cache or compression filter is, read this article, now. If you do, it is still worth taking a look. Several questions have been asked and answered about the practical use of these filters and how they compare to alternative choices that offer the same functionality.

In short, I'm arguing that this is something every Java web app developer should use, and I'm showing exactly how in general it should be done. Don't you think that is worth a quick look? Not to mention free, open-source code compliments the O'Reilly quality article.

Cheers,

Jayson Falkner - jayson@jspinsider.com

Blarg #1: Are JSP Still Relevant?

Blarg #1: Why are JSPs still relevant?

You seem like the perfect guy to ask.

So; if they are, then why are JSPs still relevant?

Great question zander, and it is one I just so happen to have a lot to say about. You would be surprised how often this type of question seems to pop up, not just about JSP, but about just about any J-starting acronym the marketing folks throw to the masses. In some cases it is valid to ask, say the technology in question really is dated...or it was just pretty worthless in general. However, in the case of JSP, there are several great reasons it is still relevant. I'll address a few of the particular reasons I think are most important, and I'll try to phrase things assuming you don't know much about JSP. I don't mean to be condescending, but far too often this type of question is asked simply because the person doesn't really understand what the J-starting acronym really describes. If you aren't that type of developer, then please bear with me, I'm assuming there are plenty of other developers who will certainly appreciate an answer that doesn't assume much.

My reasons for why JSP is still relevant.

1. JSP is a key part of the J2EE Web Tier
2. JSP is The standard
3. It is easy to use JSP in amazing ways

JSP is a key part of the J2EE Web Tier

J2EE is huge, and almost all of it is good for at least one particular task. People do spend a lot of time (namely JSR expert group people) designing each and every J2EE related technology, which means in general something helpful is made. Note, this does not imply that your work will benefit from every J2EE technology, say JSP in particular. So let us be clear on what JSP is good at, and then you can decided if you are trying to do that, or if you could care less -- either way we should hopefully agree JSP is a technology worth keeping around.

So what is JSP good for? JSP is great for generating dynamic web pages, think any web page that uses markup, e.g. HTML, XHTML, WML, or even just plain text. When I say "dynamic" I mean something that changes. A good example would be an on-line store like Amazon.com that takes a little bit of information from you, say a title of a book, and automatically generates tons of HTML-based web pages that try to get you to purchase something. This is dynamic because Amazon.com certainly doesn't have billions of HTML files saved on their servers, it wouldn't be practical. Amazon.com only keeps around key information about books, and when needed uses JSP to generate HTML on the fly. A bad example of dynamic is something like my personal resume. It is nothing more than an HTML page I update maybe twice a year. It makes a lot of sense to simply code my resume by hand, using only HTML, and let people download it as is.

JSP is really the only good technology to do this in the standard set of Java/J2EE tools. Now that is an over-simplified statement, but it is true. There are several other technologies such as Servlets and JDBC that are almost always used with JSP to get the job done, but if you try to make dynamic web pages without JSP it takes a lot more time and effort.

In summary, I'm saying if you want to make dynamic HTML, XHTML, or text and send it over the World Wide Web, JSP is what you should use. That is why it is important. If you don't want to believe me I'll give a link at the end that does a proper job of arguing this point against the millions of common counter-points developers have. Now to move on....

JSP is The standard

A key thing to understand is that JSP is a standard. It has been around for good deal of time, lots of companies have dumped lots of money in to it, several other technologies are based on JSP, and there are tried and proved successful uses of the technology. In short, I'm saying any other Java technology that is trying to compete with JSP and isn't part of the standard J2EE API is more or less worthless. I don't care if you want to argue that something is more elegant, or that you can show me an open-source project that has a few top quality hacks working on it. None of that matters. JSP does get the job done, JSP can do a great job, and you can make a good living off of programming JSP/J2EE knowing Sun, IBM, Oracle, and a slew of other companies will keep the money flowing. Other projects like WebMacro/Velocity have lost. They are bitter, and they should be. Some really neat ideas and some great code might have been produced, but they certainly won't get much credit when the next version of JSP incorporates those features.

In summary, I'm saying JSP is relevant because it is a standard. As an average developer you should forget anything you hear from other non-standard Java technologies. Sad, but true, especially if you only care about making a living as a Java web programmer.

JSP is easy to use in amazing ways

JSP can be used well, and it can do amazing things. I've spent several years of my life figuring this out. I've tried the alternatives. I know about the other open-source projects. I've helped the JSP expert group. And I've spent a year of my life writing a book about this very topic. If you want to build a good web application that is fast, efficient, and easy to maintain, JSP can do it. If you don't believe me the best I can do is tell you to do some reading. Check out Sun's website, read java.net, read JSP Insider, or simply read my book. And you are right if you are thinking I'm just pushing what I like. I like JSP, but I say that because I've tried just about every other solution to building web applications. I've dealt with the poorly funded open-source solutions, the hyped commercial solutions, and even some home-brewed attempts to improve the state of things. But I think JSP is the best.

In summary, I'm saying that I honestly think JSP is a great technology, and I think I have the experience to fairly say so. Especially considering JSP 2.0, there are far too many helpful things that you can do easily with JSP. If you understand the technology, you will get the job done and you can certainly get the job done well.

And that is why JSP is still a relevant technology. I really wish I had the time to type out each and every bit of knowledge I have on the subject, in particular some of the really slick coding tricks that would completely solve your hard to maintain JSP problems, or reasons you shouldn't bother with stuff like WebMacro/Velocity, but I seriously just got done doing this in a JSP 2.0 and Servlet 2.4 book that went on sale a few days ago. Go buy it if you want an instant fix, or try to ask some specific questions on my points above if you want a slower, free-loader fix. I'll try to answer as many questions as I can as long as you keep sending them to me -- feel free to make them specific so I can try to show some code or talk about JSP 2.0 features.

Jayson Falkner - jayson@jspinsider.com

This work is licensed under a Creative Commons License.