Building FrameFlow Server Monitor: A Day in the Life
We do our best to keep our software lean and mean. Our business is 100% based on a try-before-you-buy model, so it’s important that we make a great first impression and part of that has to do with the ease of deployment and perception of quality. There are few things we hate more than when we go to download a simple utility to get a job done and it weighs over 500 megs in size.
Keeping our software fast, efficient and small isn’t always an easy thing. We’re sometimes at the mercy of third-party components that we integrate with and sometimes we have to deal with problems thrown our way by the development tools that we use.
Recently we faced a challenge along these lines and here is how it played out…
New Microsoft Development Tools
When we were about three quarters of the way of the through, we decided to switch to the latest version of software development tools from Microsoft. The transition went smoothly, that is until we made our first full non-debug build and loaded it up in our test environment.
In all previous FrameFlow releases we have used a feature called “dynamic linking.” Dynamic linking lets each of our components share a common set of Microsoft libraries instead of building them into each one. This technique significantly reduces the total size of any application that has multiple components and, with 70+ event monitors, the monitoring service and various utilities, we benefited from it a great deal. We quickly discovered that in production environments we could no longer do this without launching a separate Microsoft setup program during our own setup.
This is not a big deal on the surface, but there are three inherent problems. First, it would make the setup process a bit more complicated and prone to errors especially for new FrameFlow users. Second, we couldn’t see any reliable way to make it work for our remote node auto-update feature for FrameFlow Multi-Site Monitor. Third, the Microsoft setup itself was more than half the size of our own setup program.
A Different Approach… Bandwidth Implications
So we switched to what is called “static linking.” With this option all the required components are included in each module and there is no sharing between them. With baited breath, we waited for the production build to complete and checked the size of the setup. For previous releases the setup program weighed in at 19M and this one was 134M, in other words 7 times bigger.
These days 134M isn’t a whole lot, but we had to consider our multi-site users. Some of our customers are monitoring upwards of 500 separate sites and the thought of using up 67 gigs of bandwidth for each remote node to auto-update was not appealing, especially since some of them are connecting over VPN links that are already close to saturation.
It was back to the drawing board and, after a few more experiments, we found what turned out to be the best solution. We knew that static linking was the only option, but the problem was it bloated each of our 70+ event monitors. The solution was what we called: The Great Event Monitor Merge. Instead of building separate DLL files for each event monitor, we combined them all into a single DLL, providing what we hoped would be a big saving in size.
Mission Accomplished with One DLL File
We kicked off another build and a little while later out popped a production setup program that was just over 17M. That’s 10% smaller than it was in v7.0.8 and earlier. At this point we called it “mission accomplished,” and moved on to other work.
You can see evidence of this change v2015.2 and later. In previous versions there was a subfolder called “Event Monitors,” and it had 70 or so DLLs in it. That folder is gone now and it is replaced by a single DLL in the main folder called EventMonitors.dll.