In the last post I wrote about ways to tackle bottlenecks and to increase the performance of an application. When dealing with a high traffic application servicing tons of concurrent users all requesting the same data, intelligent caching can boost the speed in which requests are processed. As a result, lots of load is taken away from the database.

Querying a database makes much sense when the data requested changes a lot. But imagine the database is backing a blog or news website where the data requested from the database is the same in hundreds or even thousands of cases. The most frequent query sent to the database in such an environment is probably for loading the article on page one, which - once published - probably won’t change a lot. This doesn’t hurt the Database if your private blog has 100 unique visitors per day, but if the frontpage of a popular news website is attacked by 100.000 unique visitors per hour then you are in trouble. You need to use caching in order to take away stress from your database server.

An excellent, widely used open source cache solution which is easy to use and yet powerful is OSCache (http://www.opensymphony.com/oscache/). Besides features like clustering, a servlet filter for caching entire JSP pages or persistent caching it comes with a JSP tag library that enables you to include caching into your jsp based web application so easily it hurts.

All you have to do is:
1)       Add the OSCache jar file to your classpath, put the tld file into the WEB-INF directory of the webapp and declare the OSCache taglib in your jsp page:

2)       mark portions of the jsp-page to be cached in your jsp page with cache tags:

In this example the cached portion of the page is stored under the key defined in the variable cacheKey, it supports multiple languages and expires after 1800 seconds. There are a few other attributes available for configuring the cache tag. More information can be found here http://www.opensymphony.com/oscache/wiki/JSP%20Tags.html

A cache with an invalidation timeout as seen in the above example is great for many situations, but sometimes you need full control on when a cache entry needs invalidating. OSCache offers an API to manage the cache in your Java code. This is an example of how to invalidate it in a Java web application:

Piece of cake!

Take care,

Alex

PS: OSCache is under the OpenSymphony Software License, Version 1.1 which is derived and fully compatible with the Apache Software License.

The performance of a dynamic web application can be quite unpredictable when you don’t know how many People are going to use it and of course how they are going to use it. You can predict some of the users’ behaviours and do your best to prepare your application to cope with the expected load. But sometime after the launch you suddenly find yourself in a situation where the performance of your application – or at least parts of it - is poor and the customer is unhappy. In cases like this typical reasons why you didn’t find the bottlenecks while developing are:

• more users than expected
• unpredicted behaviour of users
• the amount of data stored in the production database compared to the development database
• missing indexes on database tables
• slow queries that need optimizing besides adding indexes
• inefficient code
• insufficient resources on the servers

So before using the brute force approach by throwing more hardware at the problem, the most important task to accomplish first is to find the real bottleneck. Just like in war times good intelligence is your key to winning the battle. So gather information first.

• Find out which parts are slow and under which circumstances the performance is poor. Talking to actual users of the app is a good approach to do so.
• Monitor the servers using tools like munin. CPU and Memory usage can show you which part of the architecture is stressed. In some cases the webserver idles most of the time, while the database machine is under heavy load
• Check the Database for slow queries – most databases provide tools and statistics to determine the slowest queries. This will help you find out where indexes might be missing or which queries need optimizing
• When optimizing queries first look at the explain plan. It can point you to the problem directly.
• Check the DB for the most frequently executed queries – if a query is executed very often this might be a place where the application code needs optimizing or where caching might help. Add caching wherever the same piece of infrequently changing data is shown to many users many times. A great roundup on open source Java cache implementations can be found here.
• Use a profiler to find out where in your code the application gets stuck. Chances are high that you end up locating the place where one of the slow queries is executed

Then start optimizing the parts you expect the most performance boost from. Be careful though when adding indexes on database tables with huge amounts of data – check if there is sufficient disk/table space available on the RDBMS. Indexes can also have effects on the performance of write operations.

If all this brain doesn’t solve the problem you might need to add muscle to your hardware:

• Scale vertically by adding RAM and increasing CPU
• Scale horizontally by adding machines, which is a lot easier for web servers as it is for database servers
• An excellent piece of literature on this topic is “Scalable Internet Architectures” by Theo Schlossnagle

Take care…

Alex

Whether you’re part of an agile team using methods like XP or Scrum, or processing your projects in a more classic way with RUP or even waterfall, in most cases you’re part of a team of developers. Chances that someday you’ll have to work with or (worse) debug code someone else has written are 100%. And who of us hasn’t complained about having to deal with “the mess” someone else has made. And probably some of our co-workers have been scratching their heads with both hands looking at some piece of code we’ve written after midnight with a numb mind in shipping hell. Nobody’s perfect.

So what can we do about this situation? Whining, complaining and pointing fingers won’t make the code any better.

Just recently I read “Clean Code” by Robert C. Martin. Zillions of blog entries were recommending this book, so I had to get it myself. I was probably one the last people on earth who hadn’t read it. It’s a great piece of programming literature. Reading it I found myself nodding my head a lot, agreeing with many of the points made and regretted I hadn’t read it earlier. There are some aspects I do not agree with 100% but they were very few.

One thing that impressed me a lot because of its simpleness is the “boy scout rule”: “Leave the campground cleaner than you found it”. When working with a piece of code, make your changes and commit it a little cleaner to your version control system. Let me give you an example.

I was debugging a class for creating financial charts. The following piece of code was scattered in it with slight variations about 20 times.

The reason I was debugging the class was that the font sizes within the charts did not look right when run on the production environment. Simple change made: remove the hard coded String and the numeric font size, and replace them with constants.

No big deal, but improving the readability and maintainability of the code a little bit. Imagine a whole team following this simple principle. More productivity, less rotten code, better team spirit. And the best thing about it: it’s absolutely free!

Happy coding!
Alex