Thread: Symping, The Symphony Configuration Testing Tool

Symping is a powerful application that is shipped with Symphony DE. It can be used to simulate your application's data-flow and processing load on your cluster.

Although symping can produce some useful data, you should be aware that Symphony DE's performance may not scale linearly to larger clusters or more powerful CPU's.

Configuration

To use symping effectively, you should have at least a two host cluster, with your master components (GUI, SD & SSM) running on one host and your compute host components (SIM & SI) on the other(s). You should configure one SIM per CPU (core) on the compute host. See the vem_resource.conf document for more information.

I also suggest that you modify the symping application profile to pre-start the SIM's and SI's on the compute host. The number of pre-loaded services should be equal to the number of compute host CPU's. By doing this, you eliminate the time it takes to instantiate a service instance from the calculations.

To set the number of pre-loaded services, select Configure Applications in the Platform Management Console. Click on the symping4.0 link to launch the Application Profile Editor. Select Advanced Configuration option in the editor. Set the pre-start application value to true and the number of pre-loaded services to the desired number.



Once this change is saved, Symphony DE will pre-start the specified number of SI's on your compute hosts.

Testing

Symping has both a command line interface and a GUI page. The command line is for advanced users and won't be discussed here.

To start the GUI page, select Symphony Workload and then Run Symping. The following page will open.



The Advanced Settings and Output option is enabled on this page.

First, click Run! to ensure that your cluster is setup correctly. Now, look at the Optional Settings on the right-hand side of the page. Set the session type to UnrecoverableNoHistoricalData. This will minimize the Symphony system overhead. You can create several test runs to determine how efficiently workload can be run on your cluster. Here's an example:

1. Set the input message size to 100 bytes
2. Set the output message size to 100 bytes
3. Set the task processing time to 100 milliseconds
4. Set the number of tasks per test run to 4000
5. Run the test

You can leave Log Option unchecked, but enable Consume CPU Cycles. Symping will use sleep by default, which won't give accurate results. We want the SI to compete with the middleware for CPU cycles.

The value that you are interested in is the Session Roundtrip in the Test Summary area. This value is the length of time your workload took to complete.

You can now modify your test to see whether a longer task that exchanges more data will run more quickly. Here's a follow-up example in which I scaled the tasks up by 100 and reduced the number of tasks by a factor of 100:

1. Set the input message size to 10000 bytes
2. Set the output message size to 10000 bytes
3. Set the task processing time to 10 seconds (change units from milliseconds to seconds)
4. Set the number of tasks per test run to 40
5. Run the test

The number of CPU's in your cluster should be evenly divisible by 40, otherwise you will need to adjust the number of test runs. You want to avoid having some CPU's idle during execution of the last task.

Analyzing Results

Symping can produce a rough guess as to how fast your application can run on this cluster. No application will have tasks that take a constant time to run, so your actual results will vary. As well, your application will have dependencies that can not be simulated using symping.

Symping can tell you how much common and task data can be efficiently moved through Symphony. It can also give you the approximate minimum time each task should take to execute to efficiently utilize your cluster.

My results for the above tests on a 2 host Windows cluster were:

1. 223 seconds to complete
2. 110 seconds to complete

By increasing the amount of processing in a task from 100ms to 10s, we almost halved the overall processing time for the workload.

Feel free to post your results here so that we can compare performance results.

References

1. Symping Reference

2. Using Symping

Hi,

Kindly let me know if below inference is correct.

case1
Set the input message size to 100 bytes
Set the output message size to 100 bytes
Set the task processing time to 100 milliseconds
Set the number of tasks per test run to 4000

case2
Set the input message size to 10000 bytes
Set the output message size to 10000 bytes
Set the task processing time to 10 seconds
Set the number of tasks per test run to 40

So as per your analysis case2 is faster than case1. This implies lesser number of tasks, lesser SI's, more message data sent and faster throughput. But doesn't this indicate more data has to be serialized and transferred through network?

Ideally only taskid's, serviceid's should be sent which will reduce network latency and message data is taken from in memory grid. Am I right?

Thanks