Scaling Javabased Dynamic Web Services

1
Scaling Java-basedDynamic Web Services
Sara Sprenkle Committee Jeff Chase
Carla Ellis Amin Vahdat January 17, 2001
2
Scaling Java-based Dynamic Web Services

• Dynamic web services
• wide-area Internet applications
• written in Java
• want good performance ? scaling
• Scaling
• replicate the service
• What? When? Where?
• How? How Much?

3
Conventional Web Caches

• Web caches store recently-requested static
  content, e.g., html documents, gifs, and jpegs
• decreased client latency
• better fault tolerance
• better load balancing
• incremental scalability

Client
request
cache miss
Primary Server
Proxy Cache
Client
content
response
Client
4
Dynamic Content

• Web application servers provide personalized
  services
• create dynamic content by executing code (CGI,
  Java servlets) in response to client requests

Client
request
Client
response
Client
generate response
5
Service Caches

• Replicate primary servers Java service code and
  data at service cache
• Answered previous questions

updates
Primary Server
code
data
code
updates
6
Service Caches

• Can act as a cache for more than one service
• Partial replicas

Primary Server
Service Cache
code
data
updates
data
code
code
Primary Server
data
code
updates
data
code
code
7
Java-based Web Services

• Several applications (servlets) together provide
  a service

bank account service
data
8
Java-based Web Services Data

• Java objects linked by references
• Monitor object changes
• inject code into compiled servlet classes to make
  calls to service caching framework (JOIE)

service
9
Granularity

• Efficient data replication, synchronization
• partial replication (caching)
• tradeoffs in replication granularity
• too large ? false sharing, too many faults
• too small ? state management overhead
• need control over granularity

10
Conits Object Clusters

• Application-dependent object groupings
• Granularity for synchronization and update
  propagation
• Membership - automatic and appropriate for
  application
• Global naming

11
Conits/Object Clusters a closer look
conitid nodeid node_unique_id ? globally
unique id
4
7
8
Conit Root ingress point into cluster
0
5
2
6
1
reference to other clusters
ConitObject objects that can belong to a conit,
identified by a unique id within the conit

12

Example setting up a service cache
On harpo
Service s ServiceManager.registerService(
example ) s.registerPrimary(
groucho.cs.duke.edu )
primary groucho 100
secondary harpo 170
Primary Server
updates
code
data
code
13
Example 1 cluster creation
List list new List( 2 ) list.startNewConit(
) Naming.bind( list, spartacus )
Node id 100 groucho
14
Example 2 cluster update
List newList new List( ) newList.attach( list
) list.append( newList )
spartacus
1
0
Add objects to conits without worrying about
naming conflicts
2
3
Node id 100 groucho
15
Example 3 cluster management
spartacus
1
0
A
B
2
C
D
Node id 100 groucho
16
Example 3 cluster management

• Fault on spartacus
• Lazy add objects are added to the conit only
  when requested for replication

Conit id 100001
spartacus
1
0
A,3
B,4
2
C,5
D,6
Node id 100 groucho
17
Example 4 cross-conit reference
Conit id 100001
Conit id 100002
spartacus
0
0
1
Node id 100 groucho
18
Example 4 cross-conit reference

• Fault on spartacus
• Primary sends the transitive closure of the
  desired object(s)
• Stop propagation when reach a cross-conit
  reference

Conit id 100001
Conit id 100002
spartacus
0
0
1
Node id 100 groucho
19
Example 4 cross-conit reference

• List list Naming.lookup( spartacus )
• list.printList()

Conit id 100001
spartacus
0
100002 0
1
Node id 170 harpo
20
Example 4 resolving cross-conit reference

• Automatically adds objects to cluster

Conit id 100002
Conit id 100002
1
0
0
2
Node id 100 groucho
21
Example 4 complete replica

• List list Naming.lookup( spartacus )
• list.printList()

Conit id 100001
Conit id 100002
spartacus
1
0
0
2
1
Node id 170 harpo
22
Discussion of Examples

• On-demand replication of application data
  structures
• Cluster management
• specify conit membership for subset of objects
  (ConitRoots)
• automatically assign membership of other objects
• lazy addition (only when propagating updates)

23
Ivorys Service Cache
Service
NameCache
table of objects and their symbolic names
NodeManager
table of node locations and ids
StateManager
table of clusters/conits and ids
application threads running in the context of a
service
24
What next?

• Debugging code
• Testing different synchronization and consistency
  policies
• plug-in policies in locally-minimal parts of
  system
• Develop realistic test applications
• Evaluation of performance

25
Ivory Overview

• Extension to conventional web proxy caches
• Data-sharing layer used to replicate web services
• Goals
• consistent
• fast
• minimize overhead of state management
• minimize application programmers burden
• work with existing services
• scale with more replicas

26
Service Manager
27
Example cluster update
List itemA new List( 1 ) itemA.attach( list
) list.insert( itemA, 0 )
Conit id 100001
spartacus
0
null
1
Node id 100 groucho
28
Example another cluster update
List itemB new List( ) itemB.startNewConit(
) itemB.buildList( 2 ) list.insert( itemB, 1 )
Conit id 100001
Conit id 100002
spartacus
0
0
1
Node id 100 groucho
29
Example fault by name
List list Naming.lookup( spartacus )
NameCache
no entry for spartacus, try primarys
(grouchos) name cache
Node id 170 harpo