Notes
Slide Show
Outline
1
FoxCon Toledo 2007

Instrumenting Your
VFP Application
  • Dave Bernard
  • The Intellection Group, Inc.
  • http://www.IntellectionGroup.com
  • DBernard@IntellectionGroup.com


  • http://www.intellectiongroup.com/Presentations.asp


2
Agenda
  • Context
  • “Houston, we have a problem.”
  • What is “instrumentation”?
  • Why do it?
  • What are the goals?
  • What’s the approach?
  • How do we use the results?
  • Our findings.
3
Context
  • Who am I?
  • Over 28 years as developer, manager, executive.
  • Developing in FoxPro since 1990.
  • Vice President, Atlanta FoxPro Users Group.
  • Co-founded The Intellection Group 3 years ago.


  • Mantras:
  • There are no technical problems, only business problems.
  • Try not to sell to IT people; sell to business owners.
4
Video
5
“Houston, we have a problem.”
  • “If debugging is the process of removing software bugs, then programming must be the process of putting them in.”


  • Generally speaking, most apps are deployed when they are "good enough.“ Your code is going to be running in production with bugs and performance problems, regardless of how well you develop, test, debug and deploy.


  • We've also been told to "make it right before making it faster.“ Reality has become "There's never time to do it right, but always time to do it over."


  • The poor software development project success rate in our industry     speaks for itself.


6
What does it mean to Instrument your Code?
7
What does it mean to Instrument your Code?
  • We programmers use the term to mean adding code that records data that helps us diagnose and keep track of how our code is behaving.


  • It's proactive!


  • Instrumentation code exists before problems occur so that live production behaviors are captured. Can be done during testing phase, but the goals are different.


  • It's not error logging! More like an audit trail.


  • It’s just like security cameras on your system!
8
"Without metrics, you're just another person with a different opinion."
  • We've all heard these:
    • "The program is too slow!"
    • "The system is losing information when I know I saved it!"
    • "But it works fine for me!"
    • "It's only bombing on Jim's machine."

  • Our company has additional special considerations that drive our approach:
    • COM+ development
    • Web development
    • Framework development
    • Small software shop

  • Because we work in a mixed (not pure) environment, where several systems are competing for the same resources, we have to look at larger datasets or data across time to get an accurate picture of performance trends.
9
Instrumentation Goals
  • Performance optimization
    • Optimize the slow parts using real world data
    • Extend the lifetime of our infrastructure by reducing the load on servers
    • Optimize bandwidth utilization
    • Real time alerts for exceeding performance thresholds
    • Refactoring


  • Improve the user experience


  • Reconstruct error behaviors without having to reproduce the problem
10
Instrumentation Goals
  • CYA (Cover Your Anterior)
    • Recording actual usage comes in very handy in resolving disputes between developer and customer
    • Can actually reconstruct lost data from the log
    • Are they actually using what they said they wanted?


  • Function utility logging and tracking
    • Helps optimize our development priorities


  • Improve framework reliability


  • Bottom line: application visibility


11
OK, so what’s the approach?
  • Traditional approaches:
    • Coverage Profiler and SQL Server Profiler: Too much information.
    • ASSERT: only flags errors.
    • Event Log: too much trouble and limiting.
    • Error Logging: only gives an information snapshot

  • Advantages of custom code instrumentation:
    • Complete control over what gets measured (and what doesn't).
    • You build it in as you develop; make it part of your primary development framework.

12
OK, so what’s the approach?
  • Watch out for over-instrumentation
    • You have to figure out what is likely to be needed.
    • Instrument what you would ASSERT.
    • Instrument all data access.
    • Instrument all function points.
    • Because applications that use tracing vary widely, there are no general guidelines for strategic placement of tracing.

  • Instrumentation is always active.


13
How do we use the results?
  • Demo
14
Our Findings
  • Minimal performance hit due to instrumentation.


  • You're not really looking for code problems, per se; you’re looking for performance and business rule problems related to unexpected user behavior or unexpected data input.


  • Runtime optimization revolves largely around data access performance.


  • In a web environment, page size and complexity are big optimization targets.


15
Thanks

  • This presentation is available at


  • http://www.IntellectionGroup.com/FoxCon2007Presentation.htm
  • http://www.intellectiongroup.com/Presentations.asp



  • DBernard@IntellectionGroup.com