Another Anecdote Supporting the Thick Database Approach

This post describes how our thick database approach helped us to easily identify performance issues within a new application.

Dulcian’s BRIM-Objects includes  an object modeling tool  based on UML class diagrams. We built this tool over 10 years ago using BC4J (which evolved into ADF-BC). It takes about a minute to load the SWING application and another minute to load a big diagram (300 classes, 3000 attributes). Since this was in line with what we had seen in other tools, we never gave its performance much thought.

When we heard about HTML5, we decided to rewrite the tool as a web application. The Formspider IDE is already a web application, so we assumed that this would be possible. We performed some tests and found that we could create a full UML class diagrammer as a web tool.

After a few months, we had it all working. Then we tried to load the same big diagram, and it took about 40 seconds.  The UI tests of hundreds of components were all sub-second, so something smelled fishy.

The new architecture is 100% thick database.  This means that all of the calculations are done in the database and then an XML representation of the whole screen is sent to the browser, which then parses and renders it on the client. There is exactly one round trip from the client to the application server to the database and back again.

We asked the obvious timing questions: “How much time is spent in the database? How much time is spent in the client?”  The results were as follows:

• Time spent in the database: 38 seconds
• Time spent in the client: 2 seconds …. HMMMMMMMM

In the next hour, we placed simple tracing on the database side and found our bad query.  We rewrote it and got somewhat better results:

• Time spent in the database: 2 seconds
• Time spent in the client: 2 seconds …. Much better!!!

If we had made the same change in the old 3-tier architecture, would we have realized the same improvement? The answer is yes, mostly. Would it have been as easy to figure out?  Not quite, but still pretty easy.

So why didn’t we ever ask the question and do the analysis in the old architecture? The reason was that there were so many moving parts in the application server (using ADF/BC) that it was not at all obvious that there was a problem or where the problem might be. We knew that there were performance issues with all of the round trips between the application server, database, SWING components, and the hundreds of queries in the database needed to load the diagram, so we just suffered in silence every time someone loaded a big diagram.

There are a number of lessons learned here:

1. The “thick database” approach is again demonstrated as “cool.”
2. System architectures that do not provide dead simple ways of figuring out where your performance issues are are “not cool.”
3. Performance is never measured never gets improved.
4. Fewer moving parts in an architecture make everything better.