Database Reference
In-Depth Information
the maximum number of concurrent connections through a shared firewall, which leads
to dropped connections and application instability in test or production. It could be a
shared storage array that gets overloaded or experiences performance degradation
during performance benchmarks, which then impacts other workloads. The reality is that
many organizations can't afford to have completely separated and isolated production
and non-production environments. Often the costs are simply not justified. In those
cases, you need to take a risk-based approach and understand what the limits are, what
the impacts might be on your testing or on production while you're testing, and come up
with a plan to mitigate those risks.
Invalid Assumptions Leading to Invalid Conclusions
Often during baselining and benchmarking exercises or database migration projects, you
will need to make assumptions where there is no clear information. Sometimes these
assumptions could prove incorrect, and this might cause some or all of your conclusions
to be invalidated. An example of an assumption that could lead to invalid performance
conclusions is if you assumed an existing shared storage array, the same as is being used
for your physical databases, would be used once the databases are migrated to virtual
machines. If this is correct, you may expect similar storage performance as the physical
database systems currently enjoy, assuming the infrastructure design is similar. If this
proves incorrect and you made an assumption about storage performance based on this,
it could be completely invalid. You would potentially need to repeat some tests to
determine what the actual performance will be.
Lack of Background Noise
Often you might find if you do benchmarking in an isolated test environment that your
performance results are actually better than production, even though your test
environment might be configured similarly to production. This can be caused by the lack
of background activity or background noise of other systems in the test environment. In
production, you would have a multitude of different systems and many users pounding
away day and night. This type of background noise is often very hard to simulate in a
test environment, but it is important to at least consider it as part of your benchmarking
and baselining activities and, if necessary, make assumptions (often called an educated
guess) and make adjustments to your results.
Failure to Considering Single Compute Unit Performance
Single Compute Unit (SCU) Performance refers to the execution performance of a single
thread or single unit of work and is impacted by the clock speed of the system CPUs.
The levels of cache within a CPU can also influence SCU Performance. The higher the
SCU, the faster queries will execute and the faster response times may be for certain
 
 
 
 
Search WWH ::




Custom Search