quartz/content/notes/22-performance-and-security.md

title	aliases	tags
22-performance-and-security		info201 lecture

Performance requirements

• e.g., credit card system
  • functional reqs
    • sales authorised only for valid cards
    • generate monthly statements
    • performance requirements
      • cards are validated quickly
      • statements are accurate and generated on time
    • quickly, accurate, and on time need to be operationalised, measured, and tested.

Why are they important

• vital quality factor
• infosystems are wide and varied
• wide range of performance characteristics

Things to consider

• can interact and conflict with each other

  • accuracy vs speed
  • speed vs space
  • often a trade-off or compromise

• selectig best developent techniques for taget system

  • algorithms
  • data structures
  • languages and frameworkds
  • constraints of target platform
    • (devs machines are often more powerful)
    • minimum requiremnts for system e.g., min specs for windows
  • ...

• impact of changing requirements, e.g., adding a new module

• need to consider (often conflicting) organisational priorities

• critical to unambiguously document and agree

Response time

• what is quick

• for most people

  • < 0.1s: instant
  • 0.1s to 1s: noticable
  • 1s to 10s: slow

  • 10s: user will probably switch tasks

• affected by system workload: number of concurrent users, volume of data, etc vs available resources

• most users really dislike variable response times (unpredicatbility)

• example requiremen: "cards are validated within 2s"

  • this implies 100%
  • better: "95% of cards are validated within 2 s"

• other consideration

  • what is included in response time?
  • what is the measurement period (of the system in general) (often varied workload changes performance)
  • what is the acceptable error rate

Workload

• system workload is almost never constant

  • may may well defined peaks and troughs
  • may be unpreditable
  • peak vs typical vs minimum

• differet transaction types

  • read vs write transactions
  • online vs batch

• define workload requirements around use cases

• e.g., " the system must be able to validate 1 million cards per day"

Scalability

• can the system scale to meet changing demand
• can it scale quickly enough
• elasticity particularly important to large public-facing systems
• can be difficult to test "for real"
• example requirement: "the system must be able to handle up to 2 million cards on a busy day"

Platform

• target for system deployment
  • on prem
  • cl