We’ve just published Gibraltar 2.5.1, a cleanup release that includes fixes to issues that have been reported since the introduction of Gibraltar 2.5 and a few key enhancements. While the issues discovered were minor in the big picture, they each were significant to some of our customers and we wanted to get fixes into their hands while we continue developing Gibraltar 3.0. For a complete rundown of the defect fixes see the release notes.
There are three functional changes to Gibraltar which is why this earned the 2.5.1 label instead of just being a new build of 2.5.0:
- Automatic Send Sessions on Exit: Now if you have Hub integration set to automatically send sessions it will automatically also enable SendSessionsOnExit to ensure the session is sent as soon as the process ends.
- Metric Data is exposed to Add Ins: You can now access all of the metric data recorded in a session both in raw form and through the same basic analysis capabilities used by Analyst. This feature wasn’t quite ready for 2.5 but we didn’t need to hold it for 3.0.
- User Opt In Control: WinForms and WPF applications can take advantage of our built-in user opt in management to ensure only users that have explicitly elected into your CEIP.
Additionally, we’ve included integration with NLog 2.0 which, while still in beta, has picked up a lot of interest. We’ve validated this already with customers through support tickets but wanted to get it in the box as quickly as possible.
Automatically Send Sessions on Exit
Previously the Agent had two separate features that really didn’t work together – automatically sending sessions in the background to the Hub and sending sessions on exit. While it made perfect sense to us internally that they were independent (and were introduced at very different times) we could tell from the questions and support tickets we got that didn’t work for anyone else.
Most customers that use the auto send sessions feature with Hub were manually setting Send Sessions on Exit through code. This still wasn’t optimal because sending sessions this way prevented them from being pruned immediately upon confirmation (since that feature was integrated exclusively with auto sending). Additionally, it ignored whether there was another active process sending sessions to the same hub that could have sent the session more efficiently.
With this release we’ve integrated the two features together so if you enable automatic transmission of sessions to Hub it will implicitly perform a send session on exit if there is no other active agent sending sessions to the hub. Unlike when you explicitly request to send sessions on exit this method won’t use email and won’t log anything if it can’t (typically because the Gibraltar.Packager utility wasn’t distributed with your application). In the end, this will help hub integration just work for you.
This new capability doesn’t interfere with any other use of Send Sessions On Exit, so you don’t need to remove any code that you may have that sets that explicitly; it’s just redundant.
Metric Data Add Ins
We had originally intended this to be part of 2.5.0 but it was deferred because we weren’t happy with the API. With this new capability you can access all of the raw data for performance counters, sampled metrics, and event metrics that are recorded in your application. You can also access some of the built-in analysis capabilities used to create metric charts and grids.
We know that most customers are just starting to consider what they would do with the Add In API and hadn’t gotten deep enough into it to think through doing their own custom metric analysis but a few have come up with some very interesting use cases. Our goal always was to make sure you could export every inch of your data out of Gibraltar into another system for whatever purpose you have in mind – and we wanted to make good on that goal as soon as possible.
One customer with access to a beta wrote an add in that automatically analyzed stored procedure performance within their web application to identify queries that were either slower than the goal or had a significant change in performance. This helped them keep their database developers focused on the highest value optimizations without relying on customers telling them things were slow.
Another customer wrote an add in to track the usage trends of individual web site users to recognize how many distinct users they had each day and how long they worked with the application. They then created reports identifying people who’s habits changed so these could be looked into proactively before a dissatisfied customer became a former customer.
User Opt In
In many cases it’s a great idea to have end users explicitly opt in to your Customer Experience Improvement Program (CEIP). This ensures that they know their information is being sent, what you are going to do with it, and are comfortable with the process. You can see an example of this in Gibraltar itself – the same facility is used to allow you to opt in or out of our CEIP.
We’ve exposed the facility we’ve been using all year in Gibraltar so you can use it in your application. It supports prompting users only a limited number of times when your application starts up to make a decision and ensuring that whatever decision they make (or change) it’s respected promptly. It’s fully integrated with the automatic session transmission feature so it just works.
Other Minor Changes
Hub Performance and Scalability
The primary design goal of Hub was to not cause a problem when used over slow network connections. Unfortunately, the design did this at the expense of speed & efficiency when used over a fast connection. The previous release was limited to about 3Mbps on most hardware which meant transfer times for large sessions inside data centers were excessive. With this release we’ve radically reduced the overhead of these fast transfers without sacrificing recoverability or low bandwidth safety, allowing you to run up to essentially wirespeed.
We also identified a weakness in how the hub server and background processing service interacted that caused problems when the background service was busy analyzing a large number of sessions and addressed it. The good news is that we run our hosted hub service at a scale much larger than most of our customers so we tend to see limitations first and are able to analyze them deeply to make sure we find the right fixes. We also partner with our highest volume customers to ensure we find other issues that don’t happen in our environment.
You’ll find that this release uses significantly less memory for analyzing sessions and can process large numbers of sessions as well as large sessions much faster. It also uses less disk space, particularly for larger repositories due to a change in how we manage cached files.
We’ve made a change to the licensing system to be less insistent on activation when version numbers change. For example, if you’ve already installed a release of Gibraltar and have active maintenance you won’t be prompted to reactivate when installing this release. We recognize that activation ranges from a mild annoyance to a serious inconvenience and wanted to find a better way.
The next planned release is Gibraltar 3.0 which we expect to ship during the first quarter of 2011. There are a number of big items on tap for this release, justifying its major number change. If you’re a Gibraltar customer, contact us through support and we’ll be glad to discuss the roadmap with you and get your input to make sure we keep delivering the best value going.