Section 03. Issues with Performance Modeling.
■ Focus on performance before starting with design
Performance should dictate the design from the beginning to the end. Design issues cannot be fixed with fine tuning and better coding.
■ Manage performance risk. How low can you afford to live with? Issue
■ Balance performance with QoS requirements. Not all quality issues are supportable; some need to be relaxed, if not dropped altogether.
■ Identify and analyze key performance scenario. Indicate what kind of performance would be anticipated at a given scenario and how to change scenarios to increase/decrease performance.
■ Evaluate your model to ensure meeting of performance objectives. If need be, recast your model.
■Identify metrics and test cases. What should you measure? How often? When? What do you anticipate? What do you do when performance falls below anticipated level? Should you wait for users to send feedbacks?
For this module to work properly, we need
● An Information Structure to capture performance feedback report along with a profile of attendant scenario.
● A daemon process that would capture the above Information Structure incrementally to be used in the above
sense for updates and new installations.
A plausible guideline for design process principles.
Basically, it needs to be iterative starting with a prototype design reflecting application objectives as much as possible with a particular range of load-size in mind.
Then fine-tuning along the following route:
What goals?
♦ Avoid impractical goals, inconsistent goals and goals that cannot be measured.
♦ Are the goals consistent with scalability?
♦ Are goals measurable and verifiable?
♦ Design goal scenarios like
● What is the peak load the system can take?
● How long a particular request should take?
● How many clients the server can support?
● What’s the maximum throughput rate?
● How much CPU, memory, network-I/O and
Disk-I/O would be required?
Architectural issues:
♦ Does it support anticipated performance?
♦ Is the topology congruent to system’s need?
♦ Does it accord load-balancing, peak-bandwidth needs,
authentication, exception management, instrumentation,
database, data access strategies, state management and
caching?
♦ How costly are its components? Cost-cutting & revision?
Performance tuning:
♦ End-to-end tuning rather than tuning one aspect at a time
♦ Attempt to eliminate bottleneck would shift it to
elsewhere
♦ Not all subsystems are of equal importance. Weigh their
importance in performance fine-tuning.
System Management through its life-cycle:
♦ Continuously improve system during its life-cycle.
♦ Observe performance profile in meeting the following:
● number of users served (peak, off-peak, average)
● amount of data-volume moved
● service density per unit time
● shared resource usage
Design principles:
♦ Aim for coarse-grained services to clients.
- Fine-grained services strongly coupled
client/server system
Coarse-grained services allows abstraction of
service needsvia hierarchy
♦ Minimize round-trip time by batch work design
♦ Acquire late and release early database and network
connections. It is expensive for OS to establish repeated
connections.
♦ Determine centricity of processing.
●If client-centric move processing near to client
● If data-centric move processing near database
♦ Specific processing needs. Processing affinity to specific
processors. If client/server interactions require specific
processors, the interactions are bound to it. Minimize
such dependency. Estimate this dependency and how it
affects scalability.
♦ Pool shared resources.
♦ Avoid unnecessary works. e.g. Do data validation early.
Cut unnecessary redundancies.
♦ Reduce contentions. Focus on blocking and hotspots.
● Reduce blocking by sharing resources judiciously
●Duplicate hotspots to reduce contentions.
♦ Emphasize progressive processing.
● Perform incremental updates
● Provide clients output incrementally
● Provide anytime or incremental computing
♦ Process independent tasks concurrently
A typical client/server profile shows the areas of considerations.