Chapter 8

Performance and Scalability

 Moore’s Law

 Processor power increases by a factor of 2 every 19 months

 Is this true?

 How long will it continue if so?

 The Un-Slippery Slope

 Hardware Architecture Gap

 The gap between what the processor could do and what it actually does do

 The processor is faster than the memory and every now and then it must
wait

 Figure 8-1

 Hardware Architecture Gap

 If reference is not in cache, it must fetch it from main memory

 Doesn’t seem like a big deal, right?

 Hardware Architecture Gap

 If space is needed in cache, then system must write cache to main memory before
fetching new data, causing a wait time for processor

 Hardware Architecture Gap

 If another processor is writing to memory first, then it may cause more delay

 If another I/O is being done, there may be a delay

 The wait time adds up and can create problems or time out, but most importantly wasted
cycles!

 Hardware Architecture can have an impact on performance

 Unisys CMP hardware

  Cross-bar memory interconnects

 Third-level cache shared by processors

Separate I/O processors

 There are 3 ways to improve performance:

 1) Faster Processor

 2) Improve Hardware Architecture

 3) Push the application leftward, down the slope

 How to push the application down the slope:

 Reduce active memory footprint

 Reduce the number of task switches

 Reduce lock contentions

 Reduce the number of I/O’s

 Reduce the number of network messages sent or received

 Reduce the number of memory overlays

 Reducing the active memory footprint

 The amount of memory used for the main path processing

 If the amount of memory needed for the application is more than what is available
in cache, the cache memory will continually be recycled

 Reduce the number of task switches

 Saving data values to main memory from cache and reloading a new set of values

 Reusing data values in cache by two separate tasks may be rare

 Reduce lock contention

 Two processes attempting to use the same piece of data at the same time

 Only one process can hold the lock on a piece of data at a time
  Reduce the number of I/O’s

 Input and Outputs are disruptive to memory and processing

 I/O’s can fill cache with data that is not reused and therefore is a waste of memory
use

 I/O’s can lead to lock contention

 I/O’s can cause data reloads to cache (increasing process switches)

 Reduce the number of network messages sent and received

 Additional overhead to system is similar to the I/O’s

 Building messages and handling network protocol also ‘tax’ the system

 Reduce the number of memory overlays

 Wiping out data in memory and replacing with new

 Transaction Processing

 One Input and One Output message

 A number of reads and writes to the data file

 A write to the log file

 Figure 8-3

 Where are the bottlenecks?

 A bottleneck is a point of potential delay in the transmission

Figure 8-4

 What about disk throughput?

 Disk throughput is how many transactions the disk can handle

 Spreading the load will optimize the load, but will require software and hardware
to do it

 Figure 8-5

 What about memory?

  The operating system, networking and database software all need to use memory

 Use a transaction monitor to assist in sharing programs and resources among all
of the connected terminals

 Two-Phase Commit

 When you update two or more databases on different systems, there are additional
network messages and disk writes

 Figure 8-6

 Potential issues with the Two-Phase Commit

 Source of delays exist when sub-transactions are initiated and a log is written on
subsystem

 Locks can be held longer and potential timeouts can occur or lock contentions

 Message Queuing Issues

 You must set a schedule to empty the queue or start other systems to keep it
efficient

 Another method would be to pass the messages to the transaction monitor to

process the messages, which would start the necessary services

 Remote Database Access

 Inefficient for real-time transactions

 Every database call becomes a network message, or several messages

 These messages increase network overhead

 Using Transaction Servers Solve the Problem

 Use store procedures to call the set of commands to run

 Figure 8-7

 Batch

 3 Basic Reasons for Batch

 1) Support cyclical business processes

  2) Support housekeeping tasks

 3) Optimization

 Perform some task prior to update

 Updates are not done until batch is run

 Batch Problems

 Ran at night

 Interferes with other updates

 International business requires 24/7 uptime

 Load Balancing

 Figure 8-7

 4 Tiers

 Web Browsers

 Web Servers

 Transaction Servers

 Database Servers

 Load Balancing

 Any number of Web Servers

 Any number of Transaction Servers

 All working on the same application

 Any number of database servers

 Load Balancing Web Servers

 This requires special network router that allows the external connections to
connect at 1 point (IP/Web address)

 The network router then spreads the connections among the web servers
  Also must ensure the data in all of the web servers is the same

 Using the dual-active approach solves it

 Put all state in the back-end

 Business Intelligence Systems

 Includes these types of systems:

 Data Access

 Data Marts

 Data Warehouse

 Decision Support

 All need to handle Ad Hoc Queries and Data Replication

 Ad Hoc Queries

 I/O Intensive!

 Causes:

 Checking each record against the search criteria

 Moving data to the output message

 Sorting

 Parsing the query, building a processing plan, and optimizing the plan

 Managing temporary data

 Doing arithmetic calculations, checking for nulls

 And much, much more

 Ad Hoc Queries

 Large queries will need large amounts of memory

 They will clear memory of other items not related

 Large queries will dominate the I/O

 Data Replication

 Take a copy of the database

 Keep database up-to-date by applying the changes

 Take changes from the logs

 Do not commit failed processes

 Is network intensive

 Use less larger messages instead of many smaller ones

 Data Replication

 Delay usually occurs at system load time

 Ways to handle the load:

 Allow ‘back-up’ to get behind during work hours and catch up overnight

 Sort data before inserting into table

 Use software to help manage the load

 Backups and Recovery

 The more users, the more important not to have a failure

 The larger the database, the more likely of hardware failure

 There’s more hardware that can fail

 The more transactions, the bigger the log file

 Larger the log file, the longer the reconstruction

 The larger the database, the longer to backup

 Backup copies should be made more frequently for large databases, so less to
reconstruct

 Backups and Recovery

 The bigger the database:

  The more there is to manage

 The longer tasks will take

 The bigger the files

 The more space needed

 The more people to please J

Figure 8-8

 Web Services: Transmission Times

 What can affect transmission times?

 Packet loss

 Distance to travel

 Physical transmission medium

 Bandwidth max speed

 Network congestion

 Condition of network infrastructure

 Distributed System Performance Measurement

 Unfortunately this is almost impossible

 You can measure at single nodes

 You can get an estimate of the overall performance but no real measurement

 Chapter 9 Systems Management

 5 Categories of Systems Management

 1. Administration

 2. Operation
  3. Fault tracking and resolution

 4. Performance management and accounting

 5. Security (discussed next week)

 1. Administration

 All aspects of managing the configuration of a system

 Hardware additions/changes/ removals/updates

 Software additions/changes/ removals/updates

 User access to Network

 2. Operation

 Keeping the system running

 Manage the work flowing through the system

 Backups

 Detecting faults

 Starting and stopping transaction-processing applications

 Running batch jobs

 User maintenance for applications

 3. Fault Tracking and Resolution

 Faults must be recorded for fixing later

 Log technical details at the time of the fault

 Time, user, application, errors, etc

 Identify seriousness of the fault

 4. Performance Management and Accounting

 Statistical information is gathered at various points in the system to provide raw

information for the activity
  Use data to predict future needs

 Use for performance tuning

 Generate billing information

 Use for determining service-level requirements

 Maintenance

 Usually done at night when network and system traffic is lighter

 Define ‘night’ in a global system

 Critical and routine updates/releases are done at defined intervals

 Depends on how critical

 Define critical

 Systems Administration Group

 Ensure configuration changes are made in an orderly fashion and time

 Operations Group

 Ensures the system is running

 Monitors systems

 Works with Systems Administration group to implement changes

 Fault and Tracking Group

 Investigates and Resolves errors with Operations groups

 Performance Management Group

 Provide short-term performance monitoring

 Provide long-term capacity planning

 Consider Automating Processes and Tasks

 Large-scale systems need automation

 Too many tasks for manual intervention

  Reserve complex decision making and review for humans

 Silo vs. Distributed System

 Which is simpler?

 Which is easier to manage?

 Which is easier to implement components?

 Operational Systems Management

 Monitor and Control

 Interacts directly with the system and monitors what is going on

 Process and Manage

 Processing and recording information, and displaying information to

operators

 Managed Object – contains the Monitor and Control element in the form of an Agent

 Anything needing management

 Application, database, card in router

 Manager – contains the Process and Manage element

 May also contain an Agent

 Rules Engine

 A filtering agent that only lets the necessary information flow through to the
database for processing

 Saves processing, network, memory, etc.

 Two groups of systems management products

 Point Products – perform a specific aspect of management

 Suite Products – provide a complete suite of services for systems management

 Both can be integrated and automated

 Autonomic Management
  Allow systems to be self-healing, detecting and correcting problems

 Any problems with this?

 Report errors for fixing later

 Chapter 10 & 11

 Chapter 10 - Security

 Major Security Concerns

 Authentication

 Access Control

 Protection

 Security Management

 Authentication

 Identifying a user is who they say they are

 How can we do this?

 Access Control

 AKA…Authorization

 Giving an Authenticated user the authority to use a resource in a specified way

 Any examples?

 Protection

 Stopping unauthorized access to resources

 Can be divided among any number of categories to review for proper protection

 See next slide

 Protection Continued…

 Confidentiality – only access to ‘needed’ resources

  Integrity – protection against tampering

 Nonrepudiation – retains originator integrity

 Example: digital signature

 Denial of Service – protection against malicious service blockages

 Physical Protection – physically locking up the building/equipment

 Security Management

 How security will be administered

 Who grants/denies access

 Who decides who/what has access to what

 How security breaches are handled

 Automated reporting?

 Manual reporting?

 What Security is needed?

 Define a list of security requirements BEFORE designing implementation

architecture

 Look at the Data first!

 Decide who needs to see what

 Grant minimum level access

 Decide who need to modify what

 Deny all others

 Define User Roles

 Groups of Users will have the same needs to view/modify data

 Easier to manage

 Has potential for granting too much access

  Read-Only Users

 Manager Roles

 Running Reports

 No data modification needed

 Assigning Roles

 During planning stage, state intended actions

 During implementation the needs or access levels may change depending on

implementation strategy or changes made since initial plan

 If Data is Duplicated…

 How is access controlled?

 Access level strategies need to be consistent and synch’d with anywhere

the data is being ported

 You do not want to deny access on one system and open it up on another

 How to prevent Internal Fraud

 Multiple Level Authorizations

 2 or more employees must give authorization for something to be

approved

 Use fast detection systems to quickly identify suspicious activity

 Build in recovery procedures for access violations

 Auditing

 Logging

 Log suspicious activity

 Log User Logins

 Successful and Failed

 Automatic notification to Admin of violations

 Access to Secure Information

 Require Multiple-Authentication

 2 or more users need to approve before access is granted

 Can be physical, biometric, electronic

 Can be isolated to specific terminals

 Can also be Video surveillance to ensure user access is logged

 Daily Reports of Access reviewed

 Auditing User Activity

 Who should be in charge of auditing?

 What should they look for?

 Who would they report it to?

 What actions could be taken?

 How could it be done?

 Distributed System Security

 The “Onion Model”

 A Layered Approach

 Things on the inside are protected

 Authentication needs to be done at every layer

 Outside layer is protection to inner layers

 Resource and access point on every layer

 Access Points authenticate access from each outside layer

 To access inner core layers, authentication must occur from each outer
layer

 Access Points
  Firewalls

 Middleware

 Server system software

 Custom code

 All of the above will attempt to keep out unauthorized access

 Authenticating Server

 Located on outer layer

 Must be physically secure too

 Controls all access to system

 Must be strong authentication or an intrusion could assume the identity of any

user and access anything inside the inner layers

 Must be kept current with patches/updates to combat the most current threats

 Location Security

 Messages of a certain kind are restricted from coming from only a particular
location

 Restricts updates/access requests to come from only one server

 Unauthorized server requests would be denied and logged

 Location Security Continued…

 Firewalls can provide protection

 Separate networks can provide location security

 Branches of company on separate networks

 Departments operating on separate networks

 Boiling Lava Model

 Multiple Security Management regimes being used to different parts of the system

 Result of Silo systems being networked together

  Each silo having its own security

 Departmental policy to have each department manage their own access

 Boiling Lava Threats

 Users need multiple logon id’s

 Writing down passwords and id’s are a problem

 Sharing user credentials to others since access is difficult

 User access may not be rescinded when employee leaves organization

 Single Sign-On

 User logs on once and is granted access to everything using single sign-on
software

 Good and Bad, Why?

 Boiling Lava Model

 Confidence in security?

 Is it secure?

 Is it consistent?

 Is there a central authority?

 Should it be implemented?

 Web Services Security

 Onion Model doesn’t work on the Web

 On the web, all services are peers and not layered

 Example: A crate of apples

 Little possibility of location security

 Assumptions of authentication are not made

 Secure Sockets Layer (SSL)

  “https://” web address prefix

 Opens a session using encryption keys that are sent with messages

 Userid / password software can also be used with SSL to enhance security

 SSL sets up secure session

 Logon is performed

 Security Tokens

 Embedded user information in the message

 Can contain userid, access level, time

 Similar to your work id used for building access, but it is electronic

 May contain a hash to verify tampering

 A verifiable digit that can be decrypted

 WS-Trust Standard

 Requestor contacts Security Token Service to get a token

 Requestor contacts web service and includes token

 Web Service uses token received and contacts Security Token Service to validate
the token

 Web Service grants access upon successful validation of token

 5 Main Implementation Questions

 1. Which applications belong in which security context?

 2. Where is authorization going to take place?

 3. Where is access control going to take place?

 4. Where is security management going to take place?

 5. What threats exist and what are the countermeasures?

 Implementation Planning
  Use a network diagram and overlay security

 Indicate where access control points will be located

 Indicate where authentication will take place

 Access Control

 Where will this occur?

 Can occur at the server

 Can occur at a place prior to the application services

 Integrating Existing Security

 Access Control points connect old and new

 Provide a consistent security policy

 Bridge the old policies with the new over time

 Chapter 11 - Application Design and IT Architecture

 Design Up-Front or As-Needed?

 I say Up-Front!

 Modify as-needed later in a phased approach

 Waterfall Development?

 RAD?

 Waterfall Development

 Gather all of the requirements up front and develop

 Easier to make changes to fix problems in the requirements gathering

stage then in the design or programming phase

 Problems with Waterfall Development

 End users and the business do not know the requirements, so how do they know it
is right?
  Difficult to express the design to programmer and sponsor in a clear manner

 Division between requirements, design and implementation leads to over

engineering the project

 Iterative Development

 A series of waterfall developments overlapping one another

 Rapid Application Development (RAD)

 Combated waterfall approach in that it allowed for a prototype to be

created and tweaked to give customer what they want, and more quickly

 Eliminated the rigorous requirements gathering

 Business Rules

 Information in databases are facts about the real world

 Define the structure of these facts and how they are processed

 Tony Morgan’s view of Rules

 5 rule patterns

 Tony Morgan’s 5 Rule Patterns

 1.Constraints – dependent on meeting a single criteria

 2.List Constraints – dependent on meeting a set of criteria

 3.Classification – if a certain criteria met, then something happens

 4.Computation – formula to compute

 5.Enumeration – some standard is met

 Rules can be translated to Code

 Using If / Then criteria

 Is a contrast to some ways of thinking where Rules must always be true

 What problems do you see with this?

 Existing Systems
  2 Classes of Programmers

 Lowly Maintenance Programmer

 Superior New Application Development Programmer

 What do you think?

 Reuse of Components

 1.Programmer who writes reusable components

 2.Assembler who writes scripts to call the components

 3.Administrator who writes the deployment descriptors and configures the

production system

 Serendipitous Reuse

 Components likely do not fit every need

 Components may do more than you need

 Wrong technology – Java vs COM

 Security interfaces don’t work

 Component assumptions don’t fit

 May work in small applications

 Architectural Reuse

 Define reuse opportunities while you are designing architecture

 Reuse only occurs if you design it

 Define the interfaces and look for components to implement the interfaces

 Architectural Reuse

 Components most likely to be reused:

 Horizontal Components – consistent use of error reporting, printing and

security components

 Interface to Common Data – customer and product data

  Interface to Common Routines – calculations and data manipulation

 Reuse is good for:

 Screen layouts

 Screen format parts

 Design patterns

 Documentation

 Testing routines

 Organizations are always looking for:

 Faster Development

 Cost Reduction

 Better Security, Reliability and Performance

 Enterprise Architecture will help

 Enterprise Architecture Provides for:

 Combining existing services in lieu of writing new ones

 Cost reductions through less technologies to support

 Better security, reliability, and performance through infrastructure support being

pushed out globally

 Levels of Design

 Outside of IT

 Understand

 Brainstorm

 Clarify

 Analysis

 Repeat clarification and analysis

  Go down a level of detail and find or design the components

 Levels of Design

 IT

 Gather Requirements

 Design Solution

 Implement Solution

 Levels of Design

 IT

 Business Process Level Design

 Is there already something available

 Define Tasks

 How does the user interact with the data