The performance enhancements encompass changes to both the Dodeca server and the Dodeca client. The server changes include a major refactoring of both the Dodeca and the Dodeca-Essbase server components. The changes to both servers include:
- Implementation of a new, object-oriented framework that makes it easier for us to add new functionality in the future. It also makes it easier for customers and partners to extend the server functionalities of Dodeca.
- Significantly improved performance reading and writing the xml used to communicate with the client. In fact, in the case of large documents, xml read/write performance has been improved by more than 2000%.
- A new logging infrastructure that allows customers to better understand the internal operations of the servers. Each server has both a timed log and an untimed log. The timed log allows customers to see internal timings in the server which can be very useful for performance tuning.
The client also has some impressive performance enhancements. These enhancements include:
- Significantly improved performance reading and writing the xml used to communicate with the Dodeca-Essbase service.
- The new Accelerator that can improve the overall performance of our .NET client by up to 400%.
- We have also added some new functionality that we think users will love. For example, Dodeca now features:
- Multi-level Essbase undo/redo.
- An Essbase Unknown Members explorer
- Customizable Excel AutoCalculate to display sums, averages, etc of a selected range in the status bar.
- New options for inserting/deleting rows, columns and worksheets.
- Over 10 new workbook script methods and functions. The new functions and methods enable Dodeca workbook scripts to call a custom web service, to execute custom code on the Dodeca-Essbase server, to get the dimension name represented at a given member cell and to obtain a GUID from the operating system, among other features.
I also was doing some stress testing a few months ago and did a large zoom-in operation. Here is a screenshot of the spreadsheet after the zoom.
This retrieve, where the grid size was 803,530 rows by 9 columns, processed through our server in just over 42 seconds. How do I know that? I could see it in the Dodeca logs:
The items circled in the log indicate the grid size before the zoom-in, the grid size after the zoom-in and the milliseconds to complete the entire transaction. Since this screenshot was taken, we have done further work on the logs to separate items that have sizes/times associated with them and things that don’t have associated times. Further, the default formatting for the timed logs use pipe-delimiters between the fields so the log can be imported directly into a relational database, or even into Excel, for further analysis.
I have covered a bunch of things in this blog entry but there are a bunch of new things in Dodeca 6. When we began work on the servers, I put in many, many 80+ hour weeks researching and working on conceptual designs for the server. I was telling someone recently about my experiences during that time. Basically, I didn’t shower for days at a time and my hair gets greasy after 1 day, so I wore a toque (or stocking hat). I wore one of my many hooded sweatshirts, kept my headsets on and was generally anti-social. My family barely got a word in and most of my friends at Starbucks didn’t even recognize me. The person to whom I was telling this was another programmer and familiar with the concept. He said to me, “So, you went into Unabomber mode!” I guess you could call it that. For everyone who reads my blog on a regular basis, perhaps you can see why my posts have become a bit scarce over the last year.
In summary, this post talks about a few of the key aspects of Dodeca 6. I will delve into some of these topics deeper as time goes by, but for now, I will leave this post with a bit of a puzzler for you. Below is a screenshot of one of the new samples created using the out-of-the-box functionality of Dodeca 6. This sample view features write-back to Essbase, but it breaks the rules of Essbase a bit. Tell me, what are at least 3 of the normal Essbase rules we broke and how did we do it? I will send a free Dodeca T-Shirt to the first 5 correct answers posted in the comments below.
Note that I have to approve the comments before they show up in the comments, so I will know who the first 5 people are. For those of you who have already seen this demonstrated, you are ineligible to win but, then again, you probably already have a bunch of Dodeca T-Shirts. Winners need to send me email once you have been identified as a winner and include your name/address/size so I can mail the shirt. Also, if you want to win a shirt, use your real name when you post the comment as I don’t want to try to manage sorting out who the real ‘anonymous’ is.
So, how did we make this work?
1 comment:
Sam Toteve -
1- Row 6 is normally impossible in Essbase 'normal' functionality. Maybe hid some rows etc to get it to work.
2- Storing Cell Text at intersection that doesn't include all dims? No idea how you do this, but assume some type of backend SQL table.
3- Multiple Attribute selections?
No idea how you do this....
Sam
Post a Comment