Cary Millsap is the founder and president of Method R Corporation. He is widely known in the Oracle community as a speaker, educator, consultant, and writer. He wrote Optimizing Oracle Performance with Jeff Holt, and he is a co-author of Oracle Insights: Tales of the Oak Table. Cary is also an architect of the Method R software tools that help professionals around the world manage Oracle performance. He blogs at carymillsap.blogspot.com and tweets at twitter.com/CaryMillsap.

As a teacher, Cary has the rare ability to take complex topics and teach them in a manner that everyone can understand. He is innovative and entertaining, and he always challenges his audiences to think beyond the status quo. Cary's reputation as one of the world's foremost experts in Oracle performance diagnosis is richly deserved.

—Andrew Zitelli, Principal Software Engineer with Honors, Thales-Raytheon Systems

How Can Cary Millsap Help You?

You can bring Cary Millsap's passion and years of experience to your site, where he can help you in any of the following areas:

• Solving Oracle system performance problems.
• Implementing processes to prevent performance problems from occurring.
• Learning how the Oracle kernel performance instrumentation works, and how to use that instrumentation both for diagnosing and preventing performance problems.
• Learning the whys and hows of good software performance instrumentation that should occur during software development lifecycle.
• Implementing or learning how to use Method R performance management software.
• Designing specific Method R software enhancements to suit your needs.

Career Summary

Cary worked at Oracle Corporation from 1989 through 1999. In the early 1990s, he created Oracle's OFA Standard, which became the default configuration standard for Oracle software installations worldwide. Many of the SQL scripts he distributed throughout his Oracle career (called "Oracle APS") are still in use today. At Oracle, he accumulated various honors including Oracle Consulting's "Consultant of the Year" award. He visited hundreds of clients on performance and architectural projects and spoke to thousands of architects, DBAs, and developers in courses, seminars, and user groups. He was a founding member of the Massive Open Systems Environment Standards group, where he worked directly with Oracle Development and Marketing to help shape features that Oracle would release in versions 7 through 11. When he departed Oracle in 1999, he was a Vice President in charge of 85 performance consultants and a 15-person service line group that constructed system architecture and system management services for Oracle Consulting practices worldwide. In 1999, he co-founded a company called Hotsos. In April 2008, Cary severed his partnership with Hotsos to begin a new company called Method R Corporation.

In the early 2000s, Cary pioneered the idea that a full and unambiguous account of an Oracle session's end-user response time (called a profile) could be obtained from Oracle extended SQL trace data. The motive and means for obtaining this information helped to revolutionize the way Oracle performance analysts work. To explain the process, he wrote Optimizing Oracle Performance with Jeff Holt, which earned Oracle Magazine's 2004 Author of the Year award. He led the design and development of the Hotsos Profiler software package, which automates the most difficult part of implementing Method R for Oracle applications. He created and taught courses and seminars to Oracle practitioners at events all over the world. He co-founded the Oak Table Network, a loose association of like-minded people who make their livings from their expertise with the Oracle database engine and their skill at handling performance issues. In 2007, Oracle Corporation granted him the status of Oracle ACE Director.

During production of Optimizing Oracle Performance, Cary established and proved the theory that the location of the "knee" in an M/M/m queueing system's response time curve depends only upon the system's number of parallel service channels (m) and is in fact independent of the arrival rate (?) and service rate (?). This result makes it possible to plan computer capacity requirements with much simpler models than practitioners had tried to use in the past.

Cary Millsap Presentations

Here is a sampling of some of the 1- to 2-hour presentation topics that Cary Millsap presents at conferences, user groups, and customer sites all over the world. To book Cary Millsap, for a speaking engagement, please mail us directly at This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Thinking Clearly About Performance

Creating high-performance as an attribute of complex software is extremely difficult business for developers, technology administrators, architects, system analysts, and project managers. However, by understanding some fundamental principles, performance problem solving and prevention can be made far simpler and more reliable. This paper describes those principles, linking them together in a coherent journey covering the goals, the terms, the tools, and the decisions that you need to maximize your application’s chance of having a long, productive, high-performance life. Examples in this paper touch upon Oracle experiences, but the scope of the paper is not restricted to Oracle products.

For Developers: Making Friends with the Oracle Database

To many application developers, an Oracle database is just a "data store" with an API that they call when they need to persist an object. It’s a helpful abstraction for managing functional complexity, but it can lead to some horrible performance problems. You can avoid those problems by better understanding what’s going on inside the Oracle kernel. It’s not that hard to do. The key is understanding how to measure how your code spends time inside Oracle. Once you’ve done that, your response time profile leads you exactly to your performance improvement opportunities.

Optimizing for Oracle: When? How?

If premature performance optimization is a root of evil—and Cary Millsap believes it is—then developers face a difficult question: When and how are you supposed to optimize? If you optimize prematurely, you face the consequences of investing resources that are easy to prove after the fact to have been wasted. If you optimize too late, you create serious jeopardy for your customers and yourself as your applications fail to scale up to the user loads they are required to support. In this session, Cary offers a lifeline: a process and a set of guidelines that will allow you to reduce your risk of post-production performance crises, while not requiring you to overinvest into performance apprehensions that may never materialize.

How to Make Application Performance Easy to Diagnose

Diagnostic data collection can be the most difficult step in any system performance improvement project. But the collection of good diagnostic data doesn't need to be difficult. The determining feature is the application itself. The key to making application performance easy to diagnose lies in the hands of the application developer. This session shows how a few simple development decisions can make application performance easy to diagnose.

Why You Can't See Your Real Performance Problems

Reflecting across nearly 20 years of solving Oracle performance problems, Cary Millsap has recognized a single pattern of behavior that is the dominant reason for failure in all the projects he has witnessed. In almost every case he has seen, failures in diagnosing and repairing performance problems have been caused by unrecognized skew in diagnostic data. This presentation shows several examples that illustrate why skew is such a pervasive problem for performance analysts.

Repairing Oracle Performance Problems

In 2003, Cary Millsap and Jeff Holt published a new method for diagnosing and repairing Oracle system performance problems (Optimizing Oracle Performance: O'Reilly). Users of what the book calls Method R (the 'R' stands for "Response time") routinely fix performance problems that had evaded repair (and sometimes even detection!) by other methods for months or more. This session demonstrates how Method R works and how people use it to diagnose and repair system performance problems in perfect alignment with business priorities. The case study uses Oracle diagnostic data specifically to show how even very difficult performance problems relent quickly and permanently to the method.

Preventing Oracle Performance Problems

In 2003, Cary Millsap and Jeff Holt published a new method for diagnosing and repairing Oracle system performance problems (Optimizing Oracle Performance: O'Reilly). After solving the important diagnostic problem, their research turned to the subject of preventing such problems from occurring in the first place. The ultimate goal is a method through which you can always understand what your next performance problem will be so that you can diagnose and repair the problem before it ever actualizes as an end-user experience. This session summarizes the progress of their research so far.

Measure Once, Cut Twice

"Measure Twice, Cut Once" is a reminder that careful planning yields better gratification than going too quickly into operations that can't be undone. Sometimes, however, it's better to Measure Once, Cut Twice. It's one of the secrets behind how carpenters hang square cabinets in not-so-square kitchens. And it's one of the secrets behind how developers write applications that are easy to fix when they cause performance problems in production use. The key is to know which details you can plan for directly, and which details you simply can't know and therefore have to defend yourself against. In this session, Cary will discuss some aspects of software development where flexible design is more important than detailed planning, using woodworking analogies for inspiration. He will describe some particular flexibilities that your software needs, and he'll describe how to create them.

Accountability for System Performance (introducing Six Sigma quality in software performance management)

Businesses are commonly organized in such a manner that the departments held accountable for making application systems fast and efficient don't have enough leverage to get the job done. The result is painful. Users suffer from slow applications, and system costs spiral while organizations expend energy deflecting blame. This session describes how the right measurements and a few process changes can produce a culture of performance accountability across departments, resulting in faster, cheaper, more efficient systems.