Thread.currentThread().join() » Terracotta

Terracotta Toolkit – Part 4 (Clustered Barrier)

ashish — Thu, 17 Feb 2011 08:53:05 +0000

Recently I had a need to coordinate test drivers across JVM's, so that they all fire the load at the same time. There were many options, needed flexibility in terms that each had its own warm-up time and other dependencies. Terracotta's Clustered Barrier was a natural choice for this. Reason's were simple, I had already seen it working and it was simple enough to integrate it within application.

What you need to run this sample
1. Terracotta Release Download here
2. Include terracotta-toolkit-1.1-runtime-2.1.0.jar in classpath. You can find the jar in terracotta_install/common folder

The image below describes the scenario

Scenario

Lets see how we use the Toolkit barrier to achieve this

public class ClusteredBarrierSample {
    static final String BARRIER_NAME = "RUN_BARRIER";

    Barrier barrier;

    // Handle to the toolkit
    ClusteringToolkit clusterToolkit = null;

    public void initializeToolKit(String serverAdd, int barrierParties) {
        clusterToolkit = new TerracottaClient(serverAdd).getToolkit();
        barrier = clusterToolkit.getBarrier(BARRIER_NAME, barrierParties);
    }

    /**
     * waits till all the parties have joined and once all drivers are ready
     * fires the test
     */
    public void fireTest() {
        try {
            barrier.await();
            // fire my network drivers
            System.out.println("firing the driver");
        } catch (Exception e) {
            e.printStackTrace();
       }
    }

    public static void main(String[] args) {
        ClusteredBarrierSample barrierSample = new ClusteredBarrierSample();
        barrierSample.initializeToolKit(args[0], Integer.parseInt(args[1]));
        barrierSample.fireTest();
    }
}

The implementation is straight simple and in 3 steps
1. Intialize Terracotta Client
2. Get the Barrier, with number of parties to wait for
3. Call await() on the barrier

Using it was pretty simple and took less than 5 minutes to have the requirements met

Next Steps:

Refer Terracotta Documentation

Getting Started with Terracotta Toolkit – Part 3 (Clustered Map)

ashish — Tue, 17 Aug 2010 11:40:29 +0000

Did you ever wanted to have a Map which can be clustered across JVM, without doing much work for replicating data, ensuring coherence of data? Terracotta Toolkit allows you to fullfill your dream, Use the same Map API's you have been using for long and see your data being clustered transparently with Terracotta. The fun begins, when you add new clients and they have the data with them without any additional programming.

Lets start with some general information about Toolkit. Refer Toolkit javadoc for more details here

Pre-requisite

Download Terracotta 3.3.0 from Download page

Include following terracotta-toolkit-1.0-runtime-1.0.0.jar into your classpath for using Toolkit. The jar is present inside Terracotta_Install_dir/common folder.

You can spend some time reading the following posts on Toolkit, although they can be read in any order

Lets explore a bit what do we achieve when we say Clustered Map

Unclustered Map

As you can see in the figure above, we have different JVM's, each having a Map instance used by Application. Now if we were to share the same instance across app's running in different nodes, we would have to write a lot of infrastructure code to replicate data, keep data coherent etc.

Clustered Map

The figure above depicts a Clustered Map. The Map instance is visible to App's across JVM's as if they are accessing a local instance. You can achieve this in a few lines, without worrying about the infrastructure code. Lets see how we can achieve this in few simple steps.

Steps to creare Clustered Map

Initialize Toolkit

Get a Map reference

Use the Map

Initializing the Toolkit

Before any operations can be performed using Toolkit, it needs to be initialized first. The initialization code is very simple, just single line

ClusteringToolkit clustering = new TerracottaClient("localhost:9510").getToolkit();

This line initializes the Terracotta Client and gets an instance of Toolkit to work with. The argument passed to the TerracottaClient is the IP Address and Port of the Terracotta Server.

Have created a simple function for initialization of the Toolkit.

ClusteringToolkit clusterToolkit = null;

public void initializeToolKit(String serverAdd) {
clusterToolkit = new TerracottaClient(serverAdd).getToolkit();
}

Get/Create the Map

public void initializeMap() {
    clusteredMap = clusterToolkit.getMap(MAP_NAME);
}

The code above creates a Clustered Map. There is no more infrastructure code that you have to write. This gives us a Clustered Map reference. The best part is, there are no new API's to be learned, we continue to use the same old Map API's.

Let's see the data class that we would share across the Map.

public class SharedData implements Serializable {

    private String data;

    public SharedData(String data) {
        this.data = data;
    }

    public String getData() {
        return data;
    }

    public void setData(String data) {
        this.data = data;
    }
}

Its a no-brainer class. Just a simple class for demonstration purpose.

Just to keep life simple, we are going to create a function which populates the Map, and the Nodes can then consume the populated data. Consume here would mean just call a get() and print. In real life scenario, you can mutate the data, and the updated data shall be visible across the cluster.

Lets see the populate function

protected void populateMap(int objectCount) {
        for(int i = 0; i < objectCount; i++) {
            SharedData data = new SharedData(""+i);
            clusteredMap.put(i, data);
        }
    }

Its a simple function which just puts the data in the Map.

Lets look at the consume function

 protected void consumeMapData(int maxObjectId) {
        Range range = new Range(1, maxObjectId);
        while(true) {
            long key = range.getRandomKey();
            byte[] dataBytes = clusteredMap.get((int)key);
            System.out.println("Key = "+key);
            if(dataBytes == null) {
                System.out.println("OOPS!.. somethings wrong dude...");
                return;
            }
            SharedData data = (SharedData)deserializeObject(dataBytes);
            if(data != null) {
                System.out.println("Data = "+data.getData());
            }
            try {
                // Sleep for 5 secs
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

The function just takes a random key and call a get on the map.

To run this implementation, we would have 3 Nodes running, 1 producer and 2 consumer. The picture below gives an idea of the topology.

Runtime Topology

To run the implementation

Start Terracotta Server

Start Producer

Start one or more Consumer

You can get the complete source of the sample here

Getting Started with Terracotta Toolkit – Part 2 (Cluster Events)

ashish — Mon, 09 Aug 2010 07:52:58 +0000

In the last post we saw Terracotta toolkit Queue. In this Part, lets explore Cluster Events. Cluster Events are propagated across the Terracotta Cluster, whenever specific event happens inside the Cluster. In this post we shall explore what are the different types of Events available.

Cluster Events

As of 3.3.0, following are the four Events that are available

Node Joined
Node Left
Operations Enabled
Operations Disabled

So what do we need to do, in order to receive these events? Just two simple steps

Implement ClusterListener
Register the Listener with toolkit

Pre-requisite

Download Terracotta 3.3.0 from Download page

Include following terracotta-toolkit-1.0-runtime-1.0.0.jar into your classpath for using Toolkit. The jar is present inside Terracotta_Install_dir/common folder.

Implementing ClusterListener

Here is the code

class MyClusterListener implements ClusterListener {

        public void nodeJoined(ClusterEvent clusterEvent) {
            try {
                System.out.println("Event Type = "+clusterEvent.getType());
                System.out.println("Node Joined "+clusterEvent.getNode().getId()
                        + ", IP="+clusterEvent.getNode().getAddress());
            } catch (UnknownHostException e) {
                e.printStackTrace();
            }
        }

        public void nodeLeft(ClusterEvent clusterEvent) {
            try {
                System.out.println("Node Left "+clusterEvent.getNode().getId()
                        + ", IP="+clusterEvent.getNode().getAddress());
            } catch (UnknownHostException e) {
                e.printStackTrace();
            }
        }

        public void operationsEnabled(ClusterEvent clusterEvent) {
            System.out.println("Operations Enabled");
        }

        public void operationsDisabled(ClusterEvent clusterEvent) {
            System.out.println("Operations Disabled");
        }
    }

As you can see, the implementation is pretty simple. Now its time to register the listener

ClusterInfo clusterInfo = clusterToolkit.getClusterInfo();
clusterInfo.addClusterListener(new MyClusterListener());

Get the complete code here

Time to see the implementation in Action

Start Terracotta Server
Start the Listener
Start/Stop Terracotta Clients and see the events being received

There can be some innovative things that can be done inside the ClusterListener. For ex, you can send SNMP Traps to your management system for nodeJoined or nodeLeft events.

Stay tuned for more on Terracotta Toolkit...

Looking for more details, you find them here

Terracotta Documentation

Terracotta Toolkit Javadoc

Getting Started with Terracotta Toolkit – Part 1

ashish — Mon, 02 Aug 2010 10:09:55 +0000

Terracotta Toolkit was released as part of Terracotta 3.3.0. The Toolkit is a delight for developers working on Scalable Apps, Frameworks. For more details on features of Toolkit, refer this link.
In this post we shall work out a few samples using the Toolkit. We shall start with looking at Cluster Events, Clustered Queues and move to clustered Locks.

Lets start with some general information about Toolkit. Refer Toolkit javadoc for more details here

Pre-requisite

Download Terracotta 3.3.0 from Download page

Include following terracotta-toolkit-1.0-runtime-1.0.0.jar into your classpath for using Toolkit. The jar is present inside Terracotta_Install_dir/common folder.

Initializing the Toolkit

Before any operations can be performed using Toolkit, it needs to be initialized first. The initialization code is very simple, just single line

ClusteringToolkit clustering = new TerracottaClient("localhost:9510").getToolkit();

This line initializes the Terracotta Client and gets an instance of Toolkit to work with. The argument passed to the TerracottaClient is the IP Address and Port of the Terracotta Server.

Have created a simple function for initialization of the Toolkit.

ClusteringToolkit clusterToolkit = null;

public void initializeToolKit(String serverAdd) {
clusterToolkit = new TerracottaClient(serverAdd).getToolkit();
}

Playing with Toolkit Queue

Toolkit provide various Data structures that you can use, Queue being one of them.

Lets try and create a Producer-Consumer sample, using Toolkit Queue. Here is what we are trying to do

We have a producer which is going to produce some work, and the consumer shall process the work in different JVM's.

To achieve we need to do the following

Create a Work object which shall be pushed by Producer to consumers.
We need to create a Producer that shall produce the work
We need to create a Consumer which shall consume the work. We can have multiple instances of Consumers

Lets have a look at Work Object

class Work implements Serializable, Runnable {
private String workItem;

Work(String workItem) {
this.workItem = workItem;
}

public String getWorkItem() {
return workItem;
}

public void setWorkItem(String workItem) {
this.workItem = workItem;
}

public void run() {
System.out.println(Thread.currentThread().getName() + "processing - "+getWorkItem());
}
}

NOTE: The Objects that shall be pushed onto the Queue should implement Serializable.

What we have done here. Its a very simple implementation, where we just print what the Producer pushed.
Implementing Runnable is not necessary. I just added it so that I can push the work unit directly to an Executor

Creating Producer


static final String QUEUE_NAME = "DATA_QUEUE";

public void startProducer(int capacity) {
BlockingQueue queue = clusterToolkit.getBlockingQueue(QUEUE_NAME, capacity);
System.out.println("Starting Producer....");
int i = 0;
while (i < capacity) {
queue.add(serializeObject(new Work(""+i++)));
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}

Creating a clustered Queue is a one line job. We have already initialized the Toolkit, now we just call getBlockingQueue() API from the toolkit, and we get a Distributed Queue backed by Terracotta
After creating the Queue, we keep on adding work to the queue till its capacity is reached.

Creating Consumer

public void startConsumer(int capacity) {
BlockingQueue queue = clusterToolkit.getBlockingQueue(QUEUE_NAME, capacity);

// Lets add some threads to consumer
ExecutorService executors = Executors.newFixedThreadPool(5);

// a dumb way for a loop
while(true) {
try {
executors.execute((Work)deserializeObject(queue.take()));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}

Aha! no difference in creation, the only difference is our Consumer calls take() API on the Queue to consume the work objects. Here we have a fixed size Thread pool that keep consuming the work that the producer is pushing.

This is it. Our implementation is complete We are ready to run the sample. To execute we need to do three steps

Start Terracotta Server
Start Producer
Start one or more Consumers

See them in action yourself.

The complete code can be found at http://code.google.com/p/terracotta-samples/

Some ideas around what can we do with Distributed queue
1. Distributed SEDA stages across JVM's
2. Distributed Task processing
... add your own ideas..

Would be interested in knowing what you do around Terracotta Toolkit Queue. Please do add comments with your implementations.

What's Next?

In the next post we shall be exploring more about the Cluster Events as part of Terracotta Toolkit.

Caching and Database Offloading – Best of both worlds with Terracotta Darwin Release

ashish — Wed, 24 Mar 2010 11:20:41 +0000

Abstract

The Terracotta Darwin release a feature packed release. I love to call it a Developer's delight. Integrating Terracotta with existing apps has been simplified a lot with Express Mode. In this series we shall see some touch upon some of the new features of the Darwin release

How is this post organized?

We shall take a sample Use Case(s), and discuss the needs. Using the Use Case we shall see the fitment of Terracotta features. Discussion will be around the following

Bulk Loading to Cache
Write Behind Cache

The Use Case - Bulk Loading

Bulk loading the cache is a common need for Cache warmup. Here we try to load the data into Cache in a single go, rather then on Cache miss. This help us in reducing the database lookup upon each miss.

Some Use Cases
Case 1: For a Catalogue site, loading all the available catalogues/Products during startup

The cache can be loaded at the startup with the hot set o Products or as desired, against loading it at runtime, upon a Cache miss.

Case 2: For an Element Management System, loading all the Managed Devices into cache, available to all nodes in the cluster

For an EMS Device Information for the Devices it is managing is used most often. The Device info can be bulk loaded at the startup. The example show the use of cache by a Poller, which Polls the Device status.

There are other common use cases. Please add comment with your Use case.

Ehcache Bulk Loading with Terracotta

Terracotta Darwin release has optimized bulk loading in Ehcache. In normal scenario, loading elements in Ehcache, would update the cache entry to all the clustered caches, making the bulk loading a bit slower.

Let's see how bulk loading in action

// Get the Cache to be preloaded Cache ehcache = CacheManager.getInstance().getCache("mycache"); // Set this property before bulk loading ehcache.setNodeCoherence(false); // Load everything here loadCache(); // reset the property ehcache.setNodeCoherence(true); // Wait for all data to be distributed across cluster ehcache.waitUntilClusterCoherent();

What's being done inside the loadCache()?
Here is a glimpse

private void loadCache() { // Query the DB get the data and get the result into array // or what ever data structure you need // iterate over result and put into cache for(int i = 0; i < data.length; i++) { Element element = new Element(data.getId, data); ehcache.put(element); } }

Here is how the cache look when we are bulk loading the data. We are using both nodes to load distinct data to speed up loading process. The loading can be taken care by a single node also.

Once the bulk loading is completed, and Nodes are set to coherent again, the data is replicated across the cluster, and all Nodes have the same data set.

What's Next?
In the next post we shall cover the Write-Behind feature of Ehcache for DB offloading. I will rewrite the code of one my previous post Exploring Terracotta tim-async - Scalable way to off-load DB updates from App Transaction, to use the write-behind feature.

So you want Distributed, Scalable and Highly Available Cache?

ashish — Tue, 09 Feb 2010 09:22:53 +0000

Abstract

So you want Distributed, Scalable and Highly Available Cache? If yes, then this is the right place for you. The Terracotta Ehcache release has these features inbuilt. The Express Installation mode has simplified Terracotta integration in your application.

How this post is organized
First we shall start with simple standalone cache and then see how Terracotta can easily help us create a Distributed, Scalable and Highly Available cache, with a few minor configurations

What all do you need run the example?

Terracotta 3.2.0 - Download it from here

Sample Application
Lets design a sample application (a real simple one), which we shall use to demonstrate the features. Device Monitoring is a common requirement in OSS System, and caching the Device information reduces the Database hits. The essential components of our application are
- DevideInfo - A POJO that stores device information
- CacheHandler - Class that handles cache initialization and other ops

Lets see the CacheHandler class, which is the heart of our implementation

public class DeviceInfo implements Serializable { String deviceId; String name; // .... other device information public String getName() { return name; } public void setName(String name) { this.name = name; } public String getDeviceId() { return deviceId; } public void setDeviceId(String deviceId) { this.deviceId = deviceId; } }

The class is simple and contains information related to the device.

Let see our CacheHandler class

public class CacheHandler { public Cache deviceCache; public void initCache() { // Initialize the CacheManager CacheManager cacheManager = CacheManager.create(); // Get the Cache to store device information deviceCache = cacheManager.getCache("deviceCache"); } public void addToCache(DeviceInfo device) { Element el = new Element(device.getDeviceId(), device); deviceCache.put(el); } protected int getDeviceCacheSize() { return deviceCache.getSize(); } public static void main(String[] args) { CacheHandler handler = new CacheHandler(); handler.initCache(); // Lets add 10 devices // just to keep life simple for(int i = 0; i < 10; i++) { DeviceInfo device = new DeviceInfo(); device.setDeviceId("Device-"+i); handler.addToCache(device); } // Not recommended in production System.out.println("Cache Size = "+handler.getDeviceCacheSize()); } }

The class has two main functions
- initCache - The API initializes the cache
- addToCache - The API adds the device information to the device cache

Lets see our ehcache.xml

In the configuration we have defined a deviceCache, that we shall use to store device information.

Following is the list of jars you would need to run this app

ehcache-core-1.7.2.jar

slf4j-api-1.5.8.jar

slf4j-jdk14-1.5.8.jar

All these jars are available as part of Terracotta installation under /distributed-cache directory

You can run this example and see the same in action.

Making it Distributed....

Now lets assume that we want to make the Cache fault tolerant, survive JVM crashes, as well as have it available on different JVM's. It should be able to Scale as we add more JVM's to it and other stuff. With Terracotta, we can just do it in a few steps without changing the code. the magic lies with Express Installation mode, introduced in Terracotta version 3.2.0 and above

Lets see the 3 steps that we need to perform

1. Updates to the ehcache.xml
Add following element to ehcache.xml

and for the deviceCache, we add element

here is the updated ehcache.xml

There is no need to change the code

2. Add ehcache-terracotta-1.8.0.jar to the classpath

Lets start the Terracotta Server

3. Goto Terracotta_Install_dir/bin and execute

$ ./start-tc-server.sh

This shall start the Terracotta server

Now run the application on multiple JVM's. The device information is available on all client JVM's

To monitor Cache, you can use Terracotta Dev Console

If you have further question/queries, please visit Terracotta Forums.

What's coming up Next?
The next post shall touch on write-behind feature in the latest Terracotta Darwin release. Its essentially to get best of both worlds - Caching and Database Offloading Stay tuned..

Exploring Terracotta tim-async – Scalable way to off-load DB updates from App Transaction

ashish — Mon, 25 Jan 2010 14:59:15 +0000

Lets start this chat with a small conversation

Manager: What are the options we have to increase the TPS of our SMSC Server?

Architect: Can you elaborate a bit on this?

Manager: As of now we process a request and update the Database in the same tranaction. Essentially, we are operating our Server at the TPS at which our DB can operate.

Architect: Well we have to ensure that our Data is persisted

Manager: Yes, but can't we update the DB asynchronously, without lossing data

Architect: Yes it can be done, but we have to create a lot of infrastructure code around this, so that we don't loose data for failed transaction, process crashes etc.

If you have been in such a situation, the post is meant for you.

Summary

For any request, don't update the Database in same transaction, but data need to be persisted. This has always been a typical need to increase the liveliness of the application. The application accessing data in memory work must faster, than fetching/updating data form databases. Assume you have a solution which helps you to work in memory and allows your application to update the data to Datastore in separate transaction, providing HA and Scalability out of the box. If this is what you are looking at, Terracotta async processor (tim-async) is the right fit for you.

The article is organized to detail what tim-async is, followed by a sample application.

We shall see tim async in brief and then later would walk through the a small POC that I build around the same.

Pre-requisite

You should have basic understanding of Terracotta 3.2 and its Configuration.
You need to download tim-async using tim-get tool

What is tim-async?

tim stands for Terracotta Integration Module, and tim-async is module for asynchronous processing. tim-async provides a scalable, high performance way to asynchronously write the business data to data source (typically a database), while the application works on in-memory data structures. Decoupling the main processing from the underlying database decreases the write latency of domain objects, while high availability of data is provided by terracotta.

What features does it have

Multithreaded write behind to flush the processed data from the client VMs (L1s) to the data source

Data to be flushed remains highly available (HA) as it is shared with terracotta.

Every client takes the responsibility of writing its data set to the data source

Listeners to monitor work progress at bucket level.

NOTE: Have pulled out this information from the attachment here

Building Blocks of tim-async from User Perspective

From a User's POV, these three are the important building blocks

ItemProcessor

AsyncCoordinator

AsyncConfig

These are all classes/interface that are part of tim-async. Lets look at them in brief

ItemProcessor

Its an interface and the implementation class of this interface is where we shall be writing the actual processing logic of the Domain Object, like persisting it to the DB.

public interface ItemProcessor { public void process(I item) throws ProcessingException; }

AsyncCoordinator

Its a core class and need to be declared as Shared Root in tc-config.xml. It allows work to be added and processed asynchronously.
The class has a method start() that needs to be called by every client node (Terracotta L1) to participate in processing.
An ItemProcessor instance is local to the node, so its the right place to hold stuff DB Connection etc

AsyncConfig

Its an interface and can be implemented to custom tailor the configuration of Async processing. If we don't define one, the org.terracotta.modules.async.configs.DefaultAsyncConfig is used.

public interface AsyncConfig { public long getWorkDelay(); public long getMaxAllowedFallBehind(); public boolean isStealingEnabled(); }

Now lets see how can we implement tim-async in our application (We shall see the sample application)

- We need to implement ItemProcessor for doing custom processing say for example putting the stuff in DB
- We need to initialize AsyncCoordinator and call start() API, pass on the ItemProcessor from previous step as a param.
- Create tc-config.xml (pick teh sample from tim-async example), add the AsyncCoordinator field instance as the root
- Start TC Server and Client JVM's with tc-config.xml created above

Lets see these steps in Action.

Sample Application

I had written a SMSC simulator based on jsmpp which used to receive the SubmitSM request from Client, used to persist in the DB and return
the id to the client. There is a specific reason why I choose this application. I already had this running and since the SubmitSM just needed to persisted in DB for subsequent processing by other process. The business case was justified that the Server is very responsive to Client, as well as its ensured that the Data is persisted.

Lets walk through the a simple processing sequence

Client send a SubmitSM request

Server translated it into an internal SMS POJO, assigns a unique ID to the SMS

Server persists the SMS in Database

Sever sends the ID generate as part of SubmitSM response

The application uses Hibernate to save the POJO in MySQL Database.

Since the Domain object is least significant so won't discuss the internals of SMS POJO

Lets see how we enhanced the application to asynchronously update the DB

Implementing the ItemProcessor

public class AsyncSMSProcessor implements ItemProcessor { public void process(final SMS sms) throws ProcessingException { Session hibernateSession = DAO.getSession(); DAO.getSession().getTransaction().begin(); DAO.getSession().save(sms); DAO.getSession().getTransaction().commit(); } }

Essentially what we have to write the logic of saving the SMS object to the database. This is the object that Terracotta is going to pass back to us.
What we do here is save the SMS in a Hibernate transaction. This completes out ItemProcessor code

Initialize AsyncCoordinator

public class SMSProcessor { public AsyncCoordinator asyncUpdator; public SMSProcessor() { asyncUpdator = new AsyncCoordinator(); // Use the default API asyncUpdator.start(new AsyncSMSProcessor()); } }

public long processIncomingSMS(SubmitSm submitSm, SMPPServerSession source, ...) { // some logic here // give the date to AsyncCoordinator asyncUpdator.add(sms); // some logic there }

This is the change that we have done here. Earlier we used to save the SMS in DB here. We have now given the data to AsyncCoordinator for subsequent processing.

Let's look at the tc-config.xml

this is what we need to add to the tc-config.xml

com.tc.timasync.demo.smsAsyncCoordinator

We declared the AsyncCoordinator variable as DSO root here, which makes it shared across cluster.

That's it.

We are ready. Now we start Terracotta server with our tc-config file and start our SMSC Simulator as TC Client.

How does it all fit together

As we see the instead of updating the DB in the same transaction, we handed the data over to Terracotta. Essentially, this meant that our data has gone to Server, and won't be lost against crashes. The application operated at memory speed and responded to client. The Terracotta Server based on the configuration of tim-async shall call the ItemProcessor in different transaction. We can have multiple nodes updating the DB asynchronously or some other way, based upon the Use Case.

Let's run the both the implementations

Note on Comparison of both the implementations

I shall run both the implementation on the same hardware/OS, which would be my Laptop with 2GB of RAM, runnning Windows and MYSQL 5.X. The comparison shall be relative for the two implementation approached, and not the absolute figures. The figures would be much better if the samples are run on higher end machined with Terracotta Server (L2) running on a dedicated machine and the Clients (L1) running on different machines. The idea here is just to see the TPS of the Server.

Case I: DB updates in App transaction

For 10 runs of sending 1000 SubmitSM request client took following time

Total Time for 1000 SMS = 28891
Total Time for 1000 SMS = 34234
Total Time for 1000 SMS = 27812
Total Time for 1000 SMS = 34547
Total Time for 1000 SMS = 29953
Total Time for 1000 SMS = 34344
Total Time for 1000 SMS = 33985
Total Time for 1000 SMS = 35328
Total Time for 1000 SMS = 36968

Case II: DB updates based on tim-async

Total Time for 1000 SMS = 1359
Total Time for 1000 SMS = 1125
Total Time for 1000 SMS = 781
Total Time for 1000 SMS = 813
Total Time for 1000 SMS = 750
Total Time for 1000 SMS = 719
Total Time for 1000 SMS = 703
Total Time for 1000 SMS = 719
Total Time for 1000 SMS = 718
Total Time for 1000 SMS = 735

There was a significant decrease in the processing time of request

What's next

Download Terracotta from here and try yourself. You can also register for upcoming Darwin release, which has many new interesting features

Resources

http://blog.terracottatech.com/2009/02/offloading_a_db_even_when_upda.html - A wonderful post by Ari

http://www.slideshare.net/sbtourist/real-terracotta-presentation

http://forums.terracotta.org/forums/forums/list.page

Essential Components of Terracotta based Application

ashish — Thu, 26 Nov 2009 07:40:23 +0000

Abstract

How does a Terracotta Application look like? What are the essential components that make up the application? These were the question I had after writing my first post “Getting Started with Terracotta”. Here I try to take a quick look at these questions from a Users point of view. Please note that this post doesn’t try to dive deep into Terracotta inner working.

Components of Terracotta based Application

To keep life simple, have considered the general application architecture, which essentially can be any Terracotta app. From the figure we can see that we have four different parts that contribute to a complete Terracotta app.

User Application – These are applications that want to use Terracotta to Scale. They can either use Terracotta transparently or can use explicit Terracotta API’s

Terracotta Server – It’s the nerve center. Terracotta applications can’t run without it. For running any TC application, it’s a must to run atleast one TC Server.

Terracotta config file – Also known as tc-config.xml (default name). It provides the detailed configuration for Server as well as Client. It contains information like Server’s IP’s, persistence mode, classes to instrument etc.

Terracotta Libraries – These are essentially part of Client or User applications. They are the work horses of the running application and enables Terracotta integration with User application. An example would be dso-java.bat script adds the Terracotta bootjars to the classpath, enabling Terracotta features for the application.

So how does it all fit together at runtime

Start Terracotta Server, providing a configuration file with desired configuration

Start User Application using dso-java.(bat|sh) instead of normal java, along with a configuration file

That’s it