1. Methodology
Performance tuning is a wide subject, probably a misunderstood subject; so it has become a common practice among technologists and application vendors to regard performance as an issue that can be safely left for a tuning exercise performed at the end of a project or system implementation. This poses several challenges, such as delayed project deployment, performance issues unnoticed and compromised because of delayed delivery of applications for performance optimization, or even the entire phase of performance optimization omitted due to delays in the various stages of the development cycle. Most important, placing performance optimization at the end of a project life cycle basically reduces opportunities for identifying bad design and poor algorithms in implementation. Seldom do they realize that this could lead to potentially rewriting certain areas of the code that are poorly designed and lead to poor performance.
Irrespective of a new product development effort or an existing product being enhanced to add additional functionality, performance optimization should be considered from the very beginning of a project and should be part of the requirements definition and integrated into each stage of the development life cycle. As modules of code are developed, each unit should be iteratively tested for functionality and performance. Such considerations would make the development life cycle smooth, and performance optimization could follow standards that help consistency of application code and result in improved integration, providing efficiency and performance.
There are several approaches to tuning a system. Tuning could be approached artistically like a violinist who tightens the strings to get the required note, where every note is carefully tuned with the electronic tuner to ensure that every stroke matches. Similarly, the performance engineer or database administrator (DBA) could take a more scientific or methodical approach to tuning. A methodical approach based on empirical data and evidence is a most suitable method of problem solving, like a forensic method that a crime investigation officer would use. Analysis should be backed by evidence in the form of statistics collected at various levels and areas of the system:
From functional units of the application that are performing slowly
During various times (business prime time) of the day when there is a significant user workload
From heavily used functional areas of the application, and so forth
The data collected would help to understand the reasons for the slowness or poor performance because there could be one or several reasons why a system is slow. Slow performance could be due to bad configuration, unoptimized or inappropriately designed code, undersized hardware, or several other reasons. Unless there is unequivocal evidence of why performance is slow, the scientific approach to finding the root cause of the problem should be adopted. The old saying that tuning a computer system is an art may be true when you initially configure a system using a standard set of required parameters suggested by Oracle from the installation guides; but as we go deeper into testing a more scientific approach of data collection, mathematical analysis and reasoning must be adopted because tuning should not be considered a hit-or-miss situation: it is to be approached in a rigorous scientific manner with supporting data.
Problem-solving tasks of any nature need to be approached in a systematic and methodical manner. A detailed procedure needs to be developed and followed from end to end. During every step of the process, data should be collected and analyzed. Results from these steps should be considered as inputs into the next step, which in turn is performed in a similar step-by-step approach. A methodology should be defined to perform the operations in a rigorous manner. Methodology ( a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures ) is the procedure or process followed from start to finish, from identification of the problem to problem solving and documentation. A methodology developed and followed should be a procedure or process that is repeatable as a whole or in increments through iterations.
During all of these steps or iterations, the causes or reasons for a behavior or problem should be based on quantitative analysis and not on guesswork. Every system deployed into production has to grow in the process of a regression method of performance testing to determine poorly performing units of the application. During these tests, the test engineer would measure and obtain baselines and optimize the code to achieve the performance numbers or service-level agreements (SLA) requirements defined by the business analysts.
Performance Requirements
As with any functionality and business rule, performance needs are also (to be) defined as part of business requirements. In organizations that start small, such requirements may be minimal and may be defined by user response and feedback after implementation. However, as the business grows and when the business analyst defines changes or makes enhancements to the business requirements, items such as entities, cardinalities, and the expected response time requirements in use cases should also be defined. Performance requirements are every bit as important as functional requirements and should be explicitly identified at the earliest possible stage. However, too often, the system requirements will specify what the system must do, without specifying how fast it should do it.
When these business requirements are translated into entity models, business processes, and test cases, the cardinalities, that is, the expected instances (aka records) of a business object and required performance levels should be incorporated into the requirements analysis and the modelling of the business functions to ensure these numbers could be achieved. Table is a high-level requirement of a direct-to-home broadcasting system that plans to expand its systems based on the growth patterns observed over the years.
Table 1-1.
Business Requirements
Entity | Current Count | Maximum Count | Maximum Read Access (trans/sec) | Maximum Update Access (trans/sec) | Average Growth Rate (per year) |
---|
Smartcards | 16,750,000 | 90,000,000 | | | 4,250,000 |
Products | 43,750,000 | 150,000,000 | | | 21,250,000 |
Transmission logs | 400,000 records/day | 536,000,000 | N/A | | 670,000,000 |
Report back files | 178,600 records/day | 390,000,000 records processed/year | N/A | N/A | 550,000,000 |
Note: trans/sec. = transactions per second; N/A = not applicable.
It will store for 15 million subscriber accounts.
Four smart cards will be stored per subscriber account.
Average growth rate is based on the maximum number of active smart cards.
The peak time for report back transactions is from midnight to 2 AM.