extensible contract broker for performance...

1Pedro Pedro FurtadoFurtado, SEAMS, 26, SEAMS, 26--27 May 200727 May 2007

1

Extensible Contract Broker for Performance Extensible Contract Broker for Performance DifferentiationDifferentiation

Pedro Pedro FurtadoFurtado, , CelsoCelso SantosSantosUniv. of Univ. of CoimbraCoimbra

CISUCCISUC

PortugalPortugal


The Context of this workThe Context of this work

• Initial: to build an external middleware for database

backend that: – allows the backend to adapt to different runtime contexts

– provides differentiated service for applications

• Pursuing– Strategies for re-configuration and adaptation

– Platform to define those strategies and apply them

• Currently: – Generalizing the concept for generic applications, and to distributed

environments with hierarchies of Brokers


Running Context

Running Context

Differentiated Service and Differentiated Service and AdaptationAdaptation

Software System

(module )

Software System

(module)

• Configurable Broker– Modular– Reusable strategies

Software System

(module )

Software System

(module)

Configurable Adaptation

• Hard-Coded, where needed

Configure

Configurable adaptation

Design-time concerns

Runtime concerns, protocols

Configuration


Some Related Projects and Some Related Projects and IssuesIssues

• IBM work on autonomic systems

• C-JDBC (sequoia)– Clustered JDBC

• RT-QoS– QoS Management for Real-Time Databases

• QuO - Quality Objects– Framework for providing quality of service (QoS) in network-centric

distributed applications

• Rainbow– Architecture-Based Self-Adaptation with Reusable Infrastructure


DBDB--servers and Transactionsservers and Transactions

• Configure QoS (e.g. Performance) differently for different client

characteristics

• Modify server parameters automatically depending on conditions and

rules?

– Admission control, scheduling– Replicate partially, optimize replication– Configure replication and load-balancing parameters depending on context– Provide availability guarantees– Mobile operation

DBMS

DBMS

DBMS


Some Broker conceptsSome Broker concepts

• Applications can use Broker services,

configuring for their targets:

• Targets– Application items over which to apply features

• Service Features (SF) – service and resource use differentiation strategies (QoS) that

the Broker offers

• Contracts– Conditions and rules of action for application of service features

to targets


The Basic Broker Design The Basic Broker Design


Brokering ActionsBrokering Actions

• Tagging of targets– Identification of application items that are subject to QoS

• Contracting– specification of conditions, rules, SF and parameters that are to be

applied to targets

• Intercepting Application Targets– Identifying defined targets at runtime, retrieving contracts

• Monitoring and acting– Collect runtime statistics, monitor contracts for conditions

– Managing resources, Acting at runtime


Targets, intercepting for DB Targets, intercepting for DB backendbackend

Client Appl

JDBC

Postgres

JDBC-wrapper

Postgres

Broker Action

Intercepting with

a JDBC Wrapper

• Broker identifies transactions– SQL statement patterns, commits, etc

• Only changes to application:– Jdbc library replaced by jdbcWrapper library

– Connection con; -> ConnectionWrapper con;

Client App


AlternativeAlternative

JDBC

Postgres

postgres@5432

Postgres

postgres@5433Broker Action

Intercepting with

a FAKE PORT

• Only changes to application:– Indicate different port in JDBC connection establishment

statement

postgres@5432

JDBC

Client AppClient App


Application TaggingApplication Tagging

DB Backend

Intercepting With inserted Calls to Broker

Library methods

Client App/Service Client App/Service

Broker Action

Broker lib

• Changes to application:– Broker Library methods

– Calls to Broker methods

DB Backend


Application TaggingApplication Tagging

• Naming– User/Client indicates methods that are targets

– May also specify conditions (e.g. variable=value)

• Exampletype=thread

:user_profile=loggedCustomer

method=payment

• Tagging (and interception)– Tagger tool searches and embeds calls to Broker lib, testing

conditions and obtaining variables as well


ContractsContracts• Identify a target, Specify service features and Condition-Action rules:

• Target may be any combination of: – Individual client thread

– Method, code block

– DB session, transaction, SQL statement

<CONTRACT>

<TARGET>payment</TARGET>

<USE-SERVICE>Premium</USE-SERVICE>

<ACTION-LIST>

<ACTION>

<DEADLINE>10000</DEADLINE>

<DO>Warning</DO>

<DEADLINE>20000</DEADLINE>

<DO>Kill</DO>

</ACTION>

</ACTION-LIST>

</CONTRACT>

Service Feature

Condition-Action

target


Target TrackingTarget Tracking

• Request Manager and Monitor– Sessions hashtable

• maintains information on which target each client thread or DB session is running (if

any)

• Grabs and monitors contracts related to running target

– Monitorization and Statistics Collection• Verifies contract conditions for currently active items

• Collects statistics for use by adaptable service features

– Service features• Applies service features according to the contracts

– Action

• Acts if necessary, according to contract


Statistics, Workload AnalysisStatistics, Workload Analysis

• Monitor and characterize target runtime characteristics

(e.g. execution times)

• Identify number of simultaneous threads for maximum

throughput (for a workload)

• (...)Response Times

0

5000

10000

15000

20000

0 10 20 30 40 50

NEW_ORDER

PAYMENT

ORDER_STATUS

DELIVERY

STOCK_LEVEL

200

400

600

800

1000

0 10 20 30 40 50EC

TPM

s


Service FeaturesService Features

• Service and Resource Use differentiation

strategies (QoS)– Extensible (can code additional SF)

– Broker is applicable to any application

– Given targets, we may wish, for instance:• Differentiate requests based on client sessions or combinations of:

– Method, Client thread, DB session, transaction, SQL statement

• Deadline hints, for the system to try to meet them

• Deadline Warning and Notification

• Schedule and Load Balance with multiple servers

• Resource reservation

• Feedback-based admission control (based on the miss rate)

• Availability differentiation

• (...)


Service Features (SF) need Service Features (SF) need parameterization ...parameterization ...

• SF configuration parameter– e.g. There are three queues (Premium, Fast Service, Normal)

with weights (50%, 30%, 20%)

– e.g. Load balancing may be RR or WRR or LWR

– Reserve 20% of server for Premium requests

• What SF to use for a specific target:– Within contracts

• SF to apply

• Specific SF parameters to apply


SF with configuration parameters SF with configuration parameters <SERVICE >

<NAME>DIFFERENTIATED-SERVICE</NAME><QUEUE-LIST>

<QUEUE><SERVICENAME>Premium</SERVICENAME><WEIGHT>50</WEIGHT><RESV>20</RESV>

</ QUEUE>

< QUEUE><SERVICENAME> Fast Service </SERVICENAME><WEIGHT>30</WEIGHT><RESV>10</RESV>

</QUEUE><QUEUE>

<SERVICENAME> Normal </SERVICENAME><WEIGHT>20</WEIGHT><RESV>0</RESV>

</QUEUE></QUEUE-LIST>

</SERVICE>


Examples:Examples:

• Number of simultaneous clients limited - queue

• Priority Queuing Example:– NEW ORDER transaction on 10 sessions (out of 90) runs in Priority Queueing

• Weighted Round Robin:– 90 terminals with 1/3 of those Premium, 1/3 Fast Service and 1/3 Normal

service

<CONTRACT><TARGET>

<TRANSACTION>NEW-ORDER</TRANSACTION>

<SQL>ALL</SQL>

<SESSION>1-10</SESSION>

</TARGET>

<USE-SERVICE>PRIORITYQUEUE</USE-SERVICE>

</CONTRACT>


• With WRR wait times were divided unevenly as desired

• PQ allowed priority transactions to have small total time in a

congested state (where wait times were large)

0

2000

4000

6000

8000

10000

12000

14000

16000

Exec

Tim

e (m

secs

)

Premium Fast Service Normal

Wait Queue

Execute time

Weighted Round Robin


Admission Control RuleAdmission Control Rule

• Restrict admission of new clients when miss

rate is above 10% in the last minute

0

2000

4000

6000

8000

10000

10 20 30 40 50 60 70 80 90

Nr of Terminals

Exec

. Tim

e (m

se

Avg Time without admission control

Avg Time with admission control

Adm Ctrl triggered


LoadLoad--Balancing with runtime Balancing with runtime constraintsconstraints

• Load-balancing ORBITA approach:– Characterize reponse times of targets (monitor, statistics)

– Schedule targets differently to servers base on statistics (SF)

Miss Rate Throughput of big tasks


Current and Future WorkCurrent and Future Work

• Adaptation strategies to meet contracts– Already have some interesting results in load balancing and admission control

• Applying and extending WSLA in our context– We are redefining most of the sintax using WSLA

– www.research.ibm.com/wsla/

• Systematic language for features, architecture elements, concerns

and rules of action– e.g. RainBow

• Broker Architecture and Service Features to Broker and provide

differentiation within services architecture

http://www.research.ibm.com/wsla/


•Thank You!

• eden.dei.uc.pt/~pnf

• [email protected]

http://www.eden.dei.uc.pt/~pnf


Broker OverheadBroker Overhead

• The Broker overhead varies with options

• Typically it varies between 2% and 10%

extensible contract broker for performance...

Documents