In my last post I talked about why TOKEN-based polling is the new best way to get your EFM data into CygNet Measurement; it’s now time to start backing up that claim. Let’s start with a simple one…
How does CygNet Measurement help me to reduce the polling overhead of my devices?
The CygNet ODBC driver has recently been patched such that it returns the correct rows for a query that processes the results of a LEFT OUTER JOIN with a subsequent LEFT OUTER JOIN. Previous to this patch, such a query would not return the correct rows and either generate an unknown exception in the associated log file or cause the application to crash.
Well as a similar joke goes, first the tab strip has to want to change.
Tabs are commonly used in screen navigation. They do a good job of helping us organize our screens and they don’t require a lot of screen real estate. I used them extensively when building CygNet for Production. So much so that Applied Engineering built an entire management system to control the configuration of the tabs, but that’s a story for another day.
As Rick teased in his on-going series on screen performance enhancements, we are happy to announce the release of CygNet Message Sniffer Lite. This tool is designed to help the CygNet administrator understand exactly what messaging is happening between CygNet clients and services to help diagnose problems and improve performance
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
The DEID is connected to the UDC,
The UDC is connected to the Facility…
Remember that childhood song? Perhaps I took some liberties with the words but I think they also work in a truly geeky CygNet way.
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.
Search the CygNet Blog
Subscribe to the CygNet Blog
Enter your email address to subscribe to this blog and receive notifications of new posts by email.