Capacity Planning - Series 1

Capacity planning is the exercise of determining the capacity required for the organization to meet the needs of the software application to in a cost effective manner so that the application performs within accepted and agreed Service Level Agreements. This science is not a precise science when done.

Im sharing my experiences in capacity planning through this series. When I started working on Capacity planning and took few books to read it, it was filled with lot of mathematical formulas to arrive at the numbers. So a warning note is that if you are interested in Capacity planning, you should be ready to deal with equations (yes, it can be solving linear equations, solving etc, which we have studied during our engineering courses).

There are two approaches of performing capacity planning.

Case i: If the application is not yet developed and implemented

Case ii: If the application is developed and we have a testing setup where the application can be subjected to test load.

In my working experience I have not done much of the case i and hence I would not be dealing with that section in detail. However you should be comfortable with the Utilization law and the queuing models to arrive at a good estimation.

This article will talk about how to proceed with capacity planning with situations that arise of Case ii.

Capacity Planning exercise will have to perform the following activities which will be required as Input to the calculation.

1. Workload Profile – The workload can be defined in terms of transactions for online processes and as processes for Batch Processing. For an online application, the workload can have the following information
1. Details about the user groups
2. Details about Peak load timing
3. Details about the various business transactions as well as its timing
4. Details about the non business requirements like backup, archiving etc..
5. Details about user locations.
2. Expected SLA – The expected SLA should be captured. You should always try to get quantitative figures instead of qualitative figures like “good”, “perfect” etc. The SLA should also be defined for Peak load timing too.
3. Future Growth – The growth pattern for the application as well as its usage should be collected. This will ensure that the application will function well in future and still meet the expected SLA.

Capacity planning exercise should have the following details as its output.

1. Servers – Brand, Numbers, Location, Distribution and Load Balancing details.
2. Disks – Stripping, Speed of the Disk, Capacity of Disks , Partitioning of Disks, Type of Disk (Clarion/Symmetrix)
3. CPU – Type (AMD/Intel etc), Speed, Cores, Memory Cache, Number.
4. Memory – Type, Amount, Expansion Slots, Max Memory.
5. Networks – Expansion Slots, Channels, Network Cards (Embedded NIC’s)

JSF Configuration Files

JSF being new to the developers, there are lot of questions arising as to where to place the JSF configuration files and also the order in which the files will be loaded by the system. Though the location is based on the JSF implementation, the standard approach that I have noticed is described below

1. The implementation will search for /META-INF/faces-config.xml in all the JAR files loaded from WEB-INF/lib directory. If the implementation finds any one faces-config.xml, the file will be loaded to be used by the application. If not, it will move to the next step as mentioned in Step 2.

2. If the files are not found in the above location, it will search for the javax.faces.application.CONFIG_FILES property in the web.xml file. The comma delimited names of the config files are given as the value for this property with the path from the root of the web application. This approach is to be used if different config files need to be loaded for the application which might happen when different modules are developed by different groups and they have all separate configurations file.

javax.faces.application.CONFIG_FILES

/WEB-INF/config1.xml, /WEB-INF/config2.xml

3. Finally the implementation will search for faces-config.xml adjacent to the WEB.xml file directly under the WEB-INF folder, if it cannot find even a single faces config file in any of the locations mentioned in Step1 and Step 2.

Transport Layer

In this blog I have tried to put across my idea of developing a clustered cache

Without a clustered cache implementation, it is difficult to implement a true Singleton object. The Object created in a particular JVM will not exist in any other JVM’s and hence the other JVM’s will create a different instance of the Singleton object. To avoid these issues in a clustered application, a clustered cache would turn out to be useful.

The idea behind a clustered cache is that the data created in one JVM should be copied to the other JVM’s. The synchronization of data between JVM’s should be the responsibility of the cache itself and transparent to the application. A sample component diagram is shown below. In this approach, application accesses the cache component in JVM1. The Cache component will interact with the Synchronization component in JVM1. The Synchronization component of JVM1 will transport the data using a transport layer. The synchronization component of JVM2 will receive data from the transport layer. Once the data is received by the Synchronization component in JVM2 it needs to update the local cache in JVM2. The synchronization component should implement the following features.

· Identifying instances when the data changes in the local cache.

· Initiate the transfer of cached data to the subscribed JVM’s.

· Ensure that the data is published to other subscribed JVM’s.

· Algorithm to effectively transport data like compressing, collating etc.

· Receive the cache data from other JVM’s.

· Update the local cache based on the data received from other JVM’s.

Some of the possible Transport Layers are described below.

· JMS – Java Messaging Services implementations can be used to transport the data. The disadvantage with this approach is that a transport layer needs to be added to the application framework like IBM MQ. This is definitely a cost addition to the application infrastructure. However in the later versions of Websphere Application Server, a embedded JMS implementation is provided which can be used as transport layer.

· IP Multicasting – Data can be transferred from one machine to other machine using socket connections. In this approach, SocketConnections and SokcetListeners should be developed which will be used to transport data. The disadvantage with this approach is that a particular port should be opened for the machine through which data can be transferred. This is considered as security risks in many bigger corporations.

· Remote Method Invocation – This is an approach where the data is transferred from one JVM to another JVM by using Remote Method Invocations. The marshalling and demarshalling algorithms should be developed for this implementation. The disadvantage with this approach could be the performance based on the network.

· EJB – Enterprise JavaBeans can be deployed in the JVM to transfer the data. This is very much similar to the RMI mode of transport except for the fact that marshalling and demarshalling will be automatically performed. The disadvantage with this approach is the necessity for an EJB Container. Hence the approach will not work on java processes implemented outside any J2EE container.

Pass by Reference still?

Snippet1

public class Test {

public static void main(String[] args) {

A a = new A();

System.out.println(a.j);

xyz(a);

System.out.println(a.j);

}

private static void xyz(A a) {

a = new A(); //watch this line

a.j=20;

}

}

class A {

public int j = 10;

}

Output:

10

10

Snippet2

public class Test {

public static void main(String[] args) {

A a = new A();

System.out.println(a.j);

xyz(a);

System.out.println(a.j);

}

private static void xyz(A a) {

//a = new A(); //commented

a.j=20;

}

}

class A {

public int j = 10;

}

Output:

10

20

In snippet 2, did you notice that the updated value from the method xyz is printed in the main method? In snippet 1, the updated value from the xyz method is not reflected in the main method and hence the updated value is not printed. There are reasons behind this behavior.

In the main method of snippet 1, an object A is created at memory location say “XYZ”. The memory location of the object is passed as parameter to method xyz. In xyz method, the statement a= new A(), creates a new A object at a different memory location say “PQR”. The value of the variable “j” in the object at memory location “PQR” is then updated to 20. When the method xyz returns, the main method still refers to the “XYZ” memory location and hence prints the original value of 10 and not 20.

In the main method of snippet 2, as in snippet 1, the object A is created at memory location “XYZ”. The memory location of the object is passed as parameter to method xyz. In xyz method, the value of the variable “j” in the object at memory location “XYZ” is then updated to 20. When the method xyz returns, the main method still refers to the “XYZ” memory location and hence prints the updated value of 20.

Try making the variable “a” as class level variable and static in nature, you will find the difference. You should be able to identify the difference.