l12 session state and distributation strategies

63
Lecture 13 Session State and Distribution Strategies

Upload: olafur-andri-ragnarsson

Post on 01-Nov-2014

446 views

Category:

Technology


0 download

DESCRIPTION

One of the most critical design decisions on enterprise programming is where to keep the state. As we talked about in the lecture on Concurrency, session state is the state that is maintained between requests. A session starts when the user first hits the enterprise system, and lasts until the user signs out or times out. In this lecture we look at the session state and explore three design patterns on where to store the session state. The second topic in this lecture is how to distribution the applications. The primary reason we want to do that is to get more performance and handle more load. Most enterprise applications have lots of users, some hundreds of thousands. The only way to cope with such load is to scale the application. Scalability is how much more load an application can take if more resources are added. We will look at two ways to scale, one is by load balancing and the other by clustering. Video of this lecture are found here: http://www.olafurandri.com/?page_id=2762

TRANSCRIPT

Page 1: L12 Session State and Distributation Strategies

Lecture 13Session State and Distribution Strategies

Page 2: L12 Session State and Distributation Strategies

Session State

Page 3: L12 Session State and Distributation Strategies

Reading Fowler 6– Session State

Fowler 17– Session State Patterns

Page 4: L12 Session State and Distributation Strategies

Agenda Session State– Business transactions

Session State Patterns– Client Session State– Server Session State– Database Session State

Page 5: L12 Session State and Distributation Strategies

Business Transactions Transactions that expand more than one

request– User is working with data before they are

committed to the database• Example: User logs in, puts products in a shopping

cart, buys, and logs out– Where do we keep the state between

transactions?

Page 6: L12 Session State and Distributation Strategies

State Server with state vs. stateless server– Stateful server must keep the state between

requests Problem with stateful servers– Need more resources, limit scalability

Page 7: L12 Session State and Distributation Strategies

Stateless Servers Stateless servers scale much better Use fewer resources

Example:– View book information– Each request is separate

Page 8: L12 Session State and Distributation Strategies

Stateful Servers Stateful servers are the norm Not easy to get rid of them

Problem: they take resources and cause server affinity

Example:– 100 users make request every 10 second, each

request takes 1 second– One stateful object per user– Object are Idle 90% of the time

Page 9: L12 Session State and Distributation Strategies

Session State State that is relevant to a session– State used in business transactions and belong

to a specific client– Data structure belonging to a client– May not be consistent until they are persisted

Session is distinct from record data– Record data is a long-term persistent data in a

database – Session state might en up as record data

Page 10: L12 Session State and Distributation Strategies

Question:Where do you store the session?

EXCERISE

Page 11: L12 Session State and Distributation Strategies

Ways to Store Session State We have three players– The client using a web browser– The Server running the web application and

domain– The database storing all the data

Page 12: L12 Session State and Distributation Strategies

Ways to Store Session State Three basic choices– Client Session State (456)– Server Session State (458)– Database Session State (462)

Page 13: L12 Session State and Distributation Strategies

Client Session StateStore session state on the client

How It Works– Desktop applications can store the state in

memory– Web solutions can store state in cookies, hide it

in the web page, or use the URL– Data Transfer Object can be used– Session ID is the minimum client state– Works well with REST

Page 14: L12 Session State and Distributation Strategies

Client Session State When to Use It– Works well if server is stateless– Maximal clustering and failover resiliency

Drawbacks– Does not work well for large amount of data– Data gets lost if client crashes– Security issues

Page 15: L12 Session State and Distributation Strategies

Server Session StateStore session state on a server in a

serialized form

How It Works– Session Objects – data structures on the server

keyed to session Id Format of data– Can be binary, objects or XML

Where to store session– Application server, file or local database

Page 16: L12 Session State and Distributation Strategies

Server Session State Specific Implementations– HttpSession– Stateful Session Beans – EJB

When to Use It– Simplicity, it is easy to store and receive data

Drawbacks– Data can get lost if server goes down– Clustering and session migration becomes

difficult– Space complexity (memory of server)– Inactive sessions need to be cleaned up

Page 17: L12 Session State and Distributation Strategies

Database Session StateStore session data as committed data in the

database

How It Works– Session State stored in the database– Can be stored as temporary data to distinguish from

committed record data Pending session data

– Pending session data might violate integrity rules– Use of pending field or pending tables

• When pending session data becomes record data it is save in the real tables

Page 18: L12 Session State and Distributation Strategies

Database Session State When to Use It– Improved scalability – easy to add servers– Works well in clusters– Data is persisted, even if data centre goes

down Drawbacks– Database becomes a bottleneck– Need of clean up procedure of pending data

that did not become record data – user just left

Page 19: L12 Session State and Distributation Strategies

What about dead sessions? Client session– No our problem

Server session– Web servers will send inactive message upon

timeout Database session– Need to be clean up– Retention routines

Page 20: L12 Session State and Distributation Strategies

Caching Caching is temporary data that is kept in

memory between requests for performance reasons– Not session data– Can be thrown away and retrieved any time

Saves the round-trip to the database Can become stale or old and out-dated– Distributed caching is one way to solve that

Page 21: L12 Session State and Distributation Strategies

Practical Example Client session– For preferences,

user selections Server session – Used for browsing and

caching– Logged in customer

Database– “Legal” session– Stored, tracked, need to survive between

sessions

Page 22: L12 Session State and Distributation Strategies

We are building an application for processing development grants. The application is complicated and users can login any time and continue work on their application. What design pattern would we use for storing the session?

A) Client Session StateB) Server Session StateC) Database Session StateD) No state required

QUIZ

Page 23: L12 Session State and Distributation Strategies

Distribution Strategies

Page 24: L12 Session State and Distributation Strategies

Reading Fowler 7– Distribution Strategies

Fowler 15– Distribution Patterns– Remote Façade (388)

Page 25: L12 Session State and Distributation Strategies

Agenda Distributed Architectures– Remote and Local Interfaces– Where You Have to Distribute– Remote Façade

Scalablity DEMO

Page 26: L12 Session State and Distributation Strategies

Distributed Architecture Distribute processing by placing objects

different nodes

Page 27: L12 Session State and Distributation Strategies

Distributed Architecture Distribute processing by placing objects on

different nodes Benefits– Load is distributed between different nodes

giving overall better performance– It is easy to add new nodes– Middleware products make calls between

nodes transparent

But is this true?

Page 28: L12 Session State and Distributation Strategies

Distributed Architecture Distribute processing by placing objects

different nodes

“This design sucks like an inverted hurricane” – Fowler

Fowler’s First Law of Distributed Object Design: Don't Distribute your objects!

Page 29: L12 Session State and Distributation Strategies

Remote and Local Interfaces Local calls– Calls between components on the same node

are local Remote calls– Calls between components on different

machines are remote Objects Oriented programming– Promotes fine-grained objects

Page 30: L12 Session State and Distributation Strategies

Remote and Local Interfaces Local call within a process is very, very fast Remote call between two processes is order-of-

magnitude s l o w e r– Marshalling and un-marshalling of objects– Data transfer over the network

With fine-grained object oriented design, remote components can kill performance

Example– Address object has get and set method for each

member, city, street, and so on– Will result in many remote calls

Page 31: L12 Session State and Distributation Strategies

Remote and Local Interfaces With distributed architectures, interfaces

must be course-grained– Minimizing remote function calls

Example– Instead of having getters and setters for each

field, bulk assessors are used

Page 32: L12 Session State and Distributation Strategies

Example Sun Application Model– “The Canonical Architecture”

Entity Beans– Each bean maps to row in the database– find methods returns

Collection of Remote interfaces

Page 33: L12 Session State and Distributation Strategies

Example Result– Architecture that does not perform very well

Suggested solution was– Use session beans to call entity beans

Page 34: L12 Session State and Distributation Strategies

Distributed Architecture Better distribution model– Load Balancing or Clustering the application

involves putting several copies of the same application on different nodes

Page 35: L12 Session State and Distributation Strategies

Where You Have to Distribute As architect, try to eliminate as many

remote call as possible– If this cannot be archived choose carefully

where the distribution boundaries lay Distribution Boundaries– Client/Server– Server/Database– Web Server/Application Server– Separation due to vendor differences– There might be some genuine reason

Page 36: L12 Session State and Distributation Strategies

Optimizing Remote Calls We know remote calls are expensive How can we minimize the cost of remote

calls? The overhead is– Marshaling or serializing data– Network transfer

Put as much data into the call– Course grained call

Remote Façade

Page 37: L12 Session State and Distributation Strategies

Remote FaçadeProvides a coarse-grained facade on

fine-grained objects to improve efficiency over a network

The façade is a thin wrapper that provides coarse-grained interface to a system– In an object-oriented model, you do best with

small objects that have small methods– Can cause great deal of interaction between

objects and method invocations

Page 38: L12 Session State and Distributation Strategies

Remote Façade How It Works– Allows efficient remote access with coarse-

grained interface– Façade will use the fine-grained object to build

and return object like Data Transfer Object– Should not contain any domain logic

Page 39: L12 Session State and Distributation Strategies

Remote Façade When to Use It– Whenever you need remote access to fine

grained object model– Most common use is between UI and domain

model

Page 40: L12 Session State and Distributation Strategies

Remote Façade Remote method invocation are expensive– Performance killer

JVM

Entity

Entity

Session Entity

Session

ClientRMI

Page 41: L12 Session State and Distributation Strategies

Remote Façade Coarse grained interface

JVM

Client Entity

Entity

Session Entity

Session

RMILocal calls

RemoteFaçade

Page 42: L12 Session State and Distributation Strategies

Remote Façade Benefits– Net traffic is reduced– Transactions are closer to the database

Drawbacks– Limitations on object oriented programming– Solution is based on limitations of the network

Page 43: L12 Session State and Distributation Strategies

Interfaces for Distribution XML over HTTP is a common interface– XML is structured and allows for lot of data– XML is common format, well known– HTTP is common and esay to use

XML has overhead– Parsing and manipulation of strings is

expensive– Overhead if not needed

Approches like REST are more efficient– Use HTTP right

Page 44: L12 Session State and Distributation Strategies

Scalability

Page 45: L12 Session State and Distributation Strategies

Scaling the application Today’s web sites must handle multiple

simulations users Examples:– All web based apps must handle several users– mbl.is handles ~180.000 users/day– Betware must handle up to 100.000

simultaneous users

Page 46: L12 Session State and Distributation Strategies

The World we Live in Average number of tweets per day

58 million Total number of minutes spent on

Facebook each month 700 billion SnapChat has five million daily

active users who send 200 million photos per day.

Instagram has over 150 million users on the platform and1 billion likes happening each day

Page 47: L12 Session State and Distributation Strategies

Scalability Scalability is the measure of how adding

resource (usually hardware) affects the performance– Vertical scalability (up) – increase server

power– Horizontal scalability (out) – increase the

servers Session migration – Move the session for one server to another

Server affinity– Keep the session on one server and make the

client always use the same server

Page 48: L12 Session State and Distributation Strategies

Scalability Example

Page 49: L12 Session State and Distributation Strategies

Load Distribution Use number of machines to handle requests Load Balancer directs all

request to particular server– All requests in one session go

to the same server– Server affinity

Benefits– Load can be increased– Easy to add new pairs– Uptime is increased

Drawbacks– Database is a bootleneck

Page 50: L12 Session State and Distributation Strategies

Clustering Distributing components– Each node has one

component– Increased performance

is not guaranteed

Using cluster– Have all components

in each node and use local calls

Page 51: L12 Session State and Distributation Strategies

Clustering With clustering, servers

are connected togetheras they were a singlecomputer– Request can be handled

by any server– Sessions are stored on

multiple servers– Servers can be added and

removed any time Problem is with state

– State in application servers reduces scalability– Clients become dependant on particular nodes

Page 52: L12 Session State and Distributation Strategies

Clustering State Application functionality– Handle it yourself, but this is complicated, not

worth the effort Shared resources– Well-known pattern (Database Session State)– Problem with bottlenecks limits scalablity

Clustering Middleware– Several solutions, for example JBoss, Terracotta

Clustering JVM or network– Low levels, transparent to applications

Page 53: L12 Session State and Distributation Strategies

Scalability Example

Page 54: L12 Session State and Distributation Strategies

Measuring Scalability The only meaningful way to know about

system’s performance is to measure it Performance Tools can help this process– Give indication of scalability– Identify bottlenecks

Page 55: L12 Session State and Distributation Strategies

Example tool: LoadRunner

Page 56: L12 Session State and Distributation Strategies

Example tool: JMeter

Page 57: L12 Session State and Distributation Strategies

Which is true when you are clustering your application?

A) Make sure all requests goes to the same machineB) Deploy each component on separate machine to distribute

loadC) You try to minimize network traffic to avoid latency

problemsD) Deploy the whole solution on many machines

QUIZ

Page 58: L12 Session State and Distributation Strategies

Real World Examples: Betware Iceland Data Center

Page 59: L12 Session State and Distributation Strategies

ISP1 ISP2Hardware

firewall

Loadbalancer

16 port 2GbpsSAN switch

QLogic

12 x 300GBSAS 15K

24 x 300GBSAS 15K

IBM BladeChassis

Pair of eachserver on

separate blade

CMSDB

BackupSoftware

System DB

Page 60: L12 Session State and Distributation Strategies
Page 61: L12 Session State and Distributation Strategies
Page 62: L12 Session State and Distributation Strategies
Page 63: L12 Session State and Distributation Strategies

Summary Session State– Business transactions

Session State Patterns– Client Session State– Server Session State– Database Session State

Distribution Strategies– How to distribute