Perform upgrade of TIBCO components / Migration from TIBCO BW 5.X to 5.Y

These are the example steps for migrating from domain "OLD" to domain "NEW".

1.We have a writable directory to export the applications to. Let's call it $BATCHDIR.

2.We should know the actual username and password for the old and new domains.

3.Make sure both domains are running.

4.cd to $TRA_HOME/tra/<ver>/bin/ , lets say /utils/tibco/tra/5.3/bin/

5.Use this command to create a batch file and export .ear files and configuration files: "AppManage -batchExport -domain OLD -user tibco -pw tibco -dir $BATCHDIR "

6.To import all of the applications without starting them, use this command: "AppManage -batchDeploy -domain NEW -user tibco -pw tibco -dir $BATCHDIR -nostart"

If we want to automatically start the applications after deploying, leave off the -nostart parameter. If we don't want to deploy all the applications, modify the $BATCHDIR/AppManage.batch file by commenting or deleting the applications we don't want to deploy.

Typically after we do the batch deploy, we manually stop all of the engines in the old domain, then manually start the engines in the new domain, then stop the old domain itself. This leaves the old domain intact in case something went wrong with the deployments, but it no longer uses any resources.

Business needs may require us to have an engine running at all times, so we could start the new engines before stopping the old engines, but we should make sure they will not conflict with each other first.

Improvements to the AppManage utility in TRA version 5.3 give even more control over working with multiple engines.

Pain points which needs to put light in migration

Is all the Services are scripted deployed or not, in OLD domain?
If few of them manual deployment How to go about it?
How to convert everything to Scripted deployment going forward to ease further enhancements?
Memory Issues (Physical as well as RAM), System requirements due to migration?
Get to know the Basic difference of versions (old and new), e.g. Kind of repository used?
What causes engine startup error due to migration?
How to automate these entire process?
Can be divided into sections Export, Process & Import ?
Is services falls under LB as well as FT?
What are all adapters involved?
Carefully diagonize the difference this is where you end up more processing ?






 

Scenario - web services / Performance Tuning / work load

We have created web service as server (starter activity 'soap event source') process.

How many  number of  incoming HTTP requests (concurrent i.e.occurring at the same time) that can be handled by this web service  ? or  How can we define the workload for this process ?

Answer :

Workload can define by setting the following properties in bwengine.tra file:

bw.plugin.http.server.minProcessors
bw.plugin.http.server.maxProcessors

Setting maxProcessors to 100, means  upto 100 requests can be accepted concurrently.

 Engine.ThreadCount

To improve the ability to execute process instances concurrently, more engine threads are required.

The number of engine threads to be allocated can be set using the property Engine.ThreadCount. The default value is 8.

Engine.StepCount

Set the property, Engine.StepCount, to specify the maximum number of execution steps for a job, unless in a transaction or when the ActivationLimit is set. The default value is 20.

A low value of StepCount results in frequent thread switches. This is an overhead, especially when the number of execution steps for most jobs is high.

bw.plugin.http.client.ResponseThreadPool


To specify the size of the thread pool used by the Request-Reply activity on the web service client side, set the properties: 

bw.plugin.http.client.ResponseThreadPool
bw.plugin.http.client.ResponseThreadPool.type

As the thread pool is created when the engine starts, use a reasonable number to specify the size of the ResponseThreadPool for your system. A high value results in extra resources being allocated which may never be used.

RV- Peak Load Test /Performance Test Tools

RV 8.1 and above version software provides a tool rvperf (Rendezvous performance assessment software)

This tool is to answer questions about network behavior under sustained load conditions.

For example:

•  What happens to network performance when an application sends a batch of ten thousand messages without pausing?
•  Which computers in my network can send messages the fastest? Which can receive fastest?
•  How do peak loads affect network throughput?

Performance assessment software consists of two executable programs in below location once after tra installation.

C:\tibco\tibrv\8.1\bin>

●    rvperfm (master) sends messages, gathers performance data, and outputs the report.

●    rvperfs (slave) subscribes to messages from rvperfm, and sends back data about its own speed and effectiveness.

Example :

 Open  command prompt  and go to the path C:\tibco\tibrv\8.1\bin>
 

Start listener with one subject and  Fire the command below then it gives the output report for the mentioned subject.

C:\tibco\tibrv\8.1\bin>
rvperfm -service 1234 -network localhost -daemon tcp:1234 -subject TEST -messages 1 -size 30003728

rvperfm coordinates the tasks of measuring network performance. It sends messages to the network, and reports statistics to stdout.

rvperfm prints a brief string as it begins sending the run of messages, and another when it finishes sending the run.

Then it outputs its run report:

1.     Statistics that rvperfm collects while sending the messages.
2.     Statistics that each rvperfs process collects while receiving messages. 

Each group of statistics represents the performance of one rvperfs process.

 

 Elapsed Time :

Both programs in the performance tool report the total time that elapsed in each complete run.

The speed at which the Rendezvous daemon can deliver messages to the network depends on the network itself, the network interface card (and other hardware parameters), and the host operating system.

If rvperfm sends at a faster rate than the network can accept, rvperfm retains messages in its outbound queue until the network can accept them.

Elapsed time: 0.500000 seconds

Above example screenshot, 0.500000 seconds elapsed from the time that rvperfm sent the first message of the run, until the time that the daemon transmitted the last message of the run to the network.