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.

 

Tagged with: , ,
Posted in BLOG, Development
One comment on “Another Anecdote Supporting the Thick Database Approach
  1. I decided to add a bit more on how those 38 seconds turned into 2 (and more importantly – why ):

    http://wonderingmisha.blogspot.com/2013/03/explaining-miracle.html

    Overall, everything is very simple: views should not be used as “black boxes”!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Disclaimer
The information presented on this blog is presented to provide general technical information. If, while attempting to apply any of the ideas, procedures, or suggestions herein, you experience any kind of programming or system problems or failure, it will be as a result of your own actions. Dulcian, Inc. and all authors of text found anywhere on this site, and all internally-linked Web sites, Mail Lists, Blogs and/or e-mail group discussion, disclaim responsibility for any user's actions and any damage that may occur based on information found on this website and associated Mail Lists, Blogs and/or e-mail group discussion. Any technical advice or directions found on or through this site is provided AS IS and its provided without warranty or any guarantee of its accuracy. You perform any modifications to programs or software AT YOUR OWN RISK.