In Part 1 of my mathematically inventive “1000% improvement” tale, I introduced you to some fundamental diagnostic techniques for evaluating the potential causes of slow CygNet Studio screen performance. Here in Part 2 of the continuing saga, we’ll dive into more details of the process by which we arrived at our Part 1 solution and introduce some useful tools for evaluating and understanding many CygNet message-based behaviors, not just this one example.
The Job Runner is a little tool that packs a big punch. It can tune up your slow-running HSS, free up the UI on your script-heavy Studio screens, and open up the world of .NET programming for you. It can even make smoothies*!
There’s a new request in town, and it goes by the name “Request New Device Data” (and boy, does it mean business!).
In ye olde tyme Gas Measurement Repository (GMR), there was only one way to get data from the field, and that was by using date-based requests. When using a date-based request, you essentially are asking the devices: “What data do you have from 3 days ago until today?” This approach works for some cases, but isn’t very robust in other scenarios, many which are unforeseeable. Administrators typically need to build safety nets to handle any communication down times so that there is no data left uncollected
Recently, I was asked to assist with a customer support call regarding a poorly performing CygNet Studio screen. Having just participated in Dan Snyder’s CygNet Database Service Diagnostics and Performance Tuning breakout session at this year’s WESC, I felt more than ready to take on this challenge. Surprisingly, the actual diagnostic and remediation process required was much more involved than I expected. My hope is that by describing, over the next several posts, the detailed process I went through to decrease the screen load time from 30 seconds to 3 seconds, you may come to understand the nuanced considerations required to craft and verify the most efficient solution for your particular needs.