Wednesday, June 13, 2012

Transfer a local file to Ranger using Airavata Client

This post will describe how to transfer a local file to Ranger [1] using Airavata Client.


NOTE: This post assumes that AiravataClient, GFac and the local_file will be in the same machine.

1. Before starting Airavata server, configure repository.properties file by modifying default fake values for following properties.
trusted.cert.location=path to certificates for ranger
myproxy.server=myproxy.teragrid.org
myproxy.user=username
myproxy.pass=password
myproxy.life=3600

Configure your certificate location and my proxy credentials and start Jackrabbit instance and airavata server with all the services.

2. To create a workflow to run on ranger you need to create Host Description, Application Description and a Service Description. If you  don’t know know how to create them refer airavata 10 minutes article [2] to understand how to create those documents. Once you become familiar with XBaya UI, use following values for fields given below and create documents using XBaya GUI.

Host Description
  • Host Address      - gatekeeper.ranger.tacc.teragrid.org
Click on the check box - Define this host as Globus host, then following two entries will enable to fillup.
  • Globus Gate Keeper Endpoint - gatekeeper.ranger.tacc.teragrid.org:2119/jobmanager-sge
  • Grid FTP Endpoint           - gsiftp://gridftp.ranger.tacc.teragrid.org:2811/
Service Description

Create a Service description as follows.

IO Parameter Name Type
input echo_input URI
output echo_output URI


Application Description
  • Executable path  - /share/home/01437/ogce/airavata-test/dir/file-breed.sh
  • Temporary Directory  -  /scratch/01437/ogce/test
Select the above created service descriptor and host Descriptor.. When you select the above created host descriptor you will see a new button Gram Configuration .. now click on that and fill following values.
  • Job Type  - Single
  • Project Account Number  - You will see this when you login to ranger, put your project Account number in this field
  • Project Description  - Description of the project - not mandetory
  • Queue Type  - development
Click on Update button and save the Application Description.

3. Running the workflow.

i) Using XBaya
Then Compose your workflow using the  service  created in Application Services. Now hit the red colored play button to run the workflow. It will prompt for a input file. Then give the input file path in following format (The file which you want to copy to Ranger).
file:/home/heshan/Dev/testing/airavata/temp.txt

Save the workflow in the registry (Xbaya Menu → Export → To Registry). This will be used when invoking the workflow using the AiravataClient.

ii) Using Airavata Client
public class AiravataClientTest {

    @Test
   public void testInvokeWorkflowString() {
       try {
           AiravataClient airavataClient = new AiravataClient("xbaya.properties");
           List<String> workflowTemplateIds = airavataClient.getWorkflowTemplateIds();
           Iterator<String> iterator = workflowTemplateIds.iterator();
           while(iterator.hasNext()) {
               String next = iterator.next();
               System.out.println("workflow : " + next);

               List<WorkflowInput> workflowInputs = airavataClient.getWorkflowInputs(next);
               Iterator<WorkflowInput> workflowInputIterator = workflowInputs.iterator();
               while(workflowInputIterator.hasNext()) {
                   WorkflowInput input = workflowInputIterator.next();
                   System.out.println("Name            :" + input.getName());
                   System.out.println("Type            :" + input.getType());
                   System.out.println("Value           :" + input.getValue());
                   System.out.println("Default Value   :" + input.getDefaultValue());
                   // System.out.println("input " + input);
               }

           }

           String workflowTemplateId = "GridFtp-local-workflow";
           List<WorkflowInput> workflowInputs = airavataClient.getWorkflowInputs(workflowTemplateId);
           String topicId = airavataClient.runWorkflow(workflowTemplateId, workflowInputs);

           WorkflowExecution workflowExecutionData = airavataClient.getWorkflowExecutionData(topicId);

       } catch (RegistryException e1) {
           e1.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
       } catch (IOException e1) {
           e1.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
       } catch (Exception e) {
           e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
       }
    }
}

[1] - http://www.tacc.utexas.edu/user-services/user-guides/ranger-user-guide
[2] - http://incubator.apache.org/airavata/documentation/system/airavata-in-10-minutes.html

Running a simple MPI job on Ranger

Let's consider running a simple MPI job on Ranger [1]. The MPI program considered here will be a hello-world program.

1) Write a hello world application in C.
#include <stdio.h>
#include <mpi.h>


int main (argc, argv)
     int argc;
     char *argv[];
{
  int rank, size;

  MPI_Init (&argc, &argv);        /* starts MPI */
  MPI_Comm_rank (MPI_COMM_WORLD, &rank);        /* get current process id */
  MPI_Comm_size (MPI_COMM_WORLD, &size);        /* get number of processes */
  printf( "Hello world from process %d of %d\n", rank, size );
  MPI_Finalize();
  return 0;
}

2) Compile it in Ranger.
mpicc -o mpi-hellow-world mpi-hellow-world.c

3) Write a schedular script to run your application. (Let's assume that we have saved it under the name scheduler_sge_job_mpi_helloworld)
#!/bin/bash
# Grid Engine batch job script built by Globus job manager

#$ -S /bin/bash
#$ -V
#$ -pe 16way 16
#$ -N MPI-Airavata-Testing-Script
#$ -M heshan@ogce.org
#$ -m n
#$ -q development
#$ -A ***********
#$ -l h_rt=0:09:00
#$ -o /share/home/01437/ogce/airavata-test/mpi-hello.stdout
#$ -e /share/home/01437/ogce/airavata-test/mpi-hello.stderr
ibrun /share/home/01437/ogce/airavata-test/mpi-hellow-world

4) Use the qsub command to submit a batch job to Ranger.
ogce@login3.ranger.tacc.utexas.edu:/airavata-test/{13}> qsub scheduler_sge_job_mpi_helloworld
Once the job is submitted following output can be seen.
-------------------------------------------------------------------
------- Welcome to TACC's Ranger System, an NSF XD Resource -------
-------------------------------------------------------------------
--> Checking that you specified -V...
--> Checking that you specified a time limit...
--> Checking that you specified a queue...
--> Setting project...
--> Checking that you specified a parallel environment...
--> Checking that you specified a valid parallel environment name...
--> Checking that the minimum and maximum PE counts are the same...
--> Checking that the number of PEs requested is valid...
--> Ensuring absence of dubious h_vmem,h_data,s_vmem,s_data limits...
--> Requesting valid memory configuration (31.3G)...
--> Verifying WORK file-system availability...
--> Verifying HOME file-system availability...
--> Verifying SCRATCH file-system availability...
--> Checking ssh setup...
--> Checking that you didn't request more cores than the maximum...
--> Checking that you don't already have the maximum number of jobs...
--> Checking that you don't already have the maximum number of jobs in queue development...
--> Checking that your time limit isn't over the maximum...
--> Checking available allocation...
--> Submitting job...


Your job 2518464 ("MPI-Airavata-Testing-Script2") has been submitted

5) Using the qstat command check the status of the job.
ogce@login3.ranger.tacc.utexas.edu:/airavata-test/{17}> qstat
job-ID  prior   name       user         state submit/start at     queue                          slots ja-task-ID 
-----------------------------------------------------------------------------------------------------------------
2518464 0.00000 MPI-Airava ogce         qw    04/19/2012 11:42:01                                   16        

6) The result of the batch job is written to the specified output file.
TACC: Setting memory limits for job 2518464 to unlimited KB
TACC: Dumping job script:
--------------------------------------------------------------------------------
#!/bin/bash
# Grid Engine batch job script built by Globus job manager

#$ -S /bin/bash
#$ -V
#$ -pe 16way 16
#$ -N MPI-Airavata-Testing-Script2
#$ -M ***@ogce.org
#$ -m n
#$ -q development
#$ -A TG-STA110014S
#$ -l h_rt=0:09:00
#$ -o /share/home/01437/ogce/airavata-test/mpi-hello.stdout
#$ -e /share/home/01437/ogce/airavata-test/mpi-hello.stderr
ibrun /share/home/01437/ogce/airavata-test/mpi-hellow-world
--------------------------------------------------------------------------------
TACC: Done.
TACC: Starting up job 2518464
TACC: Setting up parallel environment for OpenMPI mpirun.
TACC: Setup complete. Running job script.
TACC: starting parallel tasks...
echo_mpi_output=Hello world from process 7 of 16
echo_mpi_output=Hello world from process 6 of 16
echo_mpi_output=Hello world from process 2 of 16
echo_mpi_output=Hello world from process 4 of 16
echo_mpi_output=Hello world from process 3 of 16
echo_mpi_output=Hello world from process 10 of 16
echo_mpi_output=Hello world from process 13 of 16
echo_mpi_output=Hello world from process 9 of 16
echo_mpi_output=Hello world from process 8 of 16
echo_mpi_output=Hello world from process 0 of 16
echo_mpi_output=Hello world from process 1 of 16
echo_mpi_output=Hello world from process 12 of 16

[1] - http://www.tacc.utexas.edu/user-services/user-guides/ranger-user-guide

Thursday, March 29, 2012

Monitor CPU Utilization of a Amazon EC2 instance using Amazon CloudWatch

Following code snippet show how to monitor CPU Utilization of a Amazon EC2 instance using Amazon Cloud Watch. In order to monitor the instance, Cloud Watch Monitoring should be enabled for the running instance.
private double monitorInstance(AWSCredentials credential, String instanceId) {
try {
AmazonCloudWatchClient cw = new AmazonCloudWatchClient(credential) ;

long offsetInMilliseconds = 1000 * 60 * 60 * 24;
GetMetricStatisticsRequest request = new GetMetricStatisticsRequest()
.withStartTime(new Date(new Date().getTime() - offsetInMilliseconds))
.withNamespace("AWS/EC2")
.withPeriod(60 * 60)
.withDimensions(new Dimension().withName("InstanceId").withValue(instanceId))
.withMetricName("CPUUtilization")
.withStatistics("Average", "Maximum")
.withEndTime(new Date());
GetMetricStatisticsResult getMetricStatisticsResult = cw.getMetricStatistics(request);

double avgCPUUtilization = 0;
List dataPoint = getMetricStatisticsResult.getDatapoints();
for (Object aDataPoint : dataPoint) {
Datapoint dp = (Datapoint) aDataPoint;
avgCPUUtilization = dp.getAverage();
log.info(instanceId + " instance's average CPU utilization : " + dp.getAverage());
}

return avgCPUUtilization;

} catch (AmazonServiceException ase) {
log.severe("Caught an AmazonServiceException, which means the request was made "
+ "to Amazon EC2, but was rejected with an error response for some reason.");
log.severe("Error Message: " + ase.getMessage());
log.severe("HTTP Status Code: " + ase.getStatusCode());
log.severe("AWS Error Code: " + ase.getErrorCode());
log.severe("Error Type: " + ase.getErrorType());
log.severe("Request ID: " + ase.getRequestId());

}
return 0;
}

Wednesday, March 21, 2012

OGCE XRegistry to Airavata Registry migration guide

This post describes how to migrate OGCE XRegistry to Apache Airavata Registry.


Apache Airavata contains a migration tool that facilitates the migration of XRegistry resouces to Airavata Registry. Following are the steps to be followed for a migration of resources. (If you find any information missing that should be included in this post, please comment on [1]
)

1) Build the Airavata trunk [2].

2) Unzip the apache-airavata-0.3-incubating-SNAPSHOT.zip.

3) Start Airavata Jackrabbit Server by running the shell script in AIRAVATA_HOME/bin directory.
eg: jackrabbit-server.sh

4) Configure the properties file xregistry.properties file. This properties file consists information of XRegistry and Airavata Registry. (This properties file should be placed in the your classpath)
eg.
registryURL=https://YOUR_HOST:19443/xregistry?wsdl
ssl.trustedCertsFile=/home/heshan/Dev/setup/certificates
ssl.hostcertsKeyFile=/home/heshan/Dev/setup/xregistry/target/dist-bin/conf/ogce_services_key.pem
myproxyServer=myproxy.teragrid.org
myproxyUser=*****
myproxyPass=*****
myproxyLifetime=14400
jcr.url=http://localhost:8081/rmi
jcr.username=****
jcr.password=****
Following is a description of each of the above mentioned properties;
registryURL - URL of the XRegistry instance.
ssl.trustedCertsFile=Directory path Cert file used to connect to XRegistry
ssl.hostcertsKeyFile=Host Certificates key file
myproxyServer - URL for MyProxy credential management service
myproxyUser - User name used for MyProxy credential management service
myproxyPass - Password associated with the myproxy username
myproxyLifetime - Lifetime for myproxy certificate.
jcr.url - URL for JCR Registry
jcr.username - User name used to access the JCR Registry
jcr.password - Password associated with the JCR Registry User name
5) Go to the AIRAVATA_HOME/bin directory. Execute the xregistry-migrator shell script with your properly configured xregistry.properties file.
eg:
./xregistry-migrator.sh /home/heshan/Dev/xregistry.properties

6) Start the Airavata server using the shell script in AIRAVATA_HOME/bin directory.
eg:
./airavata-server.sh

Browsing the Airavata Registry
7) Viewing the migrated descriptors.
i) Start the XBaya GUI by using the shell script in AIRAVATA_HOME/bin directory.
eg:
./xbaya-gui.sh

ii) Click on the Registry Menu and select “Setup Registry” option. Click ok.

iii) Then using the Registry browser you can view the host, service and application descriptors saved in the registry.

8) Now using the saved application services, you can compose scientific workflows.

NOTE:
1) If there are multiple services under the same name (under different namespaces), those will be renamed (appending _NUMBER to the service name) during migration.
2) If there are multiple applications under the same name (under different namespaces), those will be renamed (appending _NUMBER to the application name) during migration.

References

Friday, March 16, 2012

How to Deploy Apache Airavata on Tomcat

Applies to
  • Airavata Trunk - apache-airavata-0.3-incubating-SNAPSHOT.zip
  • Axis version - Axis2 1.5.1.war
  • Jackrabbit version - jackrabbit-webapp-2.4.0.war
  • Tomcat version - apache-tomcat-7.0.23
Airavata services depends on Apache Axis2 as a Web Service engine. In order to deploy Airavata system on Tomcat, you need to deploy Apache Axis2 on Tomcat first.

1) Copy all the service jar files in AIRAVATA_HOME/standalone-server/repository/services/ directory to Tomcat axis2 services directory(TOMCAT_HOME/webapps/axis2/WEB-INF/services)

2) Copy all the dependent jars (copy all the jars in AIRAVATA_HOME/lib and AIRAVATA_HOME/standalone/lib ) to TOMCAT_HOME/webapps/axis2/WEB-INF/lib.

3) Copy the properties files for messageBox (msgBroker.properties) and messageBroker (msgBroker.properties) to TOMCAT_HOME/webapps/axis2/WEB-INF/classes/conf/. These properties files can be found in AIRAVATA_HOME/standalone-server/conf directory.

4) Copy the properties files for GFac Service (repository.properties) and Interpretor Service (xbaya.properties) to TOMCAT_HOME/webapps/axis2/WEB-INF/lib/ directory. These properties files can be found in AIRAVATA_HOME/standalone-server/conf directory.

i) Based on your setup configure the GSI security credentials and certificate paths in the repository.properties file.

ii) Fill up the following property names values in your xbaya.properties file based on your gsi security credentials.
eg : myproxy.user
myproxy.password

NOTE: keep the same repository.properties file in TOMCAT_HOME/bin directory too. This issue will be fixed in later release.

4) Download and copy a database library (Apache Derby or MySql) to webapps/axis2/WEB-INF/lib directory.
eg: derby-10.7.1.1.jar
derbytools-10.7.1.1.jar

5) Copy directory AIRAVATA_HOME/standalone-server/bin/database_scripts to TOMCAT_HOME/webapps/axis2/WEB-INF/classes/database_scripts directory.

6) Now we have configured a Tomcat instance to run Airavata Services. Next is to deploy Jacrabbit instance on a separate Tomcat instance(I'm referring it's home directory as TOMCAT_HOME2).

7) Deploy Jackrabbit on Tomcat

i) Download jcr-2.0.jar and put it into TOMCAT_HOME2/webapps/jackrabbit-webapp-2.4.0/WEB-INF/lib/.

ii) Get the WAR distribution from the Downloads page and deploy it into Tomcat.

iii) Make sure to change and configure the ports by editing TOMCAT_HOME2/conf/server.xml file.

8) Now startup the Jacrabbit deployed Tomcat instance.

9) Startup the Tomcat instance with Airavata services.

10) Go to service listing page and check the service status. If there are no faulty services, then you have done the setup properly.

Thursday, July 28, 2011

Sample client for Axis2 XMPP transport

Following is a sample service client that demonstrates the use of Apache Axis2's XMPP transport.

1) Add the following to your axis2.xml

i) Register the tranport listener.
<transportReceiver name="xmpp" class="org.apache.axis2.transport.xmpp.XMPPListener">
<!-- Account details for google talk -->
<parameter name="GoogleServer">
<parameter name="transport.xmpp.ServerUrl">talk.google.com</parameter>
<parameter name="transport.xmpp.ServerAccountUserName">axis2.xmpp.account1</parameter>
<parameter name="transport.xmpp.ServerAccountPassword">apacheaxis2</parameter>
<parameter name="transport.xmpp.ServerType">transport.xmpp.ServerType.GoogleTalk</parameter>
</parameter>
</transportReceiver>

ii) Register the transport sender.
<transportSender name="xmpp" class="org.apache.axis2.transport.xmpp.XMPPSender">
</transportSender>

2) Sample service client.
import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.axis2.transport.xmpp.util.XMPPConstants;
import org.apache.axis2.util.XMLPrettyPrinter;

public class XMPPSampleClient {
public static void main(String[] args) {
invokeTimeService();
}

private static void invokeTimeService() {
String endPointUrl = "xmpp://synapse.demo.0@gmail.com/" + "TimeService";

EndpointReference targetEPR = new EndpointReference(endPointUrl);
try {
ConfigurationContext ctx =
ConfigurationContextFactory.createConfigurationContextFromURIs(
XMPPSampleClient.class.getResource("axis2.xml"), null);

OMElement payload = getPayload();
Options options = new Options();
options.setProperty(XMPPConstants.XMPP_SERVER_TYPE, XMPPConstants.XMPP_SERVER_TYPE_GOOGLETALK);
options.setProperty(XMPPConstants.XMPP_SERVER_URL, XMPPConstants.GOOGLETALK_URL);
options.setProperty(XMPPConstants.XMPP_SERVER_USERNAME, "synapse.demo.0");
options.setProperty(XMPPConstants.XMPP_SERVER_PASSWORD, "mailpassword");

options.setTo(targetEPR);
options.setAction("urn:getServerTime");
ServiceClient sender = new ServiceClient(ctx,null);

sender.setOptions(options);
OMElement result = sender.sendReceive(payload);
XMLPrettyPrinter.prettify(result, System.out);
} catch (Exception e) {
e.printStackTrace();
}
}

private static OMElement getPayload() {
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs = fac.createOMNamespace(
"http://example.xmpp.transports.axis2.org/example1", "example1");
return fac.createOMElement("getServerTime", omNs);
}
}

Thursday, July 14, 2011

XSLT transformations with WSO2 ESB

Recently I did some performance comparison on a new mediator that I have developed for WSO2 ESB for XSLT transformations.

Following 6 scenarios were taken into consideration for this benchmark;

1) SCENARIO-1 : Direct Service call to backend service (which is hosted at axis2 server) from the client.

2) SCENARIO-2 : Service Call to the backend service through a Pass through proxy (Using message realy)

3) SCENARIO-3 : Service call to the backend service through the XSLT transformation proxy (with xalan XSLT processor)


3) SCENARIO-3 : Service call to the backend service through the XSLT transformation proxy (with xalan XSLT processor)

4) SCENARIO-4 : Service call to the backend service through the XSLT transformation proxy (with saxon XSLT processor)

5) SCENARIO-5 : Service call to the backend service through the XSLT transformation proxy (with saxon XSLT processor) - with patched XSLT mediator which is doing XML stream transformation (using message relay)

6) SCENARIO-6 : Service call to the backend service through the XSLT transformation proxy (with saxon enterprise edition XSLT processor) - with patched XSLT mediator which is doing XML stream transformation (using message relay)


Following are the configurations of the machines which were used in the performance benchmark. For more information refer the attached document named hardware-configuration-of-machines.txt

Hardware/Software configuration of the machines used

1) Configuration of the machine(32 bit) which was running the client (load testing tool used was java-bench):

OS : Debian GNU/Linux 6.0

CPU : Intel(R) Pentium(R) 4 CPU 2.80GHz

RAM : 1 GB

2) Configuration of the machine(64 bit) which was running the axis2 server which is hosting the service:

OS : Ubuntu 11.04

CPU : Genuine Intel(R) CPU T2400 @ 1.83GHz

RAM : 3 GB

3) Configuration of the machine(64 bit) which was running the WSO2 ESB:

OS : Debian GNU/Linux 6.0

CPU : Pentium(R) Dual-Core CPU E5400 @ 2.70GHz

RAM : 4 GB

Results/Observation

The time per request were measured for the XSLT transformations with the ESB and calculated the latency numbers. The message sizes used were 5k, 10k, 50k, 100k, 200k, 300k, 400k, 500k. The time per request were measured for the number of requests 10000, 11000, 12000, 13000, 14000, 15000. During the benchmarking session, I got the numbers for xalan as well as saxon XSLT processors. Since the primary concern of this benchmark was on latency, the concurrency level used was one.

i) Time per request

Request Size

Direct request (ms)

ESB -Pass through(Message relay) - Time per request(ms)

ESB (xalan) – Time per request (ms)

ESB (saxon) – Time per request (ms)

ESB patched (saxon) -– Time per request (ms)

ESB Patched (Saxon EE)

Timer per request (ms)

5k

2.932

5.087

11.458

9.899

7.486

7.413

10k

4.564

6.332

16.73

15.387

11.145

10.473

50k

17.881

20.984

46.328

42.481

40.834

34.598

100k

34.691

37.339

83.554

79.325

71.151

62.992

200k

67.66

70.771

155.233

146.885

128.672

119.886

300k

100.661

103.945

233.79

213.84

186.985

177.184

400k

133.125

137.898

295.675

283.95

245.029

238.081

500k

166.008

169.460

364.027

356.182

302.779

297.676

ii) Latency

The latency was calculated by the following equation.

Latency = (Time per request through ESB - Direct request)

Request Size

ESB(Message relay) latency (ms)

ESB (xalan) latency (ms)

ESB (saxon) latency (ms)

ESB patched (saxon) latency (ms)

ESB patched (saxon-EE) latency (ms)

5k

2.155

8.526

6.967

4.554

4.481

10k

1.768

12.166

10.823

6.581

5.909

50k

3.103

28.447

24.6

22.953

16.717

100k

2.648

48.863

44.634

36.46

28.301

200k

3.111

87.573

79.225

61.012

52.226

300k

3.284

133.129

113.179

86.324

76.523

400k

4.773

162.55

150.825

111.904

104.956

500k

3.452

198.019

190.174

136.771

131.668

iii) Overhead

The overhead percentage introduced by the ESB is calculated by the following equation.

ESB Overhead = (Time per request through ESB - Direct request time)/(Direct request time) * 100 %

Request Size

ESB(Message relay) overhead(%)

ESB (xalan) overhead percentage (%)

ESB (saxon) overhead percentage (%)

ESB patched (saxon) overhead percentage (%)

ESB patched (saxon-EE) overhead percentage (%)

5k

73.49931787176

290.7912687585

237.619372442

155.3206002729

152.830832196453

10k

38.737949167397

266.5644171779

237.1384750219

144.1936897458

129.469763365469

50k

17.353615569599

159.0906548851

137.5761981992

128.3653039539

93.490296963257

100k

7.6331036868352

140.8520942031

128.661612522

105.0993052953

81.580236949065

200k

4.5979899497488

129.4309784215

117.0928170263

90.1744014189

77.188885604493

300k

3.2624353026495

132.2547957998

112.4357993662

85.7571452698

76.020504465483

400k

3.585352112676

122.103286385

113.2957746479

84.059342723


78.840187793427

500k

2.0794178593803

119.2828056479

114.5571297769

82.3881981591

79.314249915667

Observation

In case of scenarios 3 & 4, the only difference is the underlying XSLT processor used by the ESB is changed from the xalan to saxon. When comparing the performance numbers of xalan and saxon; saxon is showing a little performance improvement. Therefore, there is no significant gain with the use of saxon as opposed to xalan (which is the default XSLT processor shipped with the ESB).

In case of scenario 5, I developed a new mediator to do XSLT transformation by passing in the stream directly to the XSLT processor with the use of Message Relay.

Compared to scenarios 3 & 4, scenario 5 is showing a significant performance improvement.

The difference between scenario 5 and 6 is that the underlying saxon XSLT processor is changed from the community edition to enterprise edition. Compared to scenario 5, scenario 6 is showing a performance improvement.

Throughout this post I have talked about a transformation mediator which is supporting streaming. This will be available with the next release of the WSO2 ESB. This meadiator's name will be relayTransformer.

I will write a new post on this new mediator on some other time.

NOTE: This performance figures were calculated, inorder for me to get an idea about the performance gain of this new mediator. These figures were not calculated in an ideal environment. Therefore, if you try to compare these numbers with a performance benchmark that you might have done, it might not be comparable.

References

[1] - http://wso2.org/products/download/esb/java/4.0.0/wso2esb-4.0.0.zip

[2] - http://heshans.blogspot.com/search/label/ESB

[3] - http://wso2.org/project/esb/java/4.0.0/docs/samples/message_mediation_samples.html#Sample8