This dissertation presents a novel approach to enable tunable tradeoffs between performance and consistency for geographically replicated cloud services. The end goal of the approach is to have a solution by which replication is able to improve the overall performance of the system while inconsistency due to optimistic message delivery is bounded in both time and space. We achieve the latter goal with an eagerly executed commit layer that detects and solves conflicts in parallel with the optimistic replication layer.We believe such a solution not only solves the performance bottleneck of replicated services but also enables a full spectrum of tunability which will further allow applications to choose the best strategy to balance the tradeoff between performance and consistency for their replicated services. The new solution differs from the traditional eventual consistency model by providing a capability to solve conflicts in an online manner and to leverage the explicit role of clients in specifying the consistency requirements.Experiments on a prototype system in a real cloud environment are described, that show that the Client Oriented Layered Optimistic Replication (or COLOR) is feasible, and which evaluate the achievable tradeoffs between performance and consistency on a realistic example system under load, distributed over five replicas in two continents. The prototype shows that COLOR provides a well defined programming model to assist application developers to control the replication of their cloud services without resorting to the otherwise non-guarantee eventual consistency model in face of performance challenges. iv network 7) Server with offline apps/clients · State/cache are versioned · Require state merge for updating server state network 6) Server with middleware clients · Middleware software interacts with server on behalf of clients · E.g. session layer for 4) or 5) network 5) Server with stateful thick clients · Explicit caching and client state model user network 4) Server with stateful thin clients · Active state update, i.e. server-push · Limited client computation and caching user network 3) Server with remote stateless clients · Passive update of the server state on client · Clients reduced to extended "monitors" · E.g. browsers in 90's user network 0) Pure server 1) Server with monitor/operator1. Global commit layer backed by a consensus algorithm.
Whiteboard applicationThe web-based whiteboard client application is designed to be run from the Chrome browser, mostly in order to access the browser's internal measurement APIs. The whiteboard application uses a fixed-sized canvas to generate the client message traffic to the server. A robot is created on each emulated client to produce client messages; i.e., drawing actions, at a constant rate in order to measure the mean response time and other metrics at steady state.The whiteboard session layer has a public API for implementing non web based clients.We use this API to create a header-less client program so that it can be run from Google's ...